You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the server hands an agent its next piece of work, it builds that payload on the spot. It annotates each step with where its inputs come from, which means re-reading essentially every set of instructions in the workflow from disk, once per step it inlines — one observed call walked the whole catalogue three times. Then it sends the result, and if the recipient already holds most of it, a separate mechanism tries to notice.
This epic builds the payload once instead. Every deliverable block is composed ahead of any session and addressed by a hash of its own bytes, so a delivery becomes a list of addresses plus only the bytes the recipient lacks.
Four separately-filed defects collapse into that one change: the same block appearing twice inside one response, a repeated request answered in full, an activity body that cannot collapse when everything around it can, and the composition itself being redone on every request. Each has been measured, and the measurements are what the acceptance criteria are written against.
How the cost arises today
Composition is redone per request. The routine that annotates a step walks every activity and step in the whole workflow, not just the one being delivered; for each bound operation it re-reads the instruction file from disk to learn what it produces; and the small memo it keeps lives only inside a single call. The delivery loop invokes that routine once per ungated step, so the work per request scales as the count of all the workflow's instruction files multiplied by the count of ungated steps. A delivery still completes in roughly 60 to 130 milliseconds; the concern is the growth curve, and the catalogue only grows.
The same block ships twice inside one response. 16,453 characters byte-identical in the worst case measured. The pass that would remove them runs only when a delivery is made by reference, so a freshly spawned worker — exactly the case the budget is tightest for — pays all of it.
A repeat request is answered in full. A worker asking for something it already holds receives the whole body a second time. The collapsing that prevents this on activity deliveries does not cover requests made on demand, so nothing recognises the second ask. One worker received the same 15,126-character payload twice inside 46 seconds, in one uninterrupted run. Across one run that is 18 repeats and 67,772 characters re-sent — roughly 17 thousand tokens, and 12 to 17 per cent of everything that run fetched on demand.
The activity body is the one part that never collapses. When a resumed worker asks for its activity again, almost everything can arrive as a short marker — each bundled instruction set, the inherited rules block, each shared block, each eagerly bundled resource. The activity definition itself cannot: it is concatenated onto the response outside the addressing scheme, so no lookup happens and no marker is possible. Measured over eight activities of the main workflow, a resumed delivery totals 184,684 characters of which 70,957 — 38.4% — is the body, and the share runs from 17% on an activity binding many instruction sets to 95% on one binding few. Thirteen of the main workflow's fifteen activities carry a gate, so a worker pausing at several pays the body at each.
A ceremony's persistence is paid one commit at a time. After every setup activity the orchestrating role runs a roughly two-minute commit-and-push cycle.
The work
W1 — Compose each instruction set once per delivery. Build the map from each reference to what it produces once per request and reuse it across every step; stop rebuilding the producer list per step. The annotation output stays byte-for-byte unchanged and a regression test counts how many times composition runs. This is worth doing on its own terms and it is also the inner loop of W2, so it is not thrown away when W2 lands.
W2 — Compose the corpus ahead of any session, addressed by content. Every composed instruction set, every merged rule block and every resource section is built at load and addressed by a hash of its own bytes, before any session opens. Two identical blocks are one address by construction rather than by a pass that has to notice them.
W3 — A delivery names addresses and sends only what is missing. The recipient's holdings are tracked as they are today; what changes is that everything is addressable, including the activity body. The body keeps its identity fields in full, since a worker has to confirm the activity it received is the one it was dispatched for and that check reads the body — the step list, outcome and synthesised artifact contract are addressed separately, the treatment a composed instruction set already gets. A request for something already held returns an address rather than the bytes, on every path rather than only on activity deliveries.
W4 — The bodies a call names arrive with the caller. The pipeline that already sends along the templates and reference documents an instruction set mentions is pointed at instruction references too. Bodies arrive deduplicated within the delivery budget, followed transitively, and tolerant of a reference leading back somewhere the walk has already been rather than failing the load on one — which matters because three operations in the corpus name each other and one names itself, and all three are correct as authored. Under content addressing this costs a list of addresses rather than a second copy of anything.
W5 — The ceremony commits once. Batch the setup sequence's persistence steps into a single commit when the client workflow is dispatched, rather than one cycle per activity.
Why now is cheap
The evidence is gathered, re-verified and specific. Four sessions' runtime logs profile the waste pattern; a check against the current code confirms the composition path is unchanged since the defect was first filed; and each of the four collapsing defects carries its own measurement rather than an estimate.
The measurements are already instrumented. Characters delivered and characters saved are both summable from the session record; every delivery emits a cost line; and the benchmark that prices a definition change runs on every pull request. The acceptance criteria below are reads against instruments that exist.
Four defects become one change. They were filed separately because they present separately, but the same cause produces all four: payloads composed per request rather than compiled once. Fixing them one at a time means building three mechanisms that the fourth removes.
The multiplier grows with the corpus. The same fix costs more to validate the longer it waits.
Acceptance criteria
A single delivery composes each instruction set at most once, with the annotation output byte-for-byte unchanged and a regression test counting composition runs.
Composition happens ahead of any session, and every deliverable block is addressed by a hash of its own bytes.
No byte-identical block appears twice in one response, against a worst case of 16,453 characters measured today.
A context that asks twice for the same instruction set or resource receives the second answer as an address, with a regression test that asks twice and measures what came back — against a baseline of 18 repeats and 67,772 characters in one measured run.
A resumed delivery returns the activity's identity in full and the remainder as addresses where the bytes are unchanged, the dispatched-activity confirmation still has an identifier to check on every path, and a forced full delivery is unaffected — against a measured body share of 38.4% and a range of 17% to 95%.
The cost of a path can be computed from the compiled corpus without running it.
The bodies a call names arrive with the caller, deduplicated, transitively followed, and tolerant of a walk that returns to a body already reached.
The setup ceremony produces one commit, and a re-measurement by the recorded method shows it.
Re-delivered characters are reported against the recorded baselines — 677,132 characters at gate crossings, plus 1,109,551 on same-identity resumes that re-delivered a byte-identical payload.
Non-goals
Confirming the old mechanism's effect on production runs. A sampling exercise gated on roughly ten completed sessions measured the delivery-identity mechanism this epic replaces. Its 677,132-character baseline is carried into the criteria above, where it is answered statically rather than sampled.
Batching activities into one dispatch. The cost batching spreads is the establishment of a fresh context, and by this point one context stays alive across a run.
Teaching agents to fetch cheaply. By this point agents do not fetch.
Redesigning which steps are gated. What a definition says is not this epic's subject.
A threshold on the fan-out ratios. They are reported from the first stage of the transition and stay warn-only.
The eager budget's behaviour. A resumed delivery can be larger than its collapse suggests, because addresses cost nothing against the budget and freed headroom is spent sending resource bodies the first delivery could not afford. That is the budget working.
Tracking
Each work item is delivered as its own pull request when picked up.
Work item
Agent time
State or gate
[x]
W1 — compose each instruction set once per delivery
Item hours and epic effort-days are defined in #527.
W1 and W5 are independent of the rest and can be picked up at any point, including before this epic's turn in the running order — W1 in particular is a pure improvement to the current path and its work survives into W2.
Carries #404 W1, W5, W7, W9 and W10, #526 W5, and #397 W3a. #404 and #526 are closed and captured in the planning folder; #397 stays open for its remaining items.
Investigation detail
The status check with hot-path locations, the composition-caching capture, the repeat-request tables, the activity-body measurement and the delivery-identity baseline: 2026-08-02-delivery-cost-epic
Summary
When the server hands an agent its next piece of work, it builds that payload on the spot. It annotates each step with where its inputs come from, which means re-reading essentially every set of instructions in the workflow from disk, once per step it inlines — one observed call walked the whole catalogue three times. Then it sends the result, and if the recipient already holds most of it, a separate mechanism tries to notice.
This epic builds the payload once instead. Every deliverable block is composed ahead of any session and addressed by a hash of its own bytes, so a delivery becomes a list of addresses plus only the bytes the recipient lacks.
Four separately-filed defects collapse into that one change: the same block appearing twice inside one response, a repeated request answered in full, an activity body that cannot collapse when everything around it can, and the composition itself being redone on every request. Each has been measured, and the measurements are what the acceptance criteria are written against.
How the cost arises today
Composition is redone per request. The routine that annotates a step walks every activity and step in the whole workflow, not just the one being delivered; for each bound operation it re-reads the instruction file from disk to learn what it produces; and the small memo it keeps lives only inside a single call. The delivery loop invokes that routine once per ungated step, so the work per request scales as the count of all the workflow's instruction files multiplied by the count of ungated steps. A delivery still completes in roughly 60 to 130 milliseconds; the concern is the growth curve, and the catalogue only grows.
The same block ships twice inside one response. 16,453 characters byte-identical in the worst case measured. The pass that would remove them runs only when a delivery is made by reference, so a freshly spawned worker — exactly the case the budget is tightest for — pays all of it.
A repeat request is answered in full. A worker asking for something it already holds receives the whole body a second time. The collapsing that prevents this on activity deliveries does not cover requests made on demand, so nothing recognises the second ask. One worker received the same 15,126-character payload twice inside 46 seconds, in one uninterrupted run. Across one run that is 18 repeats and 67,772 characters re-sent — roughly 17 thousand tokens, and 12 to 17 per cent of everything that run fetched on demand.
The activity body is the one part that never collapses. When a resumed worker asks for its activity again, almost everything can arrive as a short marker — each bundled instruction set, the inherited rules block, each shared block, each eagerly bundled resource. The activity definition itself cannot: it is concatenated onto the response outside the addressing scheme, so no lookup happens and no marker is possible. Measured over eight activities of the main workflow, a resumed delivery totals 184,684 characters of which 70,957 — 38.4% — is the body, and the share runs from 17% on an activity binding many instruction sets to 95% on one binding few. Thirteen of the main workflow's fifteen activities carry a gate, so a worker pausing at several pays the body at each.
A ceremony's persistence is paid one commit at a time. After every setup activity the orchestrating role runs a roughly two-minute commit-and-push cycle.
The work
W1 — Compose each instruction set once per delivery. Build the map from each reference to what it produces once per request and reuse it across every step; stop rebuilding the producer list per step. The annotation output stays byte-for-byte unchanged and a regression test counts how many times composition runs. This is worth doing on its own terms and it is also the inner loop of W2, so it is not thrown away when W2 lands.
W2 — Compose the corpus ahead of any session, addressed by content. Every composed instruction set, every merged rule block and every resource section is built at load and addressed by a hash of its own bytes, before any session opens. Two identical blocks are one address by construction rather than by a pass that has to notice them.
W3 — A delivery names addresses and sends only what is missing. The recipient's holdings are tracked as they are today; what changes is that everything is addressable, including the activity body. The body keeps its identity fields in full, since a worker has to confirm the activity it received is the one it was dispatched for and that check reads the body — the step list, outcome and synthesised artifact contract are addressed separately, the treatment a composed instruction set already gets. A request for something already held returns an address rather than the bytes, on every path rather than only on activity deliveries.
W4 — The bodies a call names arrive with the caller. The pipeline that already sends along the templates and reference documents an instruction set mentions is pointed at instruction references too. Bodies arrive deduplicated within the delivery budget, followed transitively, and tolerant of a reference leading back somewhere the walk has already been rather than failing the load on one — which matters because three operations in the corpus name each other and one names itself, and all three are correct as authored. Under content addressing this costs a list of addresses rather than a second copy of anything.
W5 — The ceremony commits once. Batch the setup sequence's persistence steps into a single commit when the client workflow is dispatched, rather than one cycle per activity.
Why now is cheap
The evidence is gathered, re-verified and specific. Four sessions' runtime logs profile the waste pattern; a check against the current code confirms the composition path is unchanged since the defect was first filed; and each of the four collapsing defects carries its own measurement rather than an estimate.
The measurements are already instrumented. Characters delivered and characters saved are both summable from the session record; every delivery emits a cost line; and the benchmark that prices a definition change runs on every pull request. The acceptance criteria below are reads against instruments that exist.
Four defects become one change. They were filed separately because they present separately, but the same cause produces all four: payloads composed per request rather than compiled once. Fixing them one at a time means building three mechanisms that the fourth removes.
The multiplier grows with the corpus. The same fix costs more to validate the longer it waits.
Acceptance criteria
Non-goals
Tracking
Each work item is delivered as its own pull request when picked up.
Item hours and epic effort-days are defined in #527.
W1 and W5 are independent of the rest and can be picked up at any point, including before this epic's turn in the running order — W1 in particular is a pure improvement to the current path and its work survives into W2.
Carries #404 W1, W5, W7, W9 and W10, #526 W5, and #397 W3a. #404 and #526 are closed and captured in the planning folder; #397 stays open for its remaining items.
Investigation detail
The status check with hot-path locations, the composition-caching capture, the repeat-request tables, the activity-body measurement and the delivery-identity baseline:
2026-08-02-delivery-cost-epic
The minute-by-minute setup timeline, the ceremony duration series, and a withdrawn delivery-growth figure recorded so it is not re-derived: 2026-08-06-startup-cost-on-real-runs. The running order and item-by-item disposition: 2026-08-31-typed-execution-redesign.