MCP and AGENTS.md standardize how agents receive context and reach tools; neither specifies how multiple agents divide work, reconcile conflicting outputs, or agree on an answer. The 2026 arXiv cluster shows what fills that gap: every framework builds its own coordination layer on top of the shared transport, which means adopting MCP buys you plumbing, not interoperability, and the coordination logic is what you will rewrite if you ever swap orchestrators.
What do MCP and AGENTS.md actually standardize, and what do they leave out?
They standardize context delivery and tool transport, and they leave out everything about agreement. MCP gives an agent a uniform way to discover and call tools; AGENTS.md gives it a uniform way to ingest repo-level instructions. Both are one-to-one contracts between a single agent and its environment. Neither has a vocabulary for “agent A and agent B disagree about the plan,” “who owns this subtask,” or “whose output wins.”
One caveat on sourcing before the argument proceeds: none of the primary sources for this article spell out the scope of MCP or AGENTS.md directly. The claim that these protocols deliberately exclude coordination is an argument from observed framework behavior, not a quote from spec language. That observation is nonetheless consistent and recent. In 2026, arXiv has published a cluster of at least four new multi-agent frameworks, three of them in July alone (PhoenixRepair, AgentDebugX, and a memory-operator study, plus SAAG from late April), and each one ships its own bespoke collaboration, evaluation, or recovery machinery rather than building on any shared coordination standard. If a standard existed and served the need, at least one of these groups would have used it. None did.
The practical consequence follows directly. “MCP-compatible” describes a property of tool calls, not a property of systems. Two orchestrators can both speak perfect MCP and still be unable to share a task, because the task-division logic, the message semantics between agents, and the conflict-resolution policy all live above the protocol, inside each framework. Teams budgeting a migration from one orchestrator to another routinely price the tool-integration work (which MCP genuinely reduces) and forget to price the coordination rewrite (which it does not touch).
The 2026 framework cluster: four coordination layers, zero shared standards
Four papers published within twelve weeks of each other reinvent four different slices of coordination, and the diversity is the evidence. This is not four groups converging on a common pattern; it is four groups solving different coordination problems with incompatible designs, which is what a field looks like when no standard constrains it.
PhoenixRepair (arXiv:2607.18859) tackles coordination inside software-repair agents. Its mechanism is search: instead of committing to one edit location, the framework explores multiple candidate locations with iterative reflection and refinement, expanding the space of repair strategies the agents consider. The coordination question here is “how do agents collectively decide where the bug is,” and PhoenixRepair’s answer is a managed search over hypotheses, owned entirely by the framework.
SAAG (arXiv:2607.18245) tackles a different slice: evaluating whether an agent called the right other agent correctly. It decomposes agent-calling evaluation into three sequential stages, registry conformance, structural completeness, and argument grounding, each producing its own interpretable diagnostics. The evaluation itself is the coordination artifact: SAAG assumes an agent registry exists and measures how well calls conform to it. Its benchmark, derived from Glaive’s function-calling dataset, runs registries of 5, 10, and 15 agents on three local sub-4B-parameter models, which gives a sense of the scale at which this problem is currently tractable to study.
AgentDebugX (arXiv:2607.18754) assumes coordination will fail and builds the after-action loop: Detect, Attribute, Recover, Rerun, organized as a closed cycle. Where SAAG evaluates calls in isolation, AgentDebugX watches a whole multi-agent run, finds the failure, assigns blame to a specific agent at a specific step, and re-executes. The fourth paper, Retain or Consolidate? (arXiv:2607.17545), addresses the shared-memory dimension: how agents’ memory should be managed under context budgets. Its finding, that consolidation improves absolute accuracy by up to 48% on LongMemEval under tight budgets while retention wins under loose budgets 4, means the correct memory policy is conditional on deployment constraints, which is exactly the kind of context-dependent decision a fixed standard is bad at encoding.
Four frameworks, four coordination surfaces: repair-strategy search, call evaluation, failure attribution, and memory policy. The overlap between them is essentially zero.
How do current frameworks actually coordinate agents?
Three design families have emerged, and they make incompatible assumptions about where coordination intelligence should live. The choice between them determines your debugging surface, your scaling behavior, and your switching costs.
The first family treats coordination as an optimization problem inside one framework. OMAC (arXiv:2505.11765) is the clearest statement of this position. It identifies five optimization dimensions spanning both individual agent functionality and collaboration structure, and optimizes any one of them using two actors: a Semantic Initializer and a Contrastive Comparator. The framework owns the whole loop. This is the strongest counter-evidence to the case for a standards-level coordination layer: if collaboration structure is something you can tune per framework, per task, then perhaps frameworks legitimately need different coordination schemes, and a shared standard would mostly constrain them.
The second family pushes coordination down to the nodes. ReaGAN (arXiv:2508.00429) gives every node in a graph its own agent with autonomous, node-level decision-making. Each node plans its next action based on its internal memory, which yields node-level planning and adaptive message propagation with no central coordinator at all. ReaGAN works precisely because it refuses any shared protocol; the coordination emerges from local decisions. (The “Node” here is a graph node in an agentic network, not the JavaScript runtime.)
The third family treats coordination as something you diagnose after it breaks. SAAG’s cascaded three-stage evaluation and AgentDebugX’s Detect-Attribute-Recover-Rerun loop both accept the coordination design as given and build observability around it. This is the least glamorous family and, for anyone running multi-agent systems in production, arguably the most relevant one.
| Framework | Coordination mechanism | Where coordination lives | Observability story |
|---|---|---|---|
| OMAC | Optimization loop over five dimensions (Semantic Initializer + Contrastive Comparator) | Central, inside the framework | Indirect: you measure the optimized outcome |
| ReaGAN | Node-level autonomy, local memory-driven planning | Distributed across graph nodes | Hard: no central decision to inspect |
| SAAG | Cascaded three-stage call evaluation (registry, structure, grounding) | Registry + staged checks | Stage-specific interpretable diagnostics |
| AgentDebugX | Closed-loop Detect-Attribute-Recover-Rerun | Post-hoc, around any run | Explicit attribution, but capped (see below) |
| PhoenixRepair | Multi-location search with iterative reflection | Managed search inside the repair loop | Reflection traces per candidate edit |
The table’s last column is the one that matters operationally. Every framework can demonstrate that its coordination works on its benchmark of choice; far fewer can tell you which agent broke which step when it doesn’t.
What does the attribution accuracy ceiling mean for multi-agent operations?
It means that even the best available method for blaming the right agent gets it wrong most of the time, so your coordination layer must be designed for imperfect diagnosis. On the Who and When benchmark, AgentDebugX’s DeepDebug reaches 28.8% exact agent-and-step attribution accuracy on qwen3.5-9b, against 21.7% for the strongest single-pass baseline 3. Read that number twice. The state of the art, given a failed multi-agent run, identifies the failing agent at the failing step correctly less than three times in ten.
The recovery numbers tell a more encouraging second half of the story. On GAIA, DeepDebug repairs 13 of 73 failed tasks in a single rerun, compared with 4 to 6 for three decoupled self-correction baselines, lifting overall accuracy from 55.8% to 63.6% 3. So closed-loop recovery roughly doubles or triples repair yield over letting agents self-correct independently, even though the attribution underneath is mostly wrong. The lesson is structural: rerunning a bounded, well-instrumented sub-task pays off even under misattribution, because the loop contains the blast radius. Decoupled self-correction, where each agent retries on its own, does not have that property.
For a builder, this reframes what the coordination layer is for. You are not building machinery that prevents disagreement between agents; you are building machinery that makes disagreement cheap to find and cheap to redo. Concretely, that favors coordination designs with three properties: explicit task boundaries (so a rerun has a natural unit), logged inter-agent messages at those boundaries (so attribution has something to work with), and idempotent sub-tasks (so reruns are safe). None of those properties come from MCP or AGENTS.md. All of them are framework-level or application-level decisions.
The memory study sharpens one more operational trade-off. On LongMemEval, consolidation improves absolute accuracy by up to 48% under tight context budgets, while retention is the better operator when budgets are loose 4. A 48-point swing from a single memory-policy decision is larger than most model upgrades deliver, and the correct choice inverts with your budget. Any framework that hardcodes one memory operator has made a deployment decision on your behalf.
How do you audit a framework’s coordination layer before you commit?
Audit five things, in this order: how work is divided, how conflicts resolve, how failures are attributed, what memory policy is assumed, and what survives an orchestrator swap. The framework’s own documentation will answer the first loudly and the last four quietly or not at all, which is itself diagnostic.
Work division. Find the mechanism, not the marketing. Is there a planner that decomposes tasks, an optimization loop like OMAC’s, or local autonomy like ReaGAN’s? Each implies a different failure shape: central planners fail centrally, autonomous nodes fail diffusely and are harder to attribute.
Conflict resolution. Ask what happens when two agents produce contradictory outputs. If the answer is a vote, a judge model, or “the orchestrator decides,” that component is part of your coordination layer and part of your switching cost. If the documentation does not answer the question at all, the answer is probably “nothing happens,” which is the worst option.
Failure attribution. Given AgentDebugX’s 28.8% ceiling on exact attribution 3, treat any framework’s debugging claims with skepticism and check whether its runs produce the raw material (bounded tasks, logged handoffs) that tools like AgentDebugX or staged evaluators like SAAG need to work. A framework whose coordination happens in a single opaque prompt chain gives you nothing to attribute.
Memory policy. Identify whether the framework retains, consolidates, or lets you choose, and whether that choice is exposed as configuration. The memory-operator results show the right answer is budget-dependent, so a fixed policy is a latent misconfiguration for whichever deployment regime it did not assume.
Portability. Finally, list which parts of your system would survive swapping the orchestrator: tool integrations (portable, thanks to MCP), context files (portable, thanks to AGENTS.md), and coordination logic (not portable). The length of the third list is your real switching cost, and it is worth knowing before the first production incident, not after.
Budget for the coordination you own, not the protocol you adopted
The verdict: treat MCP and AGENTS.md as context and transport plumbing, price them as such, and direct your real architectural scrutiny at the coordination layer above them. That layer, how the framework divides work, reconciles outputs, and attributes failures, is framework-specific today, determines the bulk of your debugging surface, and is what you will rewrite if you change orchestrators. The 2026 framework cluster is not evidence of immaturity that a standard will soon fix; the divergence of designs (optimization loops, node autonomy, cascaded evaluation, closed-loop recovery) suggests frameworks genuinely need different coordination schemes, and OMAC’s results give that position real weight. A coordination standard may still emerge, but nothing in the current literature is converging toward one.
Two limitations deserve to stay attached to that verdict. First, the scope claim about MCP and AGENTS.md rests on observed framework behavior rather than protocol specifications, so treat “protocols exclude coordination” as an inference from the ecosystem, not a documented design decision. Second, every number cited here, the 28.8% attribution ceiling 3, the 55.8%-to-63.6% GAIA repair, the 48% memory swing 4, comes from research benchmarks rather than production systems. Benchmarks overstate coordination health in the same way they overstate model health: the tasks are bounded, the registries are small (SAAG tops out at 15 agents), and nobody’s on-call pager is involved. If your multi-agent system works better than these numbers suggest, believe your telemetry over the papers. If it works worse, the papers have at least told you which layer to blame.
Frequently Asked Questions
Can I use MCP to route tasks between agents in a production pipeline?
No. MCP defines the transport for tool calls and context delivery, not the routing logic. In July 2026, frameworks like PhoenixRepair and SAAG implemented their own bespoke task-division and registry-conformance layers because no shared protocol exists for inter-agent routing. You must build or buy a coordination layer that sits above MCP to handle work distribution.
How does ReaGAN’s node autonomy compare to centralized orchestrators?
ReaGAN (arXiv 2508.00429) distributes coordination to individual graph nodes, allowing each node to plan its next action using internal memory without a central controller. This contrasts with centralized frameworks like OMAC, which optimize collaboration structure through a single Semantic Initializer and Contrastive Comparator. ReaGAN sacrifices centralized observability for adaptive, local decision-making.
What is the practical impact of AgentDebugX’s 28.8% attribution accuracy?
Even the best attribution methods misidentify the failing agent or step in over 70% of cases on the Who and When benchmark. This means your coordination layer cannot rely on perfect blame assignment. Instead, it must design for idempotent sub-tasks and bounded reruns, as AgentDebugX’s recovery loop still improved GAIA accuracy from 55.8% to 63.6% despite the low attribution precision.
Should I use memory consolidation or retention for my agents?
The choice depends entirely on your context budget. Research from July 2026 (arXiv 2607.17545) shows that memory consolidation improves absolute accuracy by up to 48% under tight budgets, while retention is superior when budgets are loose. Hardcoding one policy in your framework will likely result in a latent misconfiguration for your specific deployment constraints.
