Agentic Systems: Containing a Bad Specialist

This is Part 3 of Agentic Systems: Operating at Scale, the third series in a pillar on building agentic systems.

• Part 1: Memory Is a System, Not a Prompt Trick: the four stores that get collapsed into one word, and what each is for.
• Part 2: What Fan-Out Costs You: the invoice the architecture diagram does not show.
• Part 3: Containing a Bad Specialist: drift, correlated failure, and what containment actually requires.

This closes the pillar. The first series split the work and scored it, the second bounded and recorded it, and the first two posts here covered state and cost. What remains is the failure case the whole structure was supposed to handle, and the question of whether it actually does.

Table of Contents

• Drift Is Not an Incident
• Three Properties That Determine Containment
• The Independence Assumption Is Load-Bearing
• Shared Infrastructure Correlates Everything
• Architectural Containment Beats Behavioural Containment
• The Honest Bill
• When Containment Is Not Worth Building
• Conclusion

Drift Is Not an Incident

An earlier series on this blog examined failures in single coding agents - a destructive command run during a code freeze, an agent acting on a hallucinated success. Those are events. They have a timestamp, a blast radius, and a post-mortem, and the discipline they call for is calibrating supervision against blast radius and reversibility.

A panel fails differently, and the difference matters operationally. One specialist among nine starts being wrong more often. Nothing crashes. No alert fires. Every decision still completes, still carries a confidence, still gets routed. The orchestrator continues weighting that specialist according to a calibration figure computed from a window that mostly predates the change. There is no moment to point at, only a number moving slowly in a direction nobody is watching.

Two properties make this hard. It is gradual, so no threshold trips. And it is partially masked, because the other eight specialists are still right, so the aggregate degrades much more slowly than the individual - which sounds like the graceful degradation the architecture promised, and is, right up until the drifting specialist happens to be the one that matters for a particular class of decision.

The honest question is not whether a specialist can drift. It will. It is: how long before the system notices, and what is the worst it can do in the meantime.

Three Properties That Determine Containment

Whether the architecture actually contains a drifting member comes down to three things, none of which are automatic.

Does influence decay fast enough? The calibration loop reduces a specialist's weight as its accuracy falls, which is the primary containment mechanism. Its speed is bounded by two things established earlier in this pillar: the calibration window, and the outcome lag for that decision type. If outcomes take a week to resolve and the window is thirty days, the system cannot meaningfully respond to drift inside a week and will respond only partially for several more. That number is knowable in advance, and most teams have never computed it. It is the single most useful thing to work out about a panel.

Is there a ceiling on any one specialist's influence? Weighting by calibrated accuracy means a specialist with a strong record carries more weight, which is the intent. Without a cap, a specialist that is both highly rated and highly confident can dominate the aggregate - and at that point the panel has quietly become a single agent with eight advisors it is entitled to ignore, reintroducing exactly the failure the first post decomposed to avoid. A cap costs a little accuracy when the specialist is genuinely right. It buys a bound on how wrong one component can make the system.

Is disagreement visible? A drifting specialist usually starts disagreeing with the others before its accuracy figure moves, because disagreement shows up per decision while accuracy needs outcomes to accumulate. That makes the disagreement rate a leading indicator with a much shorter detection lag than calibration. It only works if disagreement is recorded rather than silently resolved into an aggregate - which is a ledger design decision made long before anyone needs it.

The Independence Assumption Is Load-Bearing

Everything above assumes specialists fail independently - that when one drifts, the others are unaffected and their continued correctness both masks and eventually corrects it.

That assumption is doing more work than it appears, and it is the thing to check hardest, because when it breaks the entire containment story breaks with it. Three specialists failing independently is a degraded panel. Three failing together, for the same underlying reason, is a panel that is confidently and unanimously wrong - and the orchestrator reads unanimity as strong evidence. Correlated failure does not just defeat the aggregation, it inverts it: the system's confidence is highest exactly when it is most wrong.

Part 1 of this series named one source already: specialists sharing a working context inherit each other's misleading facts. But the deeper source is infrastructural, and it is the one worth closing this pillar on.

Shared Infrastructure Correlates Everything

Nine specialists that are logically independent are usually not physically independent. They typically share the same model provider, often the same model, frequently the same prompt scaffolding, and nearly always the same retrieval corpus.

Every one of those is a correlation channel:

• Same model. A provider updates a model version, and every specialist's behaviour shifts at once, in ways that may be subtle and systematic rather than obviously broken. Nine independent judgements just moved together.
• Same retrieval corpus. A stale runbook retrieved by several specialists misleads all of them identically - and as Part 1 noted, retrieval staleness is invisible at the point of use.
• Same prompt scaffolding. A shared system prompt or output-format instruction, changed once, alters every specialist simultaneously.
• Same input snapshot. If the upstream data is wrong, every specialist reasons correctly from a false premise and arrives at consistent, confident, wrong conclusions.

This is the mechanism behind the correlated error that individual calibration figures cannot see. Each specialist remains individually well calibrated against its own history. The aggregate is what lies, because the aggregation assumes independence that the infrastructure quietly removed.

Two practical responses. First, the ledger's model and prompt version fields exist precisely so a simultaneous shift across specialists can be attributed to a deployment rather than mistaken for genuine consensus - this is the field's real payoff, and it is only there if someone put it there early. Second, monitor the disagreement rate itself as a system-level health signal. A panel whose members suddenly agree far more than usual has probably lost independence rather than gotten better, and unexplained consensus deserves as much suspicion as unexplained conflict.

Architectural Containment Beats Behavioural Containment

There are two ways to contain a specialist, and they are not equally good.

Behavioural containment works by measuring what the specialist does and responding: calibration, weighting, demotion. It is general, it applies to any specialist, and it is fundamentally reactive - it requires outcomes to accumulate, so its detection speed is floored by outcome lag.

Architectural containment makes a class of error checkable at the moment it occurs, without waiting for outcomes. The clause pinning used by a tender-response system is the clean example: every drafted response is bound to the specific source clause it answers. A drafting agent that begins fabricating citations is not caught weeks later by a declining accuracy figure - it is caught by the next person who checks a citation against the actual clause, because the check is immediate, local, and does not require knowing whether the overall answer was good. The same pattern appears in a trading system's pre-trade validation: an order outside risk bounds is rejected structurally, regardless of how confident the signal that produced it was.

The distinction matters because architectural containment has no detection lag and does not depend on volume. Behavioural containment needs enough outcomes to be statistically meaningful, which for low-frequency decision types may be never. Where a class of error can be made immediately falsifiable - by requiring a citation, a bound, a reference to something checkable - that is worth far more than any amount of downstream calibration.

The general move: give every specialist output something a reader can check without knowing whether the decision was ultimately correct. Then drift becomes visible at the point of production rather than in a quarterly figure.

The Honest Bill

The last line is the honest difficulty with all of this: nearly every mechanism here is invisible until the day it matters. Weight ceilings, disagreement tracking, model-version fields, consensus monitoring - none of them improve a working system, and all of them cost something continuously. They are insurance, and like all insurance they look like waste until the claim.

When Containment Is Not Worth Building

• Every decision is reviewed by a human anyway. If nothing is automated, a drifting specialist produces a worse proposal that a person rejects. The review is the containment, and building a second layer is duplicated cost.
• Decision volume is too low for statistics. Below some rate, calibration and disagreement monitoring are both noise. Sample decisions manually on a schedule instead.
• The panel is small and every member is already watched. Three specialists whose outputs a human sees on every decision do not need weight ceilings.
• Errors are immediately and unambiguously visible downstream. If a bad decision surfaces within minutes through an existing operational signal, that is already architectural containment; adding calibration machinery on top is redundant.

Conclusion

A drifting specialist is not an incident, it is a slow change in a number, and whether the architecture contains it comes down to three properties that have to be built deliberately: a ceiling on any one specialist's influence, a calibration loop faster than the damage accumulates, and disagreement recorded rather than silently absorbed. All three rest on an independence assumption that shared models, shared prompts, shared retrieval, and shared inputs quietly undermine - which is why unexplained consensus deserves as much suspicion as conflict, and why model and prompt versions belong in the ledger from the start. Where a class of error can be made immediately checkable, that beats any amount of after-the-fact calibration.

That closes the pillar. Split the work so reliability means something, route on reliability that was earned and can be revoked, measure it honestly, bound what the system can do, record what it did, keep the model layer swappable, separate the stores, budget the fan-out, and contain the member that goes wrong. None of it is exotic, and most of it is what distributed systems already learned about decomposition, measurement, and blast radius. The novelty is only that the components now exercise judgement, which changes what "wrong" looks like - not an exception and a stack trace, but a confident answer that is quietly worse than it used to be.