There Is No Such Thing as a Local Change

Change one agent's prompt or model and you have changed every agent downstream, because its output is their input. The unit of change in a multi-agent system is the whole pipeline, not the agent.

The last chapter told you to tier the models: move the mechanical agents onto a small model at roughly a tenth of the price, and reserve the frontier model for the one or two that need it. It is the right call for the bill. It is also a trap, and the trap is the subject of this chapter. The moment you swap the extractor from the frontier model to a small one, you did not just change the extractor. You changed what the reconciler reads next, because a smaller model phrases the same extraction differently, and the reconciler was tuned on the old phrasing. The saving is real. The regression it introduces is invisible until it reaches production and a filing goes out with a field the reconciler used to catch and now does not.

This is the part of operating a multi-agent system that almost never makes the tutorials. In an ordinary service you change one component, run its tests against a fixed contract, and if the contract holds you ship it without touching anything else. That intuition is load-bearing for the entire way software teams deploy, and it is wrong for multi-agent systems in a way that is expensive to learn by accident. Here, a change to one agent is a change to every agent that reads its output, and nothing in the architecture stops it from spreading. There is no such thing as a local change.

TL;DR

In a multi-agent system there is no such thing as a local change. Every agent's output is the next agent's input, and unlike a microservice the contract between them is natural language, not a typed schema, so nothing stops a change from propagating downstream. Change one agent's prompt, its model, or a tool it calls, and you have changed the behaviour of every agent below it in the pipeline, because those agents were tuned on the old output and a reworded prompt or a cheaper model phrases things differently. The unit of change is therefore the whole pipeline, not the agent, and you cannot ship it component-by-component the way service intuition says you can. Four disciplines make change safe. Version the pipeline, not the agent: pin every prompt, every model assignment, and every tool definition together as one deployable artifact with one version number. Keep a set of golden transcripts, a frozen library of real runs with known-good outputs, and replay every candidate change against them so a regression shows up as a diff before it ships. Canary on live traffic: route a slice of real runs to the new pipeline version, compare it against the old one on the metrics your observability gives you, and only promote when it holds. And pin the model version, because a "latest" alias means the vendor can change your pipeline under you with no deploy on your side. The sneakiest change of all is the cost move from the last chapter: tiering an agent down to a cheaper model is a change, and it has to go through the same regression and canary as any other, because saving money on one agent quietly rewrites the input of the next.

A change to one agent is a change to every agent downstream

Start with the mechanic, because everything else follows from it. Take the six-agent extraction pipeline this series has used throughout: a planner that routes the work, a retriever that fetches the source documents, two extraction workers that pull fields against a schema, a reconciler that merges their outputs and resolves conflicts, and a reviewer that makes the final judgment and holds the two tools that touch the outside world, finalize to the system of record and send email. The agents run in sequence, and the defining fact of that sequence is that each agent's output is the next agent's input. The reconciler does not read the source documents. It reads what the two extractors wrote about the source documents. The reviewer does not read the extractions. It reads what the reconciler concluded.

So consider what happens when you edit the first extractor's prompt to fix one bug, a field it was formatting as a date string when the schema wanted an ISO timestamp. You test the extractor. The field is now correct. You ship it. What you did not test is that the extractor, re-prompted, also now writes its confidence notes in a slightly different structure, and the reconciler's conflict-resolution logic keyed on the old structure to decide which extractor to trust when they disagreed. The reconciler still runs. It still produces output. It just resolves a class of conflicts differently now, and the reviewer, reading a subtly different reconciliation, approves a subtly different set of filings. You fixed one field and moved the behaviour of two agents you never opened. That is not a bug in your change. It is the nature of the system. The output you edited was somebody else's input.

Why microservice intuition fails here

The reason a change stays local in a normal service is the contract. When one microservice calls another, the interface between them is typed and enforced: a schema, a protobuf, an OpenAPI spec. If you change the internals of a service but its output still satisfies the contract, the caller cannot tell the difference, by construction, and the change stops at that boundary. The contract is a wall that propagation cannot cross. That wall is why you can deploy one service at a time, why you can reason about a change in isolation, and why "I only touched the billing service" is a meaningful sentence.

Multi-agent pipelines have no such wall. The interface between two agents is natural language, and natural language is not a contract you can enforce. The handoff between agents is a note one agent writes and another reads, and the reader depends not just on the facts in that note but on its phrasing, its ordering, its structure, its tone of confidence, all the things a schema does not pin down and cannot. You might impose a JSON schema on the handoff and catch the crudest breakages, a missing field or a wrong type, and you should. But the schema cannot enforce that "unclear, low confidence" and "ambiguous, needs review" mean the same thing to the downstream agent, and they might not, because the downstream agent is itself a language model reading the words. The contract that would make a change local does not exist, so the change is not local. This is the operational cost of the flexibility that made you reach for agents in the first place: the same natural-language coupling that lets the pipeline handle messy inputs is the coupling that lets a change spread through it.

The blast radius of a small prompt tweak

Put a number on how far a change reaches. In the six-agent chain, label the agents one through six in run order. A change to agent one, the planner, can propagate to all five agents below it, because everything downstream depends on how the work was routed. A change to an extractor at position three reaches the reconciler and the reviewer, two agents, and because the reconciler merges both extractors, a change to one extractor also shifts how it weighs against the other. A change to the reviewer at position six reaches no downstream agent, but it is the agent holding the tools that finalize and send email, so its blast radius is the outside world instead. The pattern is simple and unforgiving: a change to agent k can alter every one of the agents below it, and the only agent whose change is nearly contained is the last one.

Now compare the two worlds directly. In a service architecture, a change to one of six components re-validates one component, because the contract stops the blast at the first boundary. In a multi-agent pipeline, a change to one of six agents can require re-validating all six, because there is no boundary to stop it and you often cannot know in advance which downstream behaviours moved. That is the core asymmetry, and it is why a multi-agent system is genuinely harder to operate than the same logic split into services: your regression surface per change is not one unit, it is up to the whole graph. The tools your observability gives you are what let you see the blast after the fact, per-span, across the trace. The disciplines in the rest of this chapter are how you see it before it ships.

Version the pipeline, not the agent

The first discipline is to stop thinking of the agents as separately deployable and start treating the whole pipeline as one artifact. A multi-agent system is not six services you version independently. It is one system whose behaviour is determined by the combination of every prompt, every model assignment, every tool definition, and the wiring between them. Change any one of those and you have a new system, whether or not you gave it a new version number. So give it one. The deployable unit is the entire configuration: the six prompts, the six model choices, the tool schemas, the handoff formats, and the graph that connects them, all pinned together and versioned as a whole. Pipeline version 47 is a specific frozen set of all of it, and pipeline version 48 differs by exactly the change you are shipping and nothing else.

This sounds like bookkeeping, and it is, but it buys you the two things you cannot operate without. The first is the ability to say precisely what is running in production, which is the entire configuration of version 47 and not "the extractor prompt from Tuesday plus the reconciler model someone swapped in a hotfix." The second is the ability to roll back, atomically, to a version that worked, instead of trying to reconstruct which of nine independent edits made across three agents caused the regression that appeared last week. A multi-agent system fails as a system and recovers as a system, so it has to be versioned as a system. The moment your agents drift into being independently editable, you have lost the ability to reason about what your pipeline does, and with it the ability to fix it when it breaks.

Golden transcripts are your regression test

Versioning tells you what changed. It does not tell you whether the change was safe. For that you need a regression test, and the regression test for a multi-agent pipeline is a set of golden transcripts. A golden transcript is one real run, captured end to end: the input documents, every agent's prompt and output at each step, and the final result, with that final result confirmed correct by a human once. Collect a few dozen of them that span the cases you care about, the clean ones, the ambiguous ones, the adversarial ones, the ones that broke you in the past, and freeze them. That frozen set is your definition of "the pipeline still works."

The test is then mechanical. Before you promote a candidate pipeline version, replay every golden transcript's inputs through it and diff the new outputs against the known-good ones. Where they match, the change did not disturb that case. Where they differ, you have found a behaviour that moved, and now you make a decision instead of a discovery in production: either the new output is also correct and you update the golden, or it is worse and you have caught a regression before a single real filing was touched. This is the same evaluation apparatus the earlier chapter built, pointed at a new job. Evaluation measured whether the pipeline was good enough to ship at all. Golden transcripts measure whether a change kept it that way, which is the question you are actually asking every time you touch a prompt. Diffing agent outputs is harder than diffing a function's return value, because two phrasings can both be right, so the diff is a starting point for judgment, not a pass-fail gate. But a diff you review beats a regression you discover, every time.

Canary on live traffic before you roll out

Golden transcripts catch the regressions you have examples of. They cannot catch the ones your frozen set does not represent, because live traffic is always stranger than your test corpus. So the last gate before full rollout is a canary. Deploy the new pipeline version alongside the old one and route a small slice of real runs, say five percent, through the new version while the other ninety-five percent stay on the proven one. Then watch, using the per-span metrics your observability already emits: the escalation rate, the tool-error rate, the reconciler's conflict rate, the reviewer's rejection rate, the cost per run, the latency. If the new version's numbers track the old version's on the same live traffic, you promote it to a hundred percent. If they diverge, you route the slice back to the old version and you have learned it on five percent of traffic instead of all of it.

The canary is doing something the golden set structurally cannot: testing the change against the actual distribution of inputs your system sees, including the cases nobody thought to freeze. It is also the natural place to enforce the reliability discipline from earlier, because a change that shifts behaviour is a reliability event, and the canary is how you keep that event contained to a slice you can watch rather than a fleet you cannot. A silent behaviour change shipped to a hundred percent of traffic is indistinguishable, on the day you ship it, from a bug, and the canary is the difference between finding out on five percent of runs and finding out from a customer.

The model swap is the sneakiest change of all

Come back to where this chapter started, because the cost lever from the last chapter is the most dangerous change of all, precisely because it does not feel like a change to behaviour. When you tier an agent down to a cheaper model to cut the bill, you edited a configuration value, not a prompt, and it is tempting to treat a config value as safe. It is not. A different model is a different function. It reads the same prompt and produces different tokens, phrased differently, structured differently, confident about different things. Every agent downstream of the one you re-tiered was tuned, implicitly, on the outputs of the old model, and now it is reading the outputs of a new one. The cost saving is real and worth having, but it is a pipeline change and it has to travel through the same golden-set replay and the same canary as a prompt edit, because it is at least as likely to move behaviour and less likely to look like it did.

There is a second, quieter version of this that will change your pipeline while you are asleep. If you point an agent at a hosted model alias rather than a pinned version, the vendor can update the model behind that alias whenever they choose, and on the day they do, your pipeline's behaviour changes with no deploy on your side, no version bump, no golden-set replay, nothing you could have reviewed. You will see it as a mysterious drift in your metrics with no corresponding change in your repository, which is the worst kind of incident to debug because your first assumption, that nothing changed, is false. Pin the model version explicitly, so that a change to the model is a change you make, deliberately, through the pipeline you version and the gates you built, and never a change that happens to you.

Do the math on the blast radius

Add up what change management actually costs, because the number is the argument. In a service architecture, the expected cost of a change is one component re-tested: you touch one of six services, its typed contract confines the blast, and continuous integration re-validates that one unit. Call the regression surface one. In a multi-agent pipeline the same edit has a regression surface of up to six, the whole graph, because there is no contract to confine it and you cannot assume the downstream agents are unaffected. So the per-change cost of doing this correctly, a full golden-set replay plus a canary window, is on the order of six times the work of the service equivalent, and unlike the service case it is not optional. Skip it and you do not save the cost. You move it downstream and pay it as a production incident, which is the reliability failure this series has been circling: a filing that went out wrong because a change three agents upstream shifted a behaviour nobody re-validated.

That multiplier is also why the cheapest pipeline to operate is the one with the fewest agents that the task genuinely needs, which is the same conclusion the very first chapter reached from a different direction. A single agent has no blast radius, because it has no downstream. Every agent you add does not just add its own cost per run, the way the last chapter showed; it widens the blast radius of every future change to the agents above it, and it does so permanently, on every change you will ever ship. The regression surface is a standing tax on a shape you chose, so the discipline that pays off before all the others is to not choose a shape wider than the problem. Fan out only where the decomposition earns its keep, and every change you make for the rest of that system's life is cheaper to validate.

There is no such thing as a local change. Change one agent's prompt or model and you have changed every agent downstream, because its output is their input. The unit of change is the pipeline, not the agent.

When you do not need any of this

The honest caveat, as in every chapter. If your pipeline is small, changes rarely, and runs at low volume, the full apparatus of versioned artifacts, golden-set replays, and live canaries is more machinery than the risk justifies, and building it is a way of spending engineering time you do not have on a problem you do not yet have. Below that line, keep a handful of golden transcripts and replay them by hand before you ship a change, which costs almost nothing and catches the crude regressions, and skip the rest until volume or change frequency makes it earn its keep. There is one exception that applies at every scale, and it is the cheapest discipline of the four: pin your model versions. A frozen pipeline is not actually frozen if it points at a "latest" alias, because the one party who can still change it, the vendor, is not bound by your caution, and that single line of configuration is the difference between a system that changes only when you change it and one that can surprise you on a Tuesday for reasons that are not in your git history. Everything else scales with your volume and your change rate. Pinning the model does not, so do it from the first run.

We build production multi-agent systems for document-heavy work in legal, finance, and insurance, where a pipeline runs thousands of extractions and filings a day and a change that shifts behaviour silently is not a bug report, it is a compliance problem. The discipline that keeps those systems safe to change is not caution, it is structure: version the pipeline as one artifact, replay golden transcripts before you ship, canary on live traffic, and pin the models so nothing changes that you did not change. Talk to an engineer or see how we work.