Coherence over orchestration

When a multi-agent system misbehaves in production, the instinct is to reach for the orchestrator. Tighten the routing. Add a guard. Move a step out of one agent and into another. We have done all of these things, and they sometimes help, and they are almost never the actual fix.

The actual fix is usually upstream of the orchestrator. The agents are individually well-behaved. The router is doing what it was told. The output is wrong because nothing in the system was responsible for the property the user actually cares about.

What we mean by coherence

Coherence is the property that a multi-agent system, viewed as one unit, behaves consistently with respect to a small number of system-level invariants — tone, policy, escalation thresholds, factual grounding, latency budgets. None of those properties belong to a single agent. They belong to the seam between agents, and to the layer underneath all of them.

• An agent can be polite while the system as a whole sounds incoherent across a session.
• An agent can be grounded against its own retrieval and still contradict another agent's output.
• An agent can hit its latency budget while the user-perceived latency blows out, because the orchestrator is making three sequential calls where one would do.

What this implies for how we build

The first decision in a new engagement is not which agents to write. It is which invariants the system needs to hold, and where each one lives. Most of them live in the substrate, not in the agents — in the retrieval layer, in the shared memory, in the evaluation harness, in the contract the orchestrator enforces on every turn.

An agent is a function. A multi-agent system is a contract.

When we say Cohera, this is what we mean. The interesting engineering problem in 2026 is not building one more agent. It is the contract every agent has to honor — written in retrieval, evals, and tools, not in prompts.