Multi-Agent Coding Needs More Than Shared Context

A controlled test of how coding agents should talk

Teams of coding agents add capacity. They also add more chances to disagree. A preprint from researchers at Amazon Web Services (AWS) AI Labs, posted to arXiv on 5 October 2026 and not yet peer reviewed, tests one way to keep them aligned. Its protocol, AECP (Artifact-Exclusive Communication Protocol), forbids free-form messages between agents. Agents may only communicate through structured artifacts that the execution harness, the runtime that runs the agents and their tools, reads and acts on.

Across five models and three benchmarks that ask agents to build a whole repository from a specification (Doc2Repo, NL2Repo and CodeProjectEval), AECP improved the average test pass rate by 28.2% and cut average wall time by 16.5%, compared with an agent team using free-form messages. Both figures are relative changes. Against a team where one agent integrates everyone's work, AECP scored 8.5% higher and ran 24.9% faster.

Where multi-agent coding loses its time

The authors also looked at where free-form teams spend their effort. In an analysis of agent traces on one benchmark, labelled with a language model, 26.8% of tokens went to repeated exploration: agents rediscovering what another agent had already found. Another 22.2% went to rework caused by incompatible decisions at module boundaries.

Both are coordination failures, not coding failures. The agents could write the code. They could not keep each other's findings and agreements in force.

Shared context is a weak coordination mechanism

The usual fix is more shared context: a bigger window, a shared scratchpad, a longer system prompt. Each step in this chain can fail on its own:

information exists
  -> the agent sees it
  -> the agent understands it
  -> the agent follows it
  -> the system verifies it was followed

Shared context helps with the first step. On its own it does not make an agent follow the information, or check that it did. We made the same argument for single agents in Why Context Alone Doesn't Prevent Architectural Drift. AECP's results point the same way for teams.

What AECP does instead

AECP turns communication into two kinds of artifact, and makes the harness an active participant rather than a message bus:

• Knowledge Artifacts record a scoped finding about the code. When another agent later accesses matching code, the harness includes the finding in what that access returns. The agent does not have to remember to look.
• Contract Artifacts record an interface agreement between agents. A verifier parses the source and checks declared symbols and signatures against the agreement, without running the code. When a contract is revised, the harness notifies the agents that depend on it and marks their work as stale.

The change in the model's role is the important part. The check no longer asks "did the agent remember the agreement?" It asks "does this code satisfy the agreement?", and a deterministic verifier answers it.

The costs and limits are real

AECP is not free, and the paper is candid about it:

• It used 46% more tokens on average than a single agent working alone.
• In one model's breakdown on one benchmark, a single agent scored highest on easy tasks, with the lowest time and token use.
• In a test on one benchmark with one model, letting a leader agent size the team assigned one worker to 39 of 104 tasks. Against a fixed three-worker team, average wall time fell 18.6%, from 785.7 to 639.2 seconds, with the same score.

The security result needs care too. With free-form messages, a malicious instruction planted in one worker reached another worker in 19 of 20 attack cases and was adopted in 8. Under AECP it reached none. The authors attribute this to removing the free-form channel. They did not test malicious content written into artifacts or shared code, so this is one closed attack path, not general security.

Applicability matters more than window size

Part of AECP's design is that its artifacts are scoped. A finding about one module reaches the agent touching that module, not every agent in the team. That is the same property that matters for engineering decisions: which component, file, operation, dependency or interface a piece of knowledge applies to, and whether it is still current.

A bigger context window gives an agent more to read. Scoped, current knowledge delivered at the moment of change gives it less to read and more to act on.

Runtime agreements are not architectural decisions

AECP coordinates agents inside one execution. Its contracts are agreements the agents reach while building: "the customer service exposes this method with this signature." They are useful, and they expire with the run.

An architectural decision is a different object: "services in the payments domain communicate asynchronously, except through approved adapters." It was made by people with the authority to make it, it applies across every run, it has a lifecycle, and it can conflict with other decisions. Coordination between agents does not produce it, and should not overwrite it.

That suggests a simple rule for anyone building agent harnesses: do not promote agent agreements into the organisation's recorded decisions automatically. Promotion needs authority and provenance, the same as any other decision. The broader case for this split is in Coordination and Governance in Multi-Agent Systems and AI Agent Orchestration Is Not Governance.

What engineering leaders should do

• Do not default to teams. In one model's breakdown in this study, a single agent was faster and better on easy tasks. Size the team to the task.
• Make coordination artifacts structured and scoped. Findings and interface agreements should be data the harness acts on, not prose in a shared channel.
• Check agreements deterministically. Where an agreement can be expressed as a signature or a rule, verify it rather than trusting recall.
• Keep two layers apart. Runtime agreements belong to one execution. Architectural decisions belong to the organisation and need an owner, a scope and a status.

Where Mneme fits

Mneme sits in the second layer. It is an open-source decision and control layer for agentic software development, and it works on decisions that hold across executions, not on coordination within one. Today that means architectural decisions in a repository, recorded with lifecycle and supersession in its Decision Index. Decisions with typed rules are enforced deterministically, and a rule can be limited to the paths it names. Supported coding agents, including Claude Code, OpenAI's Codex command-line interface (CLI) and Kiro, check their native file writes before they land, and continuous integration (CI) checks again. Each integration page lists which write paths it covers.

It works the same whether one agent or a team is making the change, and it does not orchestrate agents.

A layer that captures runtime agreements and promotes the durable ones into governed decisions is a design idea, not a shipped capability.