MCP and AGENTS.md Standardize Context, Not Agent Coordination

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.

An August 2026 recheck, triggered by the MCP roadmap the maintainers published that month, leaves that verdict standing, with a caveat about evidence. The roadmap’s work items could not be retrieved and verified at refresh time, so this article asserts nothing about their contents; Cloudflare’s companion post (“the next generation of MCP”, 2026-08-26) is in the same state. What could be checked supports the original argument: the spec snapshot dated 2026-07-28, retrieved 2026-08-24, still defines MCP as “an open-source standard for connecting AI applications to external systems,” and its host-client-server architecture pairs each server with one dedicated client. Two agents that share a server share a toolbox. They do not share a way to agree.

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, updated for this refresh: none of the primary research sources spell out the scope of MCP or AGENTS.md directly, but the protocol documentation now does. The spec snapshot dated 2026-07-28 defines MCP as “an open-source standard for connecting AI applications to external systems” and lists data sources, tools, and workflows; the architecture is host, client, server, with a dedicated client per server. No party in that architecture is responsible for reconciling two agents. What remains an inference is intent: nothing in the spec names coordination as out of scope, so “deliberately excludes” is still an argument from ecosystem behavior. That behavior is 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 August roadmap is the live test of whether that boundary moves. The roadmap post sat at 224 points and 136 comments on Hacker News when checked on 2026-08-23, which is real traction for a governance document. Since its contents are unverified here, the conditional is the honest form: if the work items stay on the protocol’s current surface (transport, auth, tool discovery, elicitation), the boundary holds and inter-agent agreement stays in application code; if any item crosses into multi-agent agreement, this article’s thesis carries an expiry date. One checkable fact tilts expectation toward the first outcome. Elicitation, the protocol’s newest interaction primitive, is a channel for a server to ask the human behind the client for structured input, not for one agent to negotiate with another. The newest thing in the protocol still points at the human.

Governance points the same direction. Since December 2025, MCP has belonged to the Agentic AI Foundation, a Linux Foundation directed fund co-founded by Anthropic, Block, and OpenAI (Wikipedia), and scope changes there move at working-group speed. The same month, Anthropic published Agent Skills, a companion standard for packaging task-specific instructions that agents load on demand. Three context-side standards in a little over a year: MCP (November 2024), the AGENTS.md convention (2025), Agent Skills (December 2025). Zero coordination standards.

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. On SWE-bench-Verified it posts a 7.8% relative improvement over SWE-agent under DeepSeek-V3.1 and the highest resolved rate in its comparison, 76.0% Pass@1, under MiniMax-M2.5. 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. The venue is a signal too: a non-archival workshop paper (KnowFM at ACL 2026).

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, 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), accepted as an oral paper at ICML 2026, 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.

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. 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%. 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; the same study replicates the crossover on LoCoMo at a smaller budget. 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, 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 ICML 2026 oral gives that position real weight. A coordination standard may still emerge, but the candidates look thin: Google’s Agent2Agent protocol (A2A, 2025) and IBM’s Agent Communication Protocol (ACP, 2025) address agent-to-agent messaging, and none of the six papers this article cites mentions either one. The August 2026 MCP roadmap is the next data point. If its work items stay on transport, auth, tool discovery, and elicitation, inter-agent agreement stays in application code, every multi-agent build keeps carrying coordination costs the protocol layer never absorbs, and the A2A/ACP split stays unresolved. If it crosses into agreement semantics, date this article. As of the 2026-08-26 refresh, the roadmap’s contents are unverified and the spec surface is unchanged.

Two limitations deserve to stay attached to that verdict. First, the scope claim about MCP now rests on the 2026-07-28 spec snapshot plus observed framework behavior, but “deliberately excludes coordination” remains an inference, and the August 2026 roadmap that could confirm or break it is unverified here. Second, every number cited, the 28.8% attribution ceiling, the 55.8%-to-63.6% GAIA repair, the 48% memory swing, 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?

AgentDebugX reports 28.8% exact agent-and-step attribution on the Who and When benchmark, which means even the best available method misidentifies the failing agent or step in over 70% of cases. Your coordination layer cannot rely on correct blame assignment. It must design for idempotent sub-tasks and bounded reruns, since the same 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.

Does the August 2026 MCP roadmap add agent coordination?

Unverified. The roadmap post could not be retrieved and checked at the time of this refresh, so this article makes no claim about its work items. What is checkable: the 2026-07-28 spec snapshot still defines MCP as a standard for connecting AI applications to external systems, with nothing about agreement between them. If a roadmap item later adds inter-agent agreement semantics, the boundary drawn here moves with it. Until then, coordination lives in application code, and A2A and ACP remain the only coordination-protocol attempts with institutional backing, neither of which the 2026 research cluster uses.