Dev's math suggests the supervisor LLM drove most of a reported 70% token cut, if handoff truly costs zero tokens

Count tokens in the design the post is arguing against. A coordinator that re-reads the whole history at each step pays for the first step's context once, the second step's twice, and onward; across 40 steps that is about 820 units of one-step context where fixed-size receipts cost 40 ^[17]. Twenty times, on the coordinator side alone. The reported saving is 70%, which is about 3.3 times on the total ^[18]. Both fit together if the worker calls were already a large share of the spend: with a zero-token handoff, a 70% drop leaves the workers at roughly 30% of what you paid before ^[19].

So the figure travels to shops whose coordinator was about seven-tenths of the spend ^[19]. That holds where workers return short structured results and the workflow runs deep ^[15]. It does not hold where each worker call carries a large context of its own; there the coordinator is a small share, and what the machine gives you is the bounded loop. The post does not include the workload, the model, or the baseline token counts behind the 70% ^[20].

The author's division of labour holds up. LLMs are credited with fuzzy cognitive translation, meaning ambiguous intent, unstructured tool output, and writing code or summaries ^[16]. "They are remarkably inefficient and unreliable at finite state routing," the author wrote ^[6].

Replacing the prompt means writing a table of names. The receipt type allows four statuses, COMPLETED, FAILED, NEEDS_HUMAN and RETRYABLE_ERROR ^[8], and the posted machine listens for seven events across plan, execute, verify, repair and two final states ^[11]. Every new way a worker can fail needs a status, an event and an edge before a run can continue past it. Before, that constraint was a sentence in a prompt ^[10].

Repair escalates to a human when context.repairCount reaches 3, written as an always transition with a guard ^[12]. Read that ceiling closely. The published snippet mentions repairCount only inside that guard ^[13]. Something outside the snippet has to increment it on each pass through repair, or the counter stays at zero and the loop the guard exists to bound keeps going.

A fast intent classifier maps the request to the initial state, and the handoff after it is labelled zero-token ^[14]. So there is still a model at the front of the pipeline. The component that used to inspect intermediate output and choose the next agent is gone, and no later step reads the request again ^[1]. A misclassified request then executes cleanly down the wrong branch, and the receipts will record that it did so correctly.

Adopting the audit change costs the least. Each receipt carries stepId, agentName, durationMs, input and output token counts, a nextTrigger and artifactHashes ^[8], while the raw transcript is sealed into a session log on disk or in object storage and only the receipt moves forward ^[9]. That answers a customer asking why the agent ran a database update from a transition log instead of thousands of lines of chatter ^[4]. In my view the receipt is worth shipping before the state machine, since per-step tokensConsumed ^[8] is what tells you whether your own coordinator was ever 70% of the bill ^[19].