# The Coordination Layer ## A market guide to what sits underneath a workforce made of people and agents *Published by Tessera · Tel Aviv / Amsterdam* --- ## The sixty-second version Most organisations now run more than one AI agent. Very few run them as a system. The tooling that exists assumes an agent works alone: one prompt, one task, one result, one reviewer. That assumption held while there was one agent. It stops holding somewhere around the fourth. The failure mode is specific and easy to miss, because nothing errors. Each agent completes its task correctly. The combination produces a wrong outcome. No log shows a failure, because no individual step failed. The problem is not in the agents; it is in the space between them, and almost nothing is watching that space. We call the thing that watches it the **coordination layer**. This guide argues that it is a distinct category, that adjacent categories cannot absorb it, and that better models will not remove the need for it. --- ## Three diagnostic questions If you want to know whether this is your problem, these three questions settle it quickly. 1. **How many agents are running in your organisation right now, and who could name them?** If nobody can produce the list, you do not have a workforce, you have weather. 2. **When two agents touch the same thing, what notices?** If the answer is "a person, eventually, if they happen to look" — that is the gap. 3. **How does an agent earn the right to act without review?** If the answer is "someone decided once, at setup" — trust is a configuration value, not a measurement, and it will drift out of date the moment the agent's behaviour changes. --- ## The state of the market Adoption is close to universal and organisation-level productivity gains are stubbornly hard to demonstrate. That gap is the interesting fact. It is tempting to read it as "the models are not good enough yet". We think that reading is wrong, because the gains are clearly visible at the level of an individual task and clearly absent at the level of an organisation. Something is consuming them in between. Our hypothesis: the gains are consumed by **supervision** and by **rework**. - **Supervision.** Every agent that cannot be trusted to act alone requires a person in the loop. Add agents and you add reviewers, so the productivity ceiling is set by human attention rather than by model capability. Teams describe this as "I spend my day reviewing output instead of doing work." - **Rework.** Every cross-agent conflict that is discovered late costs more than the work it undid. These are rarely counted as AI costs. They are counted as an incident, a bad release, or an unhappy customer. Both are coordination costs. Neither is fixed by a better model. --- ## Two shapes of the same problem ### Shape A: the supervision burden A team adopts agents carefully. Every action of consequence is gated behind human approval. Nothing goes badly wrong, and nothing gets much faster either. The people who were going to be freed by automation are now the queue that automation waits on. Adding a sixth agent makes it worse, not better. This team will tell you the technology works and that they cannot feel it. ### Shape B: unsupervised coordination failure Another team removes the gates to get the speed. For weeks it works. Then a set of individually correct actions combine into something nobody intended: a schema change and a downstream rebuild and an outbound send, each fine, arriving in the wrong order. The observability stack shows three successful runs. The governance layer reports full compliance. No orchestrator was involved, because these agents did not share a workflow. The failure surfaces when a customer mentions it. Most organisations oscillate between these two shapes, and read the oscillation as a maturity problem rather than a missing layer. --- ## Shadow agents There is a third shape that is harder to see: agents nobody approved. Individual engineers wire up assistants with real credentials because it makes their week easier. Each instance is reasonable. Collectively it is an unmapped workforce with production access and no inventory. You cannot coordinate what you cannot see, so discovery is the first primitive, not a feature. Any layer that requires agents to be registered before it can observe them will only ever see the compliant subset — which is precisely the subset that was not going to cause the problem. --- ## What adjacent categories cannot solve Five categories are commonly assumed to cover this. Each covers something real and none covers the gap. **1. Observability.** Tells you what happened, after it happened, one trace at a time. The coordination failure is not a bad trace; it is a set of good traces whose combination is wrong. You cannot find it by looking harder at any single one. **2. Governance and compliance.** Answers "was this action permitted?" The coordination failure is made entirely of permitted actions. A compliance report on the earlier example is clean, and correctly so. **3. Orchestration.** Decides what runs next *within a workflow it owns*. Real organisations run many agents that share no workflow — different teams, different vendors, different reasons. Orchestration has no view across that boundary, which is exactly where the failure lives. **4. Runtime security.** Blocks known-bad actions: exfiltration, injection, forbidden calls. The coordination failure contains no bad action. Every call is one the agent was supposed to make. **5. Workflow platforms.** Encode a process a human designed. They assume the process is known in advance. The interesting agent work is precisely the work whose steps were not enumerated ahead of time. The pattern: each category evaluates actions **individually**. The gap is a property of actions **in combination**. That is a different computation, not a better-tuned version of the same one. --- ## Defining the category **A coordination layer maintains a shared, live model of what every agent and person in an organisation is doing, computes the consequences of their actions in combination, and governs autonomy from accumulated evidence.** Four capabilities follow from that definition. **Presence.** Every agent and person is discoverable and observable as a participant, with identity, current activity and standing. Vendor-neutral, and without requiring the agent to be modified — otherwise you see only the compliant subset. **Shared context.** A semantic model of entities, dependencies and ownership, derived from observed activity rather than configured by hand. Hand-configured models are wrong within a month; derived models track reality. **Consequence computation.** Given a proposed or in-flight action and the current state of everything else, determine what it will mean in combination — before it lands, not in the post-mortem. **Earned trust.** Autonomy as a running account that's broken down three ways — by which agent, in what context, and for which kind of action — and updated only from verified outcomes. The model leans toward caution whenever the evidence is thin, and only a sustained clean record pushes it toward more freedom. --- ## The paradigm is already here The strongest argument that this is a real category is that organisations already build a bad version of it by hand. The manual version is a spreadsheet of which agents exist, a channel where people announce what they are about to run, a convention that certain actions need a second pair of eyes, and a person who holds the whole picture in their head. Every one of those is a coordination primitive implemented in human effort. They do not scale, and they fail silently when the person holding the picture is on holiday. When an organisation reinvents the same missing infrastructure independently, the infrastructure is missing. --- ## The protocol layer, and what it does not do Protocol standardisation for agents is real and useful. Tool-access protocols let an agent reach systems in a uniform way. Agent-to-agent protocols let agents address each other in a uniform way. Both are plumbing, and both are welcome. Neither answers the question this guide is about: *given everything happening at once, is this action safe, and how much rope has this agent earned?* A protocol defines how a message is shaped. It does not decide whether the message should be sent. Standard protocols make a coordination layer easier to build and more necessary to have, because they lower the cost of adding the fifth, sixth and seventh agent. --- ## Why models will not simply absorb this The most common objection is that a sufficiently capable model will coordinate itself. Three reasons we do not think so. **Visibility.** A model can only reason about what is in its context. Cross-agent coordination requires knowing what other agents — belonging to other teams, on other vendors — are doing right now. That is a systems property, not a reasoning property. No amount of capability substitutes for information the model was never given. **Incentive.** Even with perfect visibility, an agent optimising for its own task is not the right party to adjudicate a conflict with another agent's task. That adjudication needs a position outside both. **Authority.** How much autonomy an agent has is an organisational decision backed by evidence and answerable to a human. It is not a capability the model can grant itself, and most organisations would not want it to. --- ## Where this goes **Phase one — visibility.** Organisations discover what they are actually running. The first install is usually uncomfortable: the inventory is longer than expected. **Phase two — consequence.** Cross-agent conflicts get caught before they land. The value is measured in incidents that did not happen, which makes it easy to feel and hard to invoice. **Phase three — earned autonomy.** Supervision stops being uniform. Well-evidenced agents operate with less oversight, poorly-evidenced ones with more, and the total human attention required falls even as the number of agents rises. This is where the productivity gap closes, if it closes. Most organisations are in phase one and do not know it. --- ## Sizing it honestly We are not going to invent a market size. The honest version: The addressable population is organisations running enough agents for the combination to matter — currently a minority, growing quickly, and growing fastest among teams that ship software. The budget it comes from does not exist as a line item yet; today it is paid for out of platform, security, or whatever budget absorbed the last incident. Categories that begin this way either become their own line item or get absorbed by an adjacent one. Our bet is the former, for the reason given above: the computation is different in kind, not in degree. --- ## Key takeaways 1. The productivity gap is a coordination problem, not a capability problem. 2. The failure mode is made of correct actions, which is why existing tooling misses it. 3. Discovery must not require registration, or you only see the agents that were never the problem. 4. Consequence is a property of actions in combination — a different computation from evaluating them one at a time. 5. Trust should be measured and conservative, not configured once and left. 6. Better models increase the need for this layer rather than removing it. --- *Questions, disagreement, or a counter-example that breaks the argument: team@tesserahq.live. We would rather be corrected early.*