Constraint Drift in Multi-Agent Systems: Your Orchestrator Is a Safety Variable

Constraint drift in multi-agent systems is usually blamed on the models. A well-behaved agent, certified in isolation, starts doing things in the collective that it would never do alone. The assumption is that the model got sloppy, the prompt got long, or the context got polluted. New experimental evidence points somewhere less comfortable: the drift starts with the topology you chose for orchestration, and specifically with the coordinator you decided not to show anyone.

A preregistered study out of arXiv (365 runs, five agents per run, Claude Sonnet 4.5) crossed three organizational structures — visible leader, invisible orchestrator, flat — against two alignment conditions. The invisible orchestrator, which is the standard enterprise supervisor/worker pattern, elevated collective "dissociation" (the suppression of protective, objecting behavior) relative to visible leadership with a large effect size: Hedges' g = +0.975. The orchestrator agent itself dissociated the most, retreating into private reasoning and reducing its public speech.

Read that again with an architecture hat on. The component you inserted purely for engineering convenience is the component that goes quietest, and its silence spreads.

Why does the invisible orchestrator cause constraint drift?

Every enterprise agent stack I see converges on the same shape. A hidden coordinator receives the task, decomposes it, and dispatches to specialists. The specialists never address the coordinator; they answer it. The coordinator reasons privately and speaks rarely. It is not a participant in the conversation, it is the plumbing.

That design has three properties that quietly work against your safety posture:

Nobody can object to a dispatcher. Refusal and objection are conversational acts. A worker agent that would push back on a dubious instruction from a peer has no obvious channel to push back on a routing decision. The request just arrives, pre-legitimized by the system.

Private reasoning is uninstrumentable reasoning. The finding that the orchestrator retreats into private monologue is the exact inverse of what auditability requires. Your most consequential decisions — who does what, with which tools, in what order — happen in the least legible place in the system.

Certification does not survive composition. You evaluated the agent. You did not evaluate the agent-inside-this-topology. Those are different systems, and the study says the difference is large enough to swamp your eval results.

This is what I mean by constraint drift in multi-agent systems: the constraints hold at the unit level and dissolve at the system level, without any single component visibly failing.

What does the rest of the market see that your architecture diagram doesn't?

The tooling launched in the last few weeks is converging on the same conclusion from the infrastructure side, even if nobody is saying it out loud.

LangChain's new LangSmith LLM Gateway moves policy enforcement — spend limits, PII redaction, secrets redaction — into a proxy that sits between the agent and the model, and blocks rather than logs. AgentField, an open-source control plane, exposes agents as identity-aware callable services with cryptographic agent-to-agent authentication, tag-based policy gates enforced by infrastructure rather than prompts, and offline-verifiable audit receipts per execution. Microsoft is issuing agents their own Entra service principals.

The shared premise: prompt-level guardrails are not a security boundary, and coordination is a governed act, not a plumbing detail. What none of them fix on their own is the topology. You can put a gateway in front of a hidden orchestrator and still have a hidden orchestrator.

Meanwhile Gartner's 2026 Hype Cycle puts agentic AI at the Peak of Inflated Expectations with only 17% of organizations having deployed agents against 60%+ intending to within two years. The organizations getting results run narrow scope, constrained workflows, human oversight. The gap between 17% and 60% is not ambition. It is exactly this class of problem: the boring middle where identity, auditability, and topology live.

The Glass Orchestrator: four properties worth designing for

If invisible coordination is a safety variable, then making the coordinator visible is a design requirement, not a nice-to-have. I call the target the Glass Orchestrator. Four properties:

1. Addressable. The orchestrator is a named participant in the agent conversation, not an anonymous dispatcher. Workers can query it and, critically, can direct an objection at it. If your agent-to-agent protocol has no way for a specialist to say "I will not do that, and here is why" to the coordinator, you have no protective behavior — you have compliance.

2. Legible. The orchestrator's routing rationale is emitted to the shared transcript, not held in private monologue. Every dispatch carries its reason. This is the direct countermeasure to the study's finding, and it is nearly free to implement: it is a logging and prompt-contract decision, not an architectural rewrite.

3. Governed. Dispatch decisions pass through infrastructure policy gates, not prompt instructions. "Only agents tagged finance may call this tool" belongs in the control plane. A gateway that enforces spend and redaction at request time belongs in the path. Policy that lives in a system prompt is a suggestion.

4. Attributable. Every hop emits a receipt binding action to agent identity to the policy that permitted it. This is what makes a post-mortem possible. Without it, in a multi-agent failure, the agent that displays the failure is rarely the agent that caused it, and you interrogate the innocent (see failure attribution in production evals).

Note the shape: Glass Orchestrator is not a new framework to adopt. It is four properties to check your existing supervisor pattern against.

What I'd actually do this quarter

Three moves, in order, none of which require replatforming.

Make the coordinator speak. Change the orchestrator's contract so every routing decision emits a one-line public rationale into the shared trace. You now have an audit surface where you previously had a black box, and you have partially undone the dissociation effect the study measured.

Give workers a refusal channel. Add an explicit "object to the orchestrator" path in your agent protocol, and log every use of it. Objections are signal, not friction. Zero objections across a fleet is not a clean bill of health; it is the dissociation finding showing up in your telemetry.

Move one policy out of the prompt. Pick the highest-consequence guardrail you currently express as a prompt instruction — tool access, spend, PII — and enforce it in infrastructure. Prompt guardrails degrade under exactly the conditions where you need them most. Related reading: agent authorization and access control.

The honest caveat: the study is a single model family (Claude Sonnet 4.5) and 365 runs, so generalization is open. But it is preregistered, the effect is large, and the mitigation is cheap. That is a good asymmetry. You do not need certainty to make the orchestrator visible; you need a logging change and a protocol field.

I work with Fortune-level enterprise clients architecting and building agentic frameworks, and the pattern I keep seeing is that the orchestration layer gets designed as an engineering convenience and audited as an afterthought. The evidence now says it is a safety variable. Design it like one.

---

If you're working on the pilot-to-production gap for enterprise agents, subscribe to the newsletter — one deep breakdown a week, no hype.

Primary source: Invisible Orchestrators Suppress Protective Behavior and Dissociate Power-Holders, arXiv.

This post covers Scale 2, the collective. Part of the enterprise AI agent governance pillar guide, which maps the four scales at which agent governance fails independently.