Agent-to-Agent (A2A) & Monolith vs Multi-Agent
The monolith-first strategy, preventing GOTO antipatterns in multi-agent systems, designing Agent Cards, and architecting Agent-as-a-Service contracts.
Specialize only after the monolith teaches you where
The source compares this evolution with Infrastructure as Code, AutoML, and the move from monoliths to microservices: low-level manual configuration gives way to intent-based orchestration, then proven black boxes are decomposed into observable stages. The analogy is a decision aid, not permission to split early. Require evidence that specialization reduces tool-search error, attention dilution, or contextual load enough to offset coordination cost.
Early agent products often begin as one agent with one broad prompt and many tools. That is a reasonable prototype because it keeps latency, state, and debugging in one runtime. The diagram below shows an intermediate design: specialist agents exist, but they still share the same process and memory.
Monolithic Multi-Agent Architecture
Specialist agents already exist, but they still share one process and one memory.
Select a node to inspect what it buys and what it still couples
Coordinator
Routes the request to the right specialist and keeps simple local coordination in the parent prompt.
What is the tool-selection error rate and context utilization before any specialist is added?
Internal specialization can reduce the search space. A research specialist sees research tools; an analytics specialist sees query tools. Each prompt becomes more focused, while the parent retains simple local coordination. This is still a monolith from an operational perspective. One deployment, one runtime, and often one failure domain own the complete experience.
Do not split merely because the workflow has several steps. Split when the evidence shows a stable boundary, such as:
- A domain needs different access or security controls.
- A team must deploy and evaluate its capability independently.
- Context from one task actively degrades another.
- A capability needs a different model, latency target, or scaling profile.
- An external provider owns the expertise and maintenance cycle.
Use a build-vs-buy decision for every proposed specialist.
The vendor agent makes the choice concrete. Early on, the parent can apply a short compliance rubric itself. If compliance instructions begin to crowd out vendor analysis, an internal specialist in the same runtime reduces the search space. If a central compliance team must release its policy independently, that specialist may cross into a remote service. If an official provider already maintains regulatory mappings near the source data, consuming it may be cheaper than rebuilding-but only with an , data review, fallback, and exit path.
| Option | Prefer when | Hidden cost or risk | Evidence before commitment |
|---|---|---|---|
| Keep one agent | Workflow is early, tightly coupled, and one team owns the complete loop | Monolithic ceiling: tool confusion, context overload, and one failure domain | Tool-selection error, context utilization, latency, and inability to isolate releases |
| Internal specialist in the same runtime | A stable cognitive/tool boundary exists but shared state and low latency still matter | It looks modular while deployment, memory, and incidents remain coupled | Quality lift from reduced search space without network overhead |
| Build a remote specialist | Capability is differentiating and the organization can own its prompts, tools, evals, security, and upstream change cycle | Ongoing maintenance tax and independent service operations | Strategic value, named team, eval advantage, SLO, and three-year |
| Consume an official remote specialist | Another domain owner has deeper expertise and maintains the capability near its source system | Vendor dependency, price changes, data transfer, and service failure | Capability/eval fit, contract, exit path, data review, SLO, and fallback |
Once a specialist crosses a network or organizational boundary, the product becomes distributed. The orchestrator now delegates to a remote participant that can maintain its own task state, ask questions, and recover independently.
Distributed Multi-Agent Architecture
Once a specialist crosses a network or organizational boundary, the product becomes distributed.
Select a node to inspect what the network boundary adds
Network boundary
Turns a local function call into a service call with latency, authentication, and partial-failure modes.
Which identity and permissions travel with each request, and what happens when the hop fails mid-task?
The distributed diagram adds flexibility, but it also adds network failure, versioning, identity, service availability, and vendor dependency. The Product Manager must decide what the user sees while a remote agent works, how long the parent waits, what evidence is returned, and what happens if the specialist becomes unavailable halfway through a task.
Bounded tools, unbounded collaboration, and the GOTO problem
A tool works best in a bounded domain: one validated request, a predictable result shape, and a short-lived call. A specialist agent works in an unbounded problem-solving domain. It may discover a contradiction, ask the user to choose a trade-off, pause for missing information, revise its plan, or end without the artifact originally expected.
getVendorEvidence(vendorId) is bounded: the caller supplies one ID and receives one schema. “Decide whether this vendor's retention terms satisfy our policy” is not. The compliance participant may find a missing data-processing agreement, ask which region will store data, wait for legal input, then revise its conclusion. Treating that conversation as one tool call hides the pause and makes the parent guess whether silence means working, blocked, failed, or abandoned.
Forcing that collaboration into a fire-and-forget tool wrapper creates the agentic equivalent of a GOTO problem. Control leaves the parent's structured workflow and may return later, return in a different state, or never return because the user abandons the task. The parent prompt then accumulates custom branches for interruptions, clarification, resumption and cancellation.
Keep MCP bounded and predictable. Move genuinely multi-turn responsibility into A2A, where the lifecycle is visible. If a capability always returns one schema-valid answer without negotiating, it is probably still a tool; do not create a remote agent merely for architectural fashion.