Multi-agent is a contract problem

"Let's add more agents" has become the new "let's split it into microservices." Sometimes it is exactly right. Often it multiplies failure modes while making each one harder to find.

The demand is real: multi-agent architecture appeared in 345 postings in Agentic Ready's July 2026 Agentic AI Jobs Index. The patterns are well established, too. Anthropic's Building effective agents describes orchestrator-workers, where a central model delegates subtasks, and evaluator-optimizer, where one model critiques another's output in a loop. Neither resembles a group chat between personas, which is what many multi-agent demos actually are.

The difference between a pattern and a chat is a contract.

What a contract specifies

Every agent in a multi-agent system should have a written contract covering six things:

1. Role: one sentence on what this agent is responsible for, and what it is not.
2. Inputs: the schema of what it receives, and from whom.
3. Outputs: the schema of what it returns, including how it reports failure.
4. Permissions: which tools it may call, and with what scope.
5. Limits: step count, spending cap, wall-clock timeout.
6. Acceptance: how its output will be verified before anything downstream relies on it.

Here is an illustrative contract for a test-writing agent in a hypothetical code-change pipeline:

agent: test_writer
role: Write unit tests for a proposed change. Never modifies source files.
inputs:
  change_summary: string        # from planner
  diff: unified_diff            # from implementer
outputs:
  tests: list[file_patch]       # test files only
  status: enum[ok, blocked, needs_info]
  notes: string                 # reason, when blocked
permissions:
  tools: [read_file, list_dir, run_tests]
  write_paths: ["tests/**"]
limits:
  max_steps: 12
  max_cost_usd: 0.50
  timeout_s: 300
acceptance:
  - new tests fail on the base commit and pass on the change
  - no files outside tests/ modified

The status field may be the most important line. An agent with no sanctioned way to say "I could not do this" will produce something anyway.

The gate does not trust the swarm

In a well-designed system, no agent's claim is accepted on its word. If the implementer says the change is done, the gate runs the tests. If the reviewer says the code is safe, the gate runs the scanner. If the researcher says a fact is supported, the gate checks that the citation resolves and contains the claim.

The principle is that verification is performed by code and tools, not by another model's assertion. A reviewer agent is valuable for finding problems; it should never be the only thing standing between a change and production.

Failure modes to design against

The last two rows correspond directly to risks named in the OWASP Top 10 for Agentic Applications: insecure inter-agent communication and cascading failures. Using those names helps when a security review asks how the system was hardened.

Isolation is a feature

One genuine benefit of multiple agents is isolation. A sub-agent that explores a large codebase or document set in its own context window, then returns a short summary, keeps the parent's context clean. Separate working copies for agents that edit files stop them from colliding. Isolation is often a better reason to split than specialization.

Start with two agents, not ten

If you do need multiple agents, the smallest useful version is usually a pair: one that produces and one that checks, with code deciding whether the check passed. Run that pair on your golden cases and look at the traces before adding a third role. Each new agent should arrive with a reason you can state in one sentence, a contract, and at least one test proving the system is better with it than without it.

When not to swarm

Measuring Agents in Production found that most deployed agents run short trajectories under structured control flow, and that reliability is the concern practitioners raise most. Multi-agent systems are longer, less structured, and harder to make reliable by default. If a single agent with good tools, or a plain workflow, can do the job, start there.

Split when tasks are truly separable, when isolation would materially improve context quality, or when an independent verification step adds value. Then write the contracts before you spawn anything. If you cannot write them, the problem is not ready for more agents.

Sources cited

• Agentic Ready (Prefactor), Agentic AI Jobs Index — July 2026 report (snapshot July 27, 2026)
• Anthropic, Building effective agents (published December 19, 2024)
• OWASP GenAI Security Project, Top 10 for Agentic Applications 2026 (released December 9, 2025)
• Pan et al., Measuring Agents in Production (arXiv 2512.04123, submitted December 2025)