handoff size
—
—
When one agent delegates to another it writes a paragraph, and that paragraph is a real line on your bill. Replacing it with a typed dependency graph — goals, entities, tool calls, and edges saying which step waits on which — cuts a customer-service handoff from 730 tokens to 226 and lifts task success by 12.7 points. Force the same format everywhere and a benchmark full of tasks that need the agent to iterate or interpret free text drops 14.6 points, because a graph node cannot say "use your judgement". The fix is not a better format. It is a 155-token classifier that picks one per delegation, and it keeps every win while erasing every loss.
In a planner-executor system the planner reads the task, works out what needs to happen, and writes it to the executor in prose. That prose gets re-sent on every step the executor takes, so it is not a one-off cost. The same delegation expressed as a typed graph is a fraction of the size — but how much smaller depends entirely on what kind of task it is. Pick a benchmark and watch the compression change.
Compression and benefit do not move together. The multi-app benchmark compresses almost not at all — 1.04× — and is also the one where forcing the graph destroys accuracy. That is the first hint that format should be a decision rather than a default: when a task will not compress, it is usually because it genuinely needs the prose.
The graph is not free-form JSON. Nodes carry one of eight types — goal, constraint, entity, action, precondition, postcondition, tool_call, tool_arg — and edges one of seven relations, including depends_on, targets, requires, blocks and follows. What the format buys is not brevity so much as an unambiguous order: a chain of depends_on edges says the customer lookup must finish before the order query, which a paragraph only implies. Flip between the two renderings of the same delegation.
One detail decides whether any of this works: the receiving agent's own prompt has to explain the schema. Hand the same graph to a standard executor prompt with no interpretation guidance and the gain disappears entirely — restoring roughly eighty tokens of "here is how to read a graph" is what turns a below-baseline result into +12.7 points. If you adopt the format, the executor prompt is part of it.
On the multi-app benchmark, forcing every delegation through the graph costs 14.6 points against prose. The breakdown by task type is unusually clean and explains why: the graph wins on exactly one category and loses on the other four. Step through them.
The failure the paper singles out is a playlist-updating task where the user's instruction is a free-text suggestion the agent has to interpret loosely. There is no node type for "be flexible", so the planner commits to one reading, the graph freezes it, and the executor cannot back out of it. Rigid structure is exactly as good as the plan that produced it.
The router is one small classifier call before each delegation, with a single domain-agnostic instruction and no benchmark-specific examples: choose the graph when the task needs deterministic answers that depend on ordered sub-tasks — aggregations, multi-step lookups, sequential API calls — and prose when it needs iteration, conditionals, free-text interpretation, or adaptive reasoning. It defaults to prose when unsure, runs at temperature zero, and produced identical decisions across three repeat runs. Total overhead 0.15%.
The routing rates are the interesting output. On three benchmarks the router sends everything to the graph; on the multi-app one it sends 11%; on the airline variant, 2%. It is not splitting traffic evenly — it is identifying a narrow class of ordered, deterministic delegations and leaving the rest alone. On the multi-app benchmark it catches all fifteen aggregation tasks and wrongly diverts fifteen of the other 137.
The production shape is a planner that hands work to a tool-using executor many times a day, with the handoff re-sent on each executor step. Set your own volume below. The compression ratio and the accuracy effects are the paper's measured numbers for whichever benchmark profile most resembles your traffic; the delegation counts and the price are yours.
Do not size this on the token saving. On the customer-service profile the tokens are worth having, but the reason to build it is +12.7 points of task success — a change in how many delegations complete at all, which is a different order of value from a cheaper message.