Can artifact-exclusive communication make multi-agent code generation more reliable?

Coordination moves from agents to the harness

Multi-agent coding systems split repository-level work across agents, but the paper argues that exchanged information usually serves only as context: each agent must decide whether a shared finding applies and whether its implementation still matches an agreed interface. The authors report that shared findings may go unused and interface deviations may go undetected, which undermines reliability and efficiency.

The Artifact-Exclusive Communication Protocol (AECP) responds by making structured artifacts the only channel for inter-agent exchange and by specifying how the execution harness processes them. The harness supplies findings when agents access relevant code, screens implementations for mismatches with recorded interface commitments, and requires affected agents to revisit revised agreements. These steps become part of harness execution rather than actions agents must initiate from prior messages.

Knowledge artifacts deliver findings at the point of use

A Knowledge Artifact is represented as a tuple of claim, applicable scope, optional executable witness, and harness-maintained witness state. Workers record findings with the code scope they apply to, and the harness stores them with those scope associations. When a worker accesses matching code, the harness derives the current scope and retrieves non-refuted artifacts tied to that symbol, file, or enclosing directory, inserting them into the observation returned by the access operation.

Delivery is bounded and ranked. Each lookup delivers at most five artifacts and each forward at most four, newest first, truncated to 280 characters, so a single access adds about 1,400 characters. Findings are forwarded to workers owning related modules, preferring the same file, then modules connected in the dependency graph, then the same package. In the Opus-4.6 NL2Repo AECP runs, a task receives 41.9 knowledge deliveries on average; judged from traces by an LLM, 36% of delivered findings are used in the recipient's subsequent work, and witness-checked findings account for 88% of those used.

Witness checks decide which findings keep circulating

A finding that holds when recorded may become outdated as code or the environment changes. AECP therefore executes any attached witness before circulation: a zero exit marks the artifact witness-checked, a failure after the marker refutes it and rejects publication, and a failure before the marker means setup did not complete, leaving the artifact unchecked. Artifacts without a witness also remain unchecked and eligible for retrieval, and each delivered finding carries its witness state so recipients can distinguish checked from unchecked claims.

Consumers can also flag a stored claim, prompting the harness to rerun the witness and exclude refuted artifacts from later delivery while keeping an audit record. Witness execution rejects 14% of publication attempts before they enter circulation, and consumers flag 0.9 findings per task on average, 0.2 of which are retracted after the witness is rerun.

Contract artifacts let dependent modules proceed in parallel

A Contract Artifact records a symbol's identity, how it is constructed or called, and its return structure or exposed attributes. The harness validates the contract and generates stubs that expose the declared symbols and signatures without implementing behavior, so consumers can import the declared interface and build dependent modules while the producer is still working. Because stubs occupy the final module paths, consumers keep the same imports when the producer replaces them with its implementation.

When a module is submitted, a verifier compares it with the latest Contract Artifact by parsing the source into an abstract syntax tree and checking declared symbols, signatures, statically recoverable types and shapes, and residual stubs without executing the code. A provable mismatch causes rejection with the violated symbol and constraint reported, so the producer can repair the implementation or revise the agreement. This is a fast static screen for signature, attribute, and residual-stub mismatches before integration, not a runtime correctness check.

Revision tracking keeps consumers aligned with changed interfaces

An interface may change while consumers continue relying on an earlier version, and updating the producer's contract alone does not ensure those consumers revisit their assumptions. AECP addresses this by having consumers register the symbols they depend on with the harness during development, which lets the harness identify affected workers when an agreement is revised and require them to revisit it.

This is the third coordination step the harness performs, alongside supplying findings and screening implementations. Together, Knowledge and Contract Artifacts turn shared findings and interface commitments into coordination state the harness can act on, which is why AECP makes these artifacts the exclusive channel: information communicated outside them would bypass the harness checks and revision tracking that make coordination checkable.

Measured gains vary by baseline and benchmark

Evaluation covers repository construction, where agents build a repository from documentation or natural-language requirements in an empty workspace, using Doc2Repo, NL2Repo, and CodeProjectEval with closed- and open-source models including Opus-4.8 and DeepSeek-V4-Flash. Averaged across models and benchmarks, AECP improves test pass rate by 10.6% over a single agent, and by 28.2% and 8.5% over agent teams using free-form messages or centralized integration, while reducing wall time by 16.5% and 24.9% relative to those teams.

These are averages over the tested models and benchmarks, so the size of the gain depends on which baseline and which benchmark set is used. The paper also notes that simple tasks often favor fewer agents, which means the multi-agent advantage is not uniform across task difficulty.

Artifact-exclusive communication blocks message-borne attacks

The security study examines how malicious instructions propagate between agents after one agent is compromised. Artifact-exclusive communication blocks the relay of malicious instructions, reducing how often they reach other agents from 95% to 0% and how often those agents act on them from 40% to 0%.

The authors state that AECP removes only the free-form message channel between agents, so it should not be treated as a defense against instructions carried through artifacts or shared code. The attack cases ran in isolated containers without network access, no payload used a network endpoint, and generated repositories were discarded after scoring.

Where these results apply and where they stop

The evidence is bounded to repository construction from documentation or natural-language requirements in an empty workspace, across Doc2Repo, NL2Repo, and CodeProjectEval and the models tested. The reported pass-rate and wall-time figures are averages across those models and benchmarks, not guarantees for a specific repository, language, or agent scaffold, and the paper reports that AECP transfers across different agent scaffolds without quantifying that transfer separately here.

The security result is narrower still: it covers relay of malicious instructions through the message channel in the paper's attack cases, not instructions embedded in artifacts or shared code. Code produced by coding agents, including AECP, may contain errors or vulnerabilities and should be reviewed before use.

The most decision-relevant split in this paper is task difficulty and baseline choice: AECP's largest reported margin is against free-form inter-agent messaging, its margin against centralized integration is smaller, and simple tasks often favor fewer agents. Readers weighing multi-agent coordination should therefore treat artifact-exclusive communication as a way to make coordination checkable rather than as a uniform win over using fewer agents.

Sources used in this answer