Designing multi-agent systems that don't become multi-agent messes
There's a moment in every multi-agent design session that reveals whether the architect is thinking in agents or thinking in architecture. Someone draws an "orchestrator" box with arrows to a cluster labelled "research agent," "writing agent," "validation agent," and calls the result an agent swarm. The diagram looks clean and communicates capability. It has almost no architectural content — it doesn't show what each agent owns, what it can do without asking, what happens when it fails mid-task, or where the audit trail lives. Those aren't implementation details to figure out later. They're the architecture. The agent boxes are just vocabulary.
Three contracts have to exist for every agent before a line of code is written.
The autonomy boundary — the precise set of actions an agent may take without human or peer-agent approval, and the set that requires one or the other. This isn't a line in documentation; it's a policy binding the execution environment enforces. An agent that exceeds its autonomy boundary at runtime isn't misbehaving — it's misdesigned. The boundary should have prevented the action, not logged it afterward.
The communication contract — the protocol by which an agent sends and receives messages, the schema of those messages, and the guarantee about what it will and won't do with what it receives. No agent calls another agent's internal functions directly; every inter-agent exchange goes through the protocol. This isn't bureaucracy. It's the isolation property that makes each agent independently deployable, testable, and replaceable without cascading side effects. An agent that calls another's function directly creates a coupling invisible at the architecture level and very visible at the operational one — change Agent B's signature and Agent A breaks at runtime, not design time.
The failure contract — what an agent does, by design, in each defined failure mode. An agent that hits an error and returns an unstructured exception to its orchestrator doesn't have a failure contract. It has a bug.
Concretely, the agent architecture behind an autonomous deal desk — taking an inbound sales opportunity through pricing retrieval, margin computation, and quote generation under a 90-second latency target — decomposes into five agents, each with all three contracts specified before implementation:
| Agent | Autonomy boundary | Failure contract |
| CRM Context | Read-only. Credentials scoped at the IAM binding, not by convention. | API timeout → backoff ×3. Unavailable → typed error, routed to DLQ. No partial context used downstream. |
| RAG Retrieval | Read-only. Corpus DLP-redacted at ingestion; cannot retrieve raw PII. | Timeout → circuit breaker opens at 500ms. Degraded result flagged in the audit record, not silently served. |
| Margin Engine | Deterministic only. No LLM, no retrieval. Below-floor margin is auto-rejected, never routed for approval. | Computation failure after retries → typed error. A deal with an unverified margin is never processed. |
| Quote Generator | Template-constrained. The model may not write numeric fields — those come from typed inputs only. | Groundedness below threshold → routes to HITL, never delivered straight to the approval router. |
The thread running through every row of that table is the same: each agent's autonomy boundary is enforced as a binding, not a convention, and each failure contract names a specific, pre-designed response rather than leaving the orchestrator to interpret an unstructured exception. None of the five agents calls another's internals directly — every exchange is a typed message over a shared transport, the A2A discipline that predates the current wave of agent frameworks and that exists specifically so that changing one agent's behaviour doesn't silently break another's.
What scales is not the number of agents. It's whether every one of them was specified this precisely before the orchestrator diagram was ever drawn.
Further reading: Google Cloud, Vertex AI Agent Development Kit (ADK) documentation. · Google Cloud, Agent-to-Agent (A2A) Protocol specification. · Newman, S. (2021). Building Microservices, 2nd ed. O'Reilly, Ch. 12. · Nygard, M. (2018). Release It!, 2nd ed. Pragmatic Programmers.