Five sequential agents with growing context buy nothing

The proposal is two pages and it is better written than most. Ledgerline produces a quarterly risk report for each of its larger merchants — an executive summary, a volume-trends section, a chargeback analysis, a fraud-signals section, and a set of recommendations — and today a single loop writes all five from a brief containing the quarter's metrics. The proposal is to split it into five agents, one per section, running in sequence, each receiving the original brief plus every previous agent's full output. The stated benefits are separation of concerns and the ability to evaluate each section independently. There is a rollout plan, a diagram, and a paragraph about how this will make the system easier to reason about as more sections are added.

The first number to put next to it is the window size at each stage, because the proposal's own handoff rule determines it and nobody has written it down.

The split's windows are slightly larger at every stage, which is not a rounding artifact. A single loop writing section four has its own three previous sections in the window as generated tokens and nothing else; agent four receives the same three sections plus its own system prompt, plus the wrapper text a handoff needs to say which output is which, plus the brief a second time because the proposal passes it to every agent. The split therefore does not reduce any window, and by the standard set out at the end of the last chapter it has failed the first of the three tests. It fails the second by construction, since the agents run in sequence and the wall-clock is the sum of five calls rather than the maximum of anything. The third test is open until someone measures it, and the proposal contains no measurement.

Pricing the thing before arguing about it#

The single loop makes one call: 3,200 input tokens, about 6,800 output tokens, 74 seconds. The split makes five: 36,500 input tokens in total, the same 6,800 output distributed across them, and 96 seconds including handoff overhead. At $3 per million input and $15 per million output that is $0.111 against $0.112, so the token cost is a wash and anyone arguing this on price will lose the argument. Prompt caching does not help the split much either, because each agent's prefix differs from the last one's by the previous section, so the cacheable portion is only the brief.

The costs that matter are the ones that do not appear on the invoice. Five prompts have to be kept consistent with each other, and the failure mode when they drift is a report whose sections use different terminology for the same metric. Retry semantics become a design question: if agent four fails, the outputs of agents one through three either have to be persisted somewhere durable or regenerated, and regenerating them produces different text, so a retried report is not the report that was half-written. Chapter 6's arithmetic applies to the failure rate as well, though gently at this scale — five calls at a 0.4% per-call failure rate means about 2% of reports have a failed stage, against 0.4% for the single call, so the split multiplies the report-level failure rate by five while buying nothing that offsets it. And the trace becomes five spans, five separately recorded steps, that someone has to correlate to answer the question "why does this report say that".

Then there is the quality direction, which the proposal does not consider and which the earlier chapters predict. Every agent after the first is conditioned on the full text of the sections before it, which is the arrangement chapter 1 described, applied four times. Ledgerline ran the split against the single loop on 30 stored briefs before the review concluded. Verbatim phrase overlap between sections rose from 4.1% to 11.3%, because each agent has the previous sections in front of it and language leaks forward. More seriously, in 5 of the 30 reports the recommendations section proposed action on a trend that the chargeback section had explicitly described as within normal variance, having picked up the framing of the fraud-signals section that sat between them. The single loop made that error twice in thirty. Neither number is large enough to be decisive on its own, and both point the same way, which is that a chain of agents each reading the last one's prose is more likely to compound a framing than a single pass is.

Taking the separation-of-concerns argument seriously#

The author's principle is a good one and it is being applied to the wrong kind of boundary. Separation of concerns does work in a codebase, and the reason it works is enforcement: a module cannot read another module's locals, the compiler will not let it, and the interface is the only channel. That enforcement is what makes it possible to reason about one module without holding the others in your head. When the boundary is a prompt handoff whose contract is "everything the previous agents produced", nothing is encapsulated. Agent five can read every word agent two wrote, and does. The design has the vocabulary of modularity and none of the property that makes modularity useful, which is why the windows in the table above are the same size as the loop's.

The claim can also be checked against experience rather than principle, because Ledgerline had a chain of this shape elsewhere and had debugged it. When a report contained a wrong figure, the question was which stage introduced it, and answering it meant opening five spans and reading forward until the number first appeared, then reading backward to see what that agent had been given. That is more work than searching one transcript, not less, because the five spans have to be correlated by a request id and the material that explains the error is usually in a different span from the one that emitted it. The chain made the system harder to reason about in the one situation where reasoning about it mattered, and the reason is the same as the reason the windows did not shrink: there is no interface to reason against, so you end up reading everything anyway, in five pieces.

The version of this proposal that would deserve the name is available, and it is the one chapter 2 described: each section's builder takes named inputs. The volume-trends agent takes a metrics record and a prior-quarter comparison; the chargeback agent takes a chargeback table and the policy thresholds; the recommendations agent takes the findings from the three analysis sections in a structured form rather than as prose, in the shape chapter 5 specified. Writing those signatures is the work, and it is also the diagnostic, because the exercise reveals which sections genuinely depend on which upstream facts.

That graph is the report's actual dependency structure, and it is not a chain. Three of the five sections are functions of the brief alone, and the two that are not depend on the findings of those three rather than on their prose. The proposal's straight line through all five is an artifact of the order the sections appear in the document.

The other thing the author wants — evaluating sections independently — does not require a split at all. A single loop can emit its sections as separate structured fields, and a grader can score each one against its own rubric, which is a matter of tagging rather than architecture.

report = loop.run(brief, response_format=REPORT_SCHEMA)   # one call, five fields

for name, rubric in SECTION_RUBRICS.items():
    score(section=report[name], rubric=rubric, case_id=brief.id)

Per-section evaluation was the strongest argument in the proposal, and it survives the rejection of the split entirely intact, which is the sort of thing worth saying out loud in a review so the author does not hear the whole document being turned down.

Why parallelising it is not the rescue, and what to do instead#

The reflex correction is to approve the five agents but run them concurrently, which sounds like it converts a design that buys nothing into one that buys wall-clock while keeping the structure the author likes. Applied to the proposal as written, that ships a broken report. Each section is specified to be written conditioned on the previous ones, so removing the dependency does not reschedule the same work, it changes what the work is: the executive summary written first summarises nothing, and the recommendations written without the analyses are recommendations about a brief. Running the chain in parallel would produce five sections that repeat each other and occasionally contradict each other, and the reviewer who approved the parallelism without asking about the dependencies would own that outcome.

The dependency graph does contain a genuine fan-out, which is the three analysis sections. They pass both of chapter 6's checks: each one's input can be written down from the brief before any sibling runs, and the report is the same whether they are produced in any order or at once. So the honest version of the parallel proposal is three branches over the metrics record, a join that collects their structured findings, and then recommendations and the executive summary in sequence after it. That version is correct. It saves about 36 seconds on a 96-second report, which sits below the floor from the last chapter, and it costs a join, a return contract and a partial-failure policy for a report that runs four times a quarter per merchant and has no latency requirement at all. Correct and not worth building are compatible, and saying so is more useful to the author than approving it.

What to propose today is the smaller thing that the evidence supports. Keep the single loop. Add the structured section output and the per-section rubrics, which gives the author the evaluation story that motivated the proposal. Then rewrite the five section instructions, because the invoice-matching result from chapter 4 makes that the highest-expected-value change available and it costs a day. Re-run the 30 stored briefs, and if a section is still weak with a good instruction and a clean rubric, that section is now a candidate for a split with an actual measurement behind it — and it will almost certainly be one of the three analysis sections, with a builder that takes a metrics record.

There is a case in which the rejection would be wrong, and it is worth naming so the standard does not become a reflex against splitting. If the report generator grew to twenty sections and the loop's window reached 60,000 tokens by the last one, the arithmetic in the first table reverses: a builder that hands section nineteen a metrics record and three structured findings gives it a 6,000-token window against the loop's 58,000, and that is a measured reduction rather than a claimed one. The proposal is being rejected for what it is at five sections with a pass-everything handoff rule, not for its ambition. Saying which future observation would change the answer is what keeps a review from being a matter of taste, and it gives the author something specific to come back with.

The whole topic reduces to one question asked before the diagram is drawn, which is what this split will do that a single loop cannot: hold less in its window, run at the same time as something else, or do the job measurably better with the instruction held constant. The next proposal that lands is where that gets used, and the useful habit is to answer the question in the design document rather than in the review, because an author who has to write down the inherited fraction, the dependency argument or the measured difference will usually discover the answer before anyone else has to.