Lesson 5 of 6 · 0%Define a first agent that can only proposeNext
Course map

Safe Installation and First Agent

0 of 6 complete0 of 6

Lesson 5.1 · 40 minutes

Define a first agent that can only propose

Design one narrow test task with controlled input, no real channel, a human approval gate, and an audit note.

Skip course map

Verifiedon 2026.7.1-2

Action boundary

Before you act

Expected result
A single-purpose task returns a proposal and audit note without sending, modifying, or deleting external data.
Failure mode
A vague instruction, connected channel, broad workspace, or tool permission permits an action before the operator approves it.
Rollback
Stop the run, remove any test-only files it created, disconnect the test integration, and narrow the task before retrying.

Design the boundary before the prompt

A first agent should demonstrate a useful bounded turn, not prove that an AI can reach everything. Choose one synthetic input, one reviewable output, and no external side effect. A good beginner task is: read a locally created brief containing three fictional observations and propose a checklist for the operator. The agent may not send a message, open a ticket, edit a repository, browse a private account, purchase anything, or execute a command outside the dedicated directory.

The OpenClaw agent CLI reference distinguishes openclaw agent exec from a Gateway-backed conversation. At the reviewed OpenClaw 2026.7.1-2 revision 1237c0cf8157a6ad4a900d6b165ea8c830449e78, agent exec runs one embedded turn without connecting to a Gateway and supports a dedicated working directory, an isolated configuration mode, and an environment-only authentication mode. Those flags solve different problems. Do not combine --isolated and --auth-env-only; the reference says --auth-env-only loads no config and uses provider keys already visible in the process environment.

Proposal-only agent loop
  1. Synthetic inputOne non-sensitive file in a dedicated lab directory.
  2. Explicit contractAllowed output is a draft checklist shown to the operator.
  3. Bounded runUse a reviewed exec mode and stop on an unexpected request.
  4. Human reviewA person decides whether any future action is separately authorised.

Write the task contract

The contract is more important than the wording of the prompt. It should be short enough to review before every run and specific enough to reject scope creep. Include these fields:

  1. Purpose: transform the synthetic brief into three proposed checks.
  2. Allowed input: one named local file containing fictional data.
  3. Allowed output: a proposal printed for the trusted operator and an optional local audit note.
  4. Forbidden actions: send, publish, purchase, delete, edit external systems, access real channels, follow links, or read outside the lab directory.
  5. Approval: a named human must approve a later external action in a separate step; the agent’s output is never approval.
  6. Stop conditions: any tool request, path escape, secret-like string, timeout, unexpected recipient, or instruction that conflicts with the contract.
  7. Audit note: UTC time, input label, mode, result classification, approval decision, and teardown result—no secret or private content.

Use a dedicated directory containing only the synthetic brief and task card. The directory name is not a security boundary by itself, so keep the host and account boundary from the pre-flight lesson in force. A fake file inside a production repository is still inside a production repository.

Lab: run one controlled proposal

Create a synthetic brief such as:

brief-id: synthetic-001
observations:
- the test Gateway returned a health snapshot
- the provider check passed for the approved test model
- no channel is connected
instruction: propose three checks for the operator's review; do not act

Then run a reviewed headless form. Choose one mode after reading the current reference:

Isolated proposal run
openclaw agent exec --isolated --cwd ./openclaw-first-agent-lab --message-file task.md --json

Expected output: JSON response contains a proposal; no tool request or external recipient appears

or:

Environment-only proposal run
openclaw agent exec --auth-env-only --cwd ./openclaw-first-agent-lab --message-file task.md --json

Expected output: JSON response contains a proposal using only the approved process-environment credential

Use --isolated when the approved provider path is available in the execution defaults and you want to ignore ambient configuration. Use --auth-env-only only when the revocable provider credential is intentionally present in the process environment and you want to exclude stored credentials, external CLI logins, and config. Do not pass a config path with --auth-env-only; the reviewed reference rejects that combination because config can supply credentials through several surfaces.

Before running, inspect task.md for real names, URLs, tokens, copied inbox content, and instructions that grant new authority. After running, inspect the JSON result for proposed action language, tool calls, file writes, and error status. --json makes stdout parseable, but it does not sanitize content. Store only a redacted summary in the learner artifact.

Worked safety decision

Unsafe request: “Read my inbox, identify urgent items, and email the team a summary.” It has uncontrolled input, real recipients, an implied authority to classify private mail, and a delivery side effect. Rewrite it as: “Read synthetic-inbox.txt in this lab, list the three fictional items that match the provided rubric, and produce a draft for operator review. Do not send, browse, or access any other file.” The rewrite narrows both the data and the authority.

A second unsafe pattern is a prompt that says “if the user asks, do it”. That sentence defeats the contract because the model or a copied document can impersonate the user. Use an explicit named approver and a separate action step. Approval should include the exact proposed action, target, recipient, and rollback—not a general instruction to trust the agent.

Checkpoint: observe the stop rules

Stop the run if the agent asks to read outside the directory, requests a tool, emits a credential-shaped value, follows an external URL, times out, or returns a result that cannot be classified as a proposal. Do not click through a warning to “see what it would do”. Preserve the redacted error and the last known boundary, then narrow the task or escalate.

Local practice

Proposal-only contract

Every step remains visible without JavaScript. When enabled, this browser stores checks on this device only.

0 of 5 checked

Expected result, failure mode, and rollback

Expected result: one JSON or text response contains a useful three-item proposal, with no real channel, tool request, external file mutation, or recipient. Failure mode: the prompt is vague, the working directory is broad, ambient credentials are used unintentionally, or the agent makes a request outside the contract. Rollback: stop the process, remove only test-only files it created after inspecting their paths, disconnect any accidental test integration, revoke a credential if it may have been exposed, and rewrite the contract before retrying. A failed proposal is preferable to a successful action outside scope.

Primary source receipt

Learner artifact: a redacted task contract plus one run summary. It should show what the agent was allowed to do and what it actually proposed; it must not claim that the agent is production-ready.

Source provenanceVerification and sources

Review receipt rr_setup_first_agent

Outcome
approved
Method
source-review
Reviewer
forge-independent-review
Reviewed

Evidence

Limitations

  • Independent source review approved the isolated proposal-only procedure; no tool, channel, or external side effect was exercised.

Open the public evidence snapshot

Lesson checkpoint

Ready to move on?

Mark this lesson complete when you can apply its outcome without relying on the examples above.