Multi-agent work needs a contract

Giving six agents different names does not create an engineering team. It creates six processes capable of making changes. The useful organization begins with a contract: what each process owns, what it may read or change, and what evidence must arrive at the handoff.

The recovered SENN draft described a six-role system: coordination, implementation, interface design, quality review, architectural work, and knowledge curation. That division is a useful design proposal. Its dramatic incident timeline, productivity claims, and exact memory-graph totals are not treated here as independently verified results.

Start with the smallest useful split

A second agent is valuable when its work can proceed independently or when it provides a materially different review. It is less useful when both agents need to edit the same function every few minutes.

Consider a configurator change. One worker could implement a pricing rule while another prepares tests from the approved price specification. A frontend worker can integrate the result after the interface is stable. Starting all three against an undefined API creates coordination work before it creates a feature.

One capable worker is often the right starting point. Add a role when you can name the bottleneck it removes.

Write the handoff before the work

A compact task packet should include:

“Build the backend” leaves nearly all of these decisions open. “Implement this price-rule function with these fixtures, without editing the checkout route” gives another worker a stable boundary.

Names and personas can make a system easier to discuss. They do not replace enforced permissions, version control, or clear interfaces.

Treat shared memory as a source collection

A useful memory system preserves where a statement came from and when it was true. It should distinguish a current specification, an observation from a past run, a proposed design, and a worker’s inference.

Do not let an old confident note override the current repository merely because it is familiar. Recheck facts that are cheap to verify and likely to change: branch state, API shape, installed version, deployment status, and test results.

Access rules also belong in the retrieval layer. A document marked private should not become visible because another agent guessed its title. Labels without enforcement are organization, not authorization.

Keep communication legible and structured

Human-readable messages are valuable because the operator can understand them. Machine-readable fields are valuable because a scheduler can validate them. These goals fit together.

A handoff can contain a short explanation plus structured fields for revision, changed paths, test command, exit status, and blockers. The explanation tells a reviewer why the work matters; the fields stop an orchestration system from interpreting “looks good” as proof.

Use targeted updates. Broadcasting every action to every worker fills their context with noise and makes ownership less clear.

Review from outside the implementation

A reviewer should receive the requirement, the patch, and enough environment information to run an independent check. Asking it to restate the implementer’s explanation produces agreement more easily than scrutiny.

A useful review asks what would falsify the success claim. For a pricing change, try a stale catalog revision and a boundary quantity. For a renderer change, switch materials while an earlier asset is still loading. For a database change, rehearse the migration on representative data.

A different agent can catch mistakes, but difference alone does not guarantee independence. Workers using the same incomplete specification can repeat the same error.

Integrate serially where state is shared

Parallel preparation and serial integration are often a productive combination. Before landing each patch, confirm the target revision and rerun the checks affected by earlier changes.

If two patches overlap, give one owner responsibility for the combined result. Do not treat a clean textual merge as semantic validation. Two individually correct changes can disagree about units, cache ownership, or error handling.

Keep the final evidence attached to the integrated revision. Tests from yesterday’s branch are useful history; they are not the release evidence for today’s combined code.

Compare coordination under a matched budget

Anthropic’s August 2026 multi-agent experiments distinguish bounded delegation from less structured peer coordination. In its vulnerability-search study, broader swarm results also reflected broader search scope and spending; matched comparisons were more nuanced. More findings alone do not establish more efficient coordination.

Before expanding a team, run the same bounded task with one agent, a coordinator with delegated tools, and the proposed peer arrangement. Hold the repository snapshot, allowed tools, task set, and total budget fixed. Include integration and review in elapsed time.

Record accepted outcomes, duplicate work, unresolved conflicts, and human correction time. A team that finishes more subtasks but leaves more integration work may be slower for the user.

Diagnose the failure at the handoff

The MAST study groups observed failures around system design, inter-agent misalignment, and task verification. Use that taxonomy as a starting point for investigation, not as an automatic diagnosis of a particular team.

For a failed task, find the earliest handoff where the evidence and the receiving agent’s understanding diverged. Was the required input missing, the authority unclear, the artifact stale, or the completion criterion misunderstood?

Change one contract at a time and rerun the same case. A useful intervention might require a schema version in a research handoff or an artifact hash in a review request. Adding another agent is justified only if the new arrangement improves the final result under the chosen budget.

Measure whether the system helps

Compare against a simpler workflow on representative tasks. Record completion quality, rework, elapsed time, tool cost, conflicts, and defects found after delivery. Include coordination time.

The result may support more specialization, fewer workers, or a stronger specification. All three are useful findings. The objective is dependable delivery, not a large cast of agents.