A goal gives an agent direction. A control loop gives the surrounding operation a way to know whether the work is complete, incomplete, or unsafe to continue.

It is tempting to describe an agent as a model with a goal and some tools. That is only the beginning of the design. Once the model can choose a route through several actions, the operation needs more than a final answer. It needs to see the work that was planned, the work that actually happened, the failures that were repaired, and the point at which the system deliberately stopped.

This becomes especially important when one agent coordinates several others. A parent can divide a large item into independent units, send each unit to a specialist, and combine the returned findings. Parallel work can be useful when one context cannot reasonably hold the whole task. But every additional unit is also another place where a result can be malformed, missing, contradictory, or quietly forgotten before the synthesis is written.

The reliable question is therefore not “can this agent finish the job?” It is “what evidence tells us whether the job is actually complete, and what happens when it is not?” A control loop answers that question with explicit ownership, recorded state, recovery paths, and human gates at the decisions that cannot safely be left to a run.

01Scope

Give each delegated unit a bounded task and a result shape the orchestrator can validate.

02Observe

Record the units dispatched, the units returned, and one trace that connects the whole run.

03Recover

Retry, re-route, or declare a gap before a partial result can become a confident summary.

04Gate

Pause for a person before irreversible or high-stakes action; protect the coordinator's state throughout.

01

Make the goal operable, not merely ambitious

In a multi-agent design, the orchestrator owns the goal. Its job is to decide how the work is divided, issue the assignments, and make sense of the results together. A subagent owns one scoped piece of work and returns its finding. This separation is useful only if the orchestrator has made the handoff clear enough to inspect. “Review this material” is a vague instruction; a named unit, expected output, and known completion condition are a workable assignment.

Before dispatching, decide what a usable return looks like. The expected structure might require a finding, the evidence considered, and a stated uncertainty. It might also require the subagent to say that it could not complete the unit. The exact format will depend on the task. What matters is that the coordinator can distinguish a valid result from an empty response that merely looks like one.

There is a second design choice here: how the coordinator will handle disagreement and gaps. Two subagents can return incompatible findings. A result can be present yet fail the expected structure. The system should not leave either case to an improvised final summary. Define the conflict rule or escalation route while the architecture is being designed, when it can still be examined by the people accountable for the outcome.

02

Observe the whole run, not just the final prose

A fluent synthesis is not proof that all of the underlying work happened. Consider a hypothetical illustration: a coordinator divides a policy review into independent sections. Most subagents return usable findings, one times out, and another returns a response that cannot be parsed. If the coordinator produces a polished summary from the results in hand, a reader may receive an apparently complete answer with two silent holes in it.

The essential check is simple: reconcile the units returned with the units dispatched. The system must know how many pieces of work it asked for, which ones completed, which ones are still pending, and which ones were explicitly abandoned or escalated. A synthesis may only describe coverage that its own record can support. If the counts do not reconcile, the gap belongs in the output or in an exception queue before anyone treats the work as complete.

That record also needs to survive the journey across agents. A shared trace identifier lets an operator follow one run from the initial goal, through its subagent assignments, to its recoveries and final synthesis. Without it, each component can appear healthy in isolation while the complete trajectory is impossible to reconstruct. Observability is not an after-the-fact dashboard; it is the thread that makes a distributed decision reviewable.

03

Recover locally; surface what cannot be recovered

Not all failures carry the same consequence. A subagent that returns nothing is often recoverable: validate the response, try again, route the unit to another capable path, or mark the unit as a gap. The key is that a recoverable failure still needs a mechanism watching for it. A timeout does not become safe merely because another part of the system continued running.

The coordinator's failure is different. If it loses the goal, the map of assignments, or the state it needs to synthesize results, there may be no trustworthy way to infer what happened after the fact. Protect that state and checkpoint progress so a failed run can resume from a known point rather than quietly rebuilding a different interpretation. This is not redundant ceremony. The orchestrator is the component holding the meaning of “complete.”

Failure boundaryControl responseEvidence retained
Subagent returnValidate the expected result; retry, re-route, or flag the missing unit.Assignment, return status, validation result, and any declared gap.
Conflicting findingsApply a predefined conflict rule or route the disagreement to a person.The competing findings and the decision or escalation taken.
Coordinator stateProtect the goal and checkpoint progress so the run can resume from known state.The last recoverable state and its linked trace.

There is no virtue in pretending every interruption can be automated away. A sound design separates the conditions it can repair from the conditions it must surface. It then preserves enough evidence for an operator to decide whether to retry, resume, change the assignment, or stop the run. That is what makes an agent's autonomy bounded in practice rather than only in a diagram.

04

Place the human gate before the consequential action

Human review is not a single setting that is either on or off. In an agent workflow, it is a gate placed before the action whose risk or irreversibility requires accountable judgment. The gate pauses the run so a person can review the proposed action, the information that led to it, and any exception recorded in the control loop.

That does not mean a person needs to inspect every low-stakes step. Routine, reversible actions can be sampled rather than held behind a universal approval queue. The architectural point is proportionality: reserve the pause for the point at which a bad autonomous action would be difficult to undo or would carry material consequences. The system can still move quickly where the consequence is low, while keeping responsibility visible where it matters.

Checkpoint placement also changes the quality of the handoff. A reviewer should receive more than a recommendation in isolation. The run should make available the goal, the actions taken, the coverage status, the remaining gaps, and the trace that connects them. A person cannot meaningfully approve an action if the system hides the evidence needed to understand what it is asking them to approve.

A control-loop test before autonomy expands

Before asking an agent to coordinate work across several actions or subagents, ask:

  1. Who owns the goal, the decomposition, and the final synthesis?
  2. What exactly is dispatched, and what result structure must return for each unit to count as complete?
  3. How will the system reconcile requested units, valid returns, pending work, failures, and declared gaps?
  4. Which failures can be retried or re-routed, and which must be surfaced to an accountable person?
  5. What state must be checkpointed so a failed coordinator can resume rather than restart ambiguously?
  6. Can one trace connect the goal, delegated work, recoveries, and final outcome?
  7. Which proposed action needs a human gate because it is high-stakes or difficult to reverse?

A useful agent does not merely pursue a goal. It keeps the operation oriented while the route changes: observe the state, compare it with the expected coverage, correct recoverable failures, and stop for human judgment where the decision deserves it. That is the difference between a promising autonomous demonstration and a system an organisation can responsibly operate.

Field note / 05

Autonomy earns trust when the system can account for the work it set in motion.

Back to all field notes