Fieldnotes / engineering

Human-in-the-loop

Explanation

Propose, review, execute

An agent prepares a proposed action. A reviewer decides whether that action should proceed. An executor enforces the decision and performs it.

These are separate responsibilities. The proposing agent does not need unrestricted production credentials.

  1. 0s The agent prepares a release proposal. It has not deployed anything.
  2. 7s A reviewer inspects the proposed action. A decision is still required.
  3. 14s The executor waits for authorization. A proposal alone cannot trigger execution.
  4. 21s Keep these responsibilities separate. Preparation is different from permission.

Give the reviewer evidence

A review request should name the exact artifact, environment and observed checks. The reviewer needs a concrete action rather than a vague request to continue.

The decision should identify the action that was reviewed. Approval is not a blanket permission for future changes.

  1. 0s The proposal names artifact A. Its destination is production.
  2. 7s Attach test results and relevant risks. The reviewer can inspect the evidence.
  3. 14s The reviewer makes a decision about A. Store the action the decision applies to.
  4. 21s Approval now refers to a concrete artifact. Execution must check that same identity.

Pause without guessing

A workflow can persist its state while waiting for a human decision. A durable pause must survive the failures relevant to the application.

Elapsed time is not approval. Resume only with a trustworthy decision and preserve the action under review.

  1. 0s The workflow reaches a review boundary. It pauses before executing the action.
  2. 7s Save the state and proposed artifact. The pending work can be resumed later.
  3. 14s No decision has arrived yet. Do not interpret waiting as consent.
  4. 21s A decision can resume the workflow. Revalidate the action before execution.

Reject an approval mismatch

A new edit produces artifact B while approval for A is pending or already recorded. The executor must not apply approval of A to B.

New artifact, target or significant parameters require revalidation and, when policy requires it, a new decision.

  1. 0s The current artifact has changed to B. The recorded approval still names A.
  2. 7s The executor compares their identities. The approved and requested actions differ.
  3. 14s Execution is blocked by the mismatch. No deployment happens here.
  4. 21s Review B with its own current evidence. Do not treat approval as transferable.

Record the outcome

The executor checks the matching approval and permissions, performs the action, and records the result. Resume and retry behavior must avoid duplicate effects.

Human approval does not replace reliable execution. Use suitable idempotency and failure handling for the actual operation.

  1. 0s In a separate run, artifact A is approved. The executor also checks permissions.
  2. 7s The executor performs the operation. A restart must not blindly repeat effects.
  3. 14s Record the observed execution result. Keep it tied to the approved artifact.
  4. 21s Report what actually happened. Approval and successful execution differ.
Read the guide

Helpful first: Guardrails and permissions.

The idea

Separate proposing, reviewing and executing. A model can prepare a useful change without holding production credentials. A reviewer needs a concrete action and supporting evidence; the executor needs a trustworthy decision about that same action. A stored instruction to ask first expresses intent, but does not enforce permissions.

Where it helps

Delegation removes moments when an engineer might notice a surprising command. Put review where mistakes become costly, such as deployment. Our recommendation is to automate bounded preparation and reserve attention for decisions requiring context.

Teams adopting agents need to decide where delegation stops before expanding tool access. This chapter turns familiar release review into an explicit contract between the agent, reviewer and executor.

An agent prepares release A of a checkout service, attaches its test results and requests deployment to production. While approval waits, another edit creates release B. The deployment executor must not treat approval of A as approval of B. In our illustrative design, B requires new evidence and a new decision; no deployment occurs while the mismatch remains.

What you will be able to check

  • Specify a review request containing an immutable artifact identity, target, evidence and expected impact.
  • Demonstrate that a changed proposal cannot reuse an earlier approval.
  • Explain what survives a restart and which operations can repeat during resumption.

What changes in the team

Today
An engineer builds a release, inspects its diff and tests, asks a teammate for review, then starts deployment.
With an agent
An agent prepares the release packet; a workflow pauses for review and a restricted executor checks the approved packet before deployment.
Still your responsibility
The reviewer evaluates intent, impact and acceptable risk, and remains responsible for approving, rejecting or requesting changes.

Work through an example

  1. Prepare a release packet. Include the checkout service’s artifact digest, production target, change summary, test evidence, rollout steps and recovery plan. Use trusted build outputs to identify the artifact. Give the reviewer something inspectable beyond the agent’s confidence.
  2. Pause and retain the packet. LangGraph interrupts require a checkpointer and thread ID; resumption uses that same thread. Its persistence documentation warns that in-memory checkpoints disappear on process restart. Choose durable storage when approvals must survive deployment or worker failure; a chat message alone is not a durable workflow.
  3. Review the specific release. Let the engineer inspect A and approve, reject or request edits. Record the authenticated reviewer, decision and packet identity in protected application state. If the agent produces B, return it for review. The artifact-approval cut isolates this substitution problem. The other cuts show changed production prerequisites and LangGraph node replay; none depicts every release check.
  4. Revalidate and execute. Check the target’s current prerequisites and release identity at the executor, protecting the check-to-action boundary against concurrent changes. GitHub environment approvals illustrate a real gate: protected jobs cannot access environment secrets before approval. Availability depends on plan and repository visibility; administrator bypass settings also matter. This does not supply our artifact-binding contract automatically.
  5. Resume without duplicating work. LangGraph restarts the interrupted node, so earlier code can run again. Keep the deployment outside that preparation node and make repeated execution harmless, for example by reconciling a unique release request with the deployment system. Moving code after an interrupt alone is not a general exactly-once guarantee.

The engineering decision

Choose the approval boundary by impact and reversibility. Make rejection and cancellation real outcomes, and assign someone to handle abandoned requests. OWASP recommends server-side authorization, reviewable transaction details and a final execution gate. Applying those principles to agent releases is a design recommendation, not a feature guaranteed by an agent framework.

  • Approving a broad task such as “ship the fix” while the executable artifact keeps changing.
  • Giving the agent a second credential or tool path that bypasses the review gate.
  • Treating approval as proof that a release is correct, or repeatedly presenting evidence too weak for a meaningful decision.

Try it with your team

Break a stale approval in a sandbox

  1. Create a fake deployment tool that records its input instead of changing a real service.
  2. Prepare packet A and have a teammate record approval for its artifact identity and target.
  3. Replace A with B before resuming; attempt execution with A’s approval.
  4. Review B, approve it, then resume twice and inspect the tool’s recorded effects.

You have an answer when…

  • The stale approval produces no deployment record and a visible request for fresh review.
  • A newly approved B produces one intended deployment effect across duplicate resumption; the log identifies reviewer, artifact and target.

Read further

Take one delegated task your team runs today. Which exact artifact and target would a reviewer authorize, and what executable check prevents a later revision from inheriting that authorization?

Original video comparisons