A Pipeline Is What It Refuses to Forward

“The fundamental problem of communication is that of reproducing at one point either exactly or approximately a message selected at another point.” — Claude Shannon, A Mathematical Theory of Communication (1948)

The first stage of my code reviewer hands the next one a two-field object: a rule id and a citation. Not its reasoning. Not the file it just read. Two fields.

That’s the design decision I want to talk about, and at the time I made it I couldn’t have told you it was interesting. I did it for the bill.

BLUF

• The lever isn’t the split, it’s the seam. What each stage refuses to forward is where the behaviour changes — the stage count on its own decides nothing.
• There’s a hard version of that, and it’s someone else’s result. With unlimited relay bandwidth a multi-agent system can forward everything and reproduce a single agent exactly. So a real multi-agent advantage has to come from the relay being limited (Yu et al., 2026).
• The target is “near-sufficient” — enough to do the job, not enough to re-litigate it. Forward too much and the next stage re-derives a decision already made. Forward too little and it improvises the part you dropped.
• It’s a per-seam property, not a system property. “Is my pipeline well-factored?” is the wrong question. Every seam gets its own answer. (That reading is mine, not theirs.)
• There’s a test you can run before building anything: name what the receiving stage checks, delete everything the answer doesn’t mention, see if it still works.
• It has an expiry condition, and it points at me. The gains are strongest for weaker models and shrink — or invert — for stronger ones, which exploit redundant context fine. My pipeline is a bet that the model is weak enough to need it.
• Honest scope: I bounded my relays for cost. I have no isolated figure for what the narrowing alone bought, and no evidence at all that it made the outputs better. Everything past the receipt is Yu et al.'s result or my extension of it, labelled as such.

What crosses the seam

The concrete shape, genericised. Each stage forwards only a projection of what it knows:

• the scout hands the gate {rule, cite} — not its reasoning, not the file
• the gate hands the deep pass the surviving candidates plus the cited slice — not whole files
• the deep pass hands the decision step the features it extracted — not the slice it read
• the decision step hands the writer a verdict and a rule id — not the argument that produced it

Nothing downstream sees the whole diff again after the scout. Each stage gets a typed payload carrying what the next stage needs, and nothing else.

The honest reason is less flattering than the one I’d like to claim: I did it for cost. Handing every agent the whole context is the easy thing; curating what each one receives is the cheap thing, and the bill is what drove the change. I had a hypothesis alongside it — that recall would improve too, because there’s less to attend to — and it stayed a hypothesis.

Be precise about how thin the receipt is, because it’s thinner than the argument built on it. The narrowing shipped alongside other changes to the same pipeline, so I have no isolated figure for what it bought on its own; I can’t split that bill. What I have is a bounded-relay pipeline that is built, running, and cheaper than the thing it replaced — and no evidence whatsoever that the outputs got better. A system that got cheaper and also got better tells you nothing about which change did what.

The reason it’s worth writing down anyway is that somebody ran the controlled version, and what they found is sharper than my hunch was.

The condition

Yu et al. frame it as an information bottleneck. A single agent keeps its whole trace in one shared context. A multi-agent system splits the work into isolated local contexts connected only by what they call “bounded relay messages.” Then the observation: if relay bandwidth is unlimited, the multi-agent system can reproduce any single-agent system by forwarding everything. It collapses. Whatever advantage composition has must come from the relay being limited.

Which turns the question I ask about my own pipeline from “did I split this well” into “what did I refuse to forward, and why.” If the answer at some seam is “nothing, really,” that seam isn’t doing work. It’s a function call with a network hop and a model bill attached.

They find the payoff lands when relays are “near-sufficient” — enough for the next stage to do its job, not enough for it to redo the last one. Both directions off that strip cost you: forward too much and the receiving stage re-derives a judgment made upstream, forward too little and it improvises the gap. Their evidence is 18 controlled experiments across five benchmarks and three model scales — a real dose of it, and theirs, not mine.

Why over-forwarding costs is my reading rather than their result, and worth separating out: a re-derived judgment costs more than the tokens it burns. It’s a second opinion, differently wrong, arriving to compete with the first. That’s reasoning from the shape of the thing. I haven’t isolated it.

The part I’d add is an extension, not their finding: near-sufficiency is a property of each seam, not of the architecture. My gate→deep seam and my decision→write seam aren’t the same problem. The deep→decision seam carries extracted features because the decision step only needs the features. The gate→deep seam needs the cited slice, and dropping it would be catastrophic. There’s no global setting to tune. There are four seams and four answers, and I set each one by hand.

The test

Which gives you something to run before you build anything.

For every seam, answer one question: what does the receiving stage check? Then delete everything the answer doesn’t mention and see whether it can still do its job.

If it can, that’s your relay — freeze it as a type so it can’t quietly widen back out. If it can’t, add back the smallest thing that fixes it, and now you know what that seam is for. And if you can’t answer the question at all, you don’t have a pipeline. You have a queue of agents re-reading the same diff.

The freezing matters as much as the deleting, because relays widen by default. Every seam I’ve ever debugged, the temptation was to pass one more field so the next stage would stop getting it wrong — and one more field is always locally correct and cumulatively how you end up back where you started.

The expiry condition

Now the part that cuts against me.

The same work finds the effect is capability-dependent: strongest for weaker models, shrinking — or inverting — when relays drop information, particularly for stronger models, which exploit redundant context well and gain little from having it compressed on their behalf. They call the parameter β. It tracks how the balance moves with capability.

Take that seriously and my architecture has a condition attached: the pipeline is worth its complexity only while the model is weak enough to need it. Every seam I bounded is a compression I’m performing for the model, and a strong enough model would rather I didn’t.

Same shape as the deletion route in A Big Rule Set Is an Attention Problem — where Anthropic’s reported removal of most of Claude Code’s system prompt for their more advanced models, with no measured loss on their evals, is cited in full — but aimed a layer down. There, the capability-conditional thing to delete was a rule. Here it’s a seam.

So here’s the ablation, which I have described and not run: take an adjudicated fixture set — planted defects, known answers — and run it twice. Once through the pipeline as built. Once with one stage handed the full context that seam currently keeps from it. Count confirmed true findings against the known answers, not verdict changes, because a verdict that moved isn’t a verdict that improved. If the wide version doesn’t win, the seam is earning its keep. If it does win, that relay was too narrow and I’ve been paying to compress something the model wanted whole.

I don’t know which way that goes for my pipeline. It is a cheap experiment and I haven’t run it, which is the most honest thing in this post.

The point

Stage count is a diagram. The payload is the design. Every seam is a decision about what the next stage is not allowed to know — and if you didn’t make that decision on purpose, the default made it for you.

So the question I’d start with on any pipeline with a model in it isn’t how many stages it has. It’s what each stage refuses to forward — and whether a better model would want it back.

---

How sure I am: the bounded-relay pipeline is real and running, genericised — typed projections on every seam, no stage seeing the whole diff after the scout. Cost was the motive and the pipeline is cheaper than what it replaced, but I have no isolated figure for the narrowing alone — it shipped with other changes and I can’t apportion the saving. That it improved recall, determinism, or anything else about the outputs is a hypothesis I have not tested, and nothing here should be read as evidence for it. The bounded-relay condition, the “near-sufficient” target, the 18-experiment evidence base, and the capability inversion are Yu et al.'s, cited with their scope intact — including the half that cuts against me. The Anthropic deletion figure is theirs and is sourced in full in the linked post, cited here only for the shape of the move. What’s mine and unmeasured: reading near-sufficiency as per-seam rather than system-wide, the delete-what-isn’t-checked test, the relays-widen-by-default warning, the account of why over-forwarding costs, and the ablation I’ve specified but not run. And the expiry condition is an inference, not a measurement — Yu et al. measured the capability effect across their benchmarks and model scales, not on my pipeline. That mine specifically is worth its complexity only while the model is weak enough to need it is me applying their result to a system they never saw. It’s the reason I wrote down the ablation instead of asserting the conclusion.

Sources

• Claude Shannon, A Mathematical Theory of Communication (1948) — the epigraph; a framing, not a load-bearing cite.
• Yu, Zhou, Dong, Barath, Staunton, Yoon, Qian, Caverlee & Ji, When Do Multi-Agent Systems Help? An Information Bottleneck Perspective (2026), arXiv:2607.16133 — a multi-agent system’s local contexts are linked only by “bounded relay messages”; with unlimited bandwidth it can forward everything and reproduce a single-agent system, so the advantage must come from limited relays. Gains land when relays are “near-sufficient,” are strongest for weaker models, and shrink or invert when relays drop information, particularly for stronger models; an effective parameter β tracks the shift with capability. 18 controlled experiments, five benchmarks, three model scales. Their result and their scope; the per-seam reading and the design test built on it are mine.
• Thariq Shihipar, The New Rules of Context Engineering for Claude 5 Generation Models (claude.com blog, 24 Jul 2026) — the capability-conditional deletion route, cited here for its shape; the figure, the scope, and the eval caveat are handled in A Big Rule Set Is an Attention Problem.

---

Related: Keep the Factory, Ship the Result (which stages hold a model — this post is what crosses between them); Your Skills Are One-Offs (the same typed artifact, argued for portability rather than bandwidth); A Big Rule Set Is an Attention Problem (the same capability-conditional deletion, aimed at a rule instead of a seam).