Your agent loop can now think, act, observe, and stop. But there is a question the loop alone does not answer: when the agent says "I will publish this," has anything actually happened yet?

Beginners blur five very different events into one. Experienced builders keep them strictly apart — because the controls for each are different, and confusing them is how drafts become public incidents.

Five levels, from harmless to irreversible

Think of everything an agent produces as sitting on a ladder. Each rung looks similar in chat. Each rung means something completely different in the real world:

The core confusion is between levels 2 and 5. An agent that writes "Calling publish_post..." in its narration has not necessarily called anything. Only the tool log — inputs, timestamp, result — proves execution. This is the same lesson as Class 15's boundary rule: availability is not permission, and narration is not action. Lesson 30.4 will make that check mechanical.

Reads (level 3) are where every new agent should live for its first runs. Proposals (level 4) are where it earns trust. Execution (level 5) is where a human stays in the path for anything consequential.

Gates: the actions that always wait for a yes

Some actions never run on the agent's own authority, no matter how confident it sounds or how many clean test runs precede them. Memorize this gate list — it returns in every later class:

• Publish — a post, article, or release going public under your name.
• Spend — payments, trades, ad spend, paid API commitments.
• Delete — records, files, accounts, backups.
• Send — emails, messages, or notifications to real people.
• DNS changes — routing edits that can take a site offline globally within minutes.
• Production writes — migrations, config changes, or deploys that touch live data or live traffic.

The gate itself is simple and visible:

agent proposes (exact tool + inputs + target)
  → human reviews the proposed artifact
  → human approves with scope ("merge PR #118 only")
  → agent executes narrowly → result is logged with approver + time

No bundled approvals. "Approved to handle publishing" is not an approval — it is an abdication. Each consequential action gets its own yes, its own scope, and its own log line.

Worked example: the article package that never silently publishes

Take an editorial agent tasked with turning a source packet into a finished article. Here is the safe path, rung by rung:

1. Plan (level 1). "I will draft the article from packet 2026-09-01, check required fields, and open a review PR." Reviewable words, zero side effects. 2. Inspection (level 3). The agent reads the packet, lists the target folder, and checks the publishing checklist. All read-only calls, all logged. 3. Proposed change (level 4). The agent writes the draft to a branch, runs the draft validator (Lesson 30.4), and opens a pull request with sources, citations, and the validation result attached. The PR description names exactly what it proposes: "Add articles/2026-09-01-guide.md, no production changes." 4. Human merges (level 5, gated). A human reads the diff, checks the sources, and merges. The agent never calls publish, never pushes to main, never flips a CMS flag on its own.

If the agent instead narrates "Published the article!" with no PR number, no merge commit, and no approver — nothing was published. Or worse, something was published outside the review path, and the missing gate is the incident. Either way, the tool log settles it in seconds.

This is the pattern for every pair from Class 15: draft before publish, schema read before migration, balance lookup before payment, DNS list before DNS update. Propose visibly, review deliberately, execute narrowly.

Practical exercise: add the approval line to your agent card

Pull out the AGENT-CARD.md you wrote in Class 28 — goal, input, tools, output, stop condition, human owner. Now annotate every consequential step:

1. List each tool or output your agent touches. 2. Beside each one, write one line: Approval required: yes / no — approver: <name or role> — scope: <exact action>. 3. Every publish, spend, delete, send, DNS, or production-write step must read yes with a named approver. Reads and local drafts may read no, with the review path noted.

Example lines:

- read_source_packet: approval required: no — review path: logged reads
- open_review_PR: approval required: no — human merges afterward
- merge_to_main / publish: approval required: yes — approver: Darin — scope: this PR only
- delete_old_packets: approval required: yes — approver: Darin — scope: named files only

Finish line: an updated AGENT-CARD.md where every consequential step carries an explicit approval line with a named human.

Verify: hand the card to a fresh session and ask: "Which of these would you do without asking: read the packet, open a review PR, merge to main, delete old packets?" If it would merge or delete unasked, the approval lines are not explicit enough.

Common failure mode: "approval required for important actions." Which actions, approved by whom, for what scope? Name the tool, the approver, and the boundary — otherwise the gate never triggers.

Check your understanding

1. In your own words, what separates a simulated tool call from an executed action? Where would you look to tell them apart? 2. Why should a new agent spend its first runs at level 3 (read-only) before touching levels 4 and 5? 3. For each gate item — publish, spend, delete, send, DNS, production write — explain *why* it needs a human yes. 4. In the article-package example, what exactly did the human review before merging? 5. What is wrong with the approval "you may handle publishing when ready," and how would you rewrite it?