Who owns control at each hop

Lesson 2 of 5 in Orchestration End to End: One Request Through the Whole System.

The single most useful artifact you can produce for a multi-hop system fits on one page. For every hop, write down which side decides what happens next: your code, or the model. Call it the control ledger.

It sounds trivial. It is the thing that is wrong in most systems that misbehave in confusing ways, because control flow is usually not decided — it is inherited from a framework default, a copied example, and one late-night retry wrapper.

The control ledger for the order-exception resolver
Hop	Who decides next	How the decision is expressed	If you got this backwards
Classify	Model labels, code dispatches	Structured output: one label from a closed set, plus confidence	A model that picks its own next handler is doing a handoff, not classification — and you have lost the fallback route
Resolve entities	Code, entirely	Straight-line lookups; failure raises	A model-driven resolution loop can spend six turns and still be wrong about which order it is
Fan out	Code	The branch set is known at design time: three warehouses, one research task	Paying an orchestrator to rediscover a constant every run. Model-planned fan-out is for genuinely unpredictable subtask sets
Inside the subagent	Model, bounded	A real loop with a tool set, a turn cap, and a required output shape	Turning research into a fixed chain removes exactly the adaptivity you delegated for — and an uncapped loop turns it into an open budget
Merge	Code decides precedence; model may summarise	An explicit rule: entitlement constrains remedy; availability constrains promise	A model asked to “reconcile these” will produce a fluent answer that quietly picks a side, differently on each run
Propose remedy	Model	Structured proposal: remedy type, quantity, cost, justification, citation	Hard-coding the remedy matrix is legitimate — but then you have a workflow and should stop calling it an agent
Approval gate	Code	`cost > limit` evaluated in code, on the proposal’s actual fields	The classic: asking the model whether it needs approval. An injected instruction, or an optimistic cost estimate, is now your control
Stop the run	Code owns the outer bound; model may finish early	A `done` tool the model may call, inside a hard cap on turns, spend, and wall-clock	Two authorities disagreeing about when the run is over — the ping-pong below

The two-loop problem: when nobody owns control, everybody does

A framework supplies an agent loop. Your service wraps calls in a retry. An orchestration layer adds its own “if the step did not produce output, run it again”. Each is reasonable alone. Together they produce three signatures that are miserable to debug:

Double execution. The inner loop’s tool call times out on the client side but succeeds server-side; the outer retry runs the step again. Two shipments, one order. This is not a rare tail event — client timeouts on slow ERP calls are the expected case, which is why idempotency belongs in lesson four rather than in an appendix.

Ping-pong non-termination. The model calls done; the outer layer sees an empty result field and re-invokes; the model calls done again. The run burns its budget agreeing to stop.

Caps that do not compose. The inner loop caps at 10 turns, the outer retries 3 times, so your real bound is 30 turns and your dashboard says 10. Every bound that exists in two places is a bound you do not have.

The fix is boring and effective: name one owner per hop, write it in the ledger, and make every other layer pass through rather than decide. Where two layers genuinely must both retry, make the outer one’s retries visible to the inner one’s budget — a shared retry budget rather than two independent counters.

Three questions to ask at any hop

1. Who decides what happens next here? If two answers come back, that is a bug you have not hit yet.

2. What is the bound, and where is it enforced? Turns, spend, wall-clock. In code, checked before dispatch — not in the prompt, where it is a suggestion.

3. What does “done” mean at this hop, and who is allowed to say it? A hop whose exit condition is “the model stopped producing tool calls” has no exit condition when the model keeps producing them.

How do I know if a hop should be model-owned at all?

The state-machines-vs-loops test, applied per hop rather than per system: can you enumerate the valid next steps in code? If yes, code should choose — you gain determinism for free. If the set genuinely depends on what was just observed, the model earns the decision. Most real systems are a mix, hop by hop, and the mix is the design.

What about frameworks that hide the loop?

You still owe the ledger; you just have to read source or docs to fill in the rows the framework owns. That is the abstraction debt coming due: a hidden loop is still a control decision, made by someone who never saw your requirements. If you cannot determine from the docs who decides when a step is retried, treat that as a finding, not a detail.

Does the ledger change when a subagent is involved?

It gains rows. A subagent is a hop with its own internal ledger — and two boundaries: the brief going in, and the result coming back. Both boundaries need an owner. The commonest omission is who decides the subagent has failed: if the parent waits on a subagent whose own cap is larger than the parent’s deadline, the parent’s deadline is decoration.

Key terms: control flow, model-directed control flow, max turns, retry budget, stopping condition

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.