Building Multi-Agent Systems with A2A: Architectures and Orchestration Patterns

Why Multi-Agent Systems

Single agents hit practical limits. A single agent that tries to handle every aspect of a complex workflow needs enormous context, diverse tools, and broad domain expertise packed into one system prompt. As the scope grows, the agent becomes harder to maintain, harder to test, and more likely to produce errors because its attention is divided across too many responsibilities.

Multi-agent systems address this by decomposing complex work into specialized roles. Each agent has a narrow scope: one handles financial analysis, another handles document generation, a third handles data visualization. Each agent can be built, tested, and improved independently. When the financial analysis agent needs to improve, only its prompts, tools, and training change. The other agents are unaffected.

A2A makes this decomposition practical across framework and organizational boundaries. The financial agent can be built on LangGraph and run on AWS. The document agent can be built on CrewAI and run on GCP. The visualization agent can be a custom implementation running on-premises. A2A provides the communication layer that lets these heterogeneous agents collaborate as a unified system without sharing code, runtimes, or internal state.

The economics also favor specialization. A specialized agent that handles one type of task well can use a smaller, cheaper model than a generalist agent that needs the most capable model for every interaction. The financial agent might run on a model optimized for numerical reasoning, while the document agent runs on one optimized for long-form writing. The system as a whole achieves better results at lower cost than a single agent running on the most expensive model available.

Orchestration Architectures

The orchestration architecture determines how agents discover each other, how tasks get routed, and who makes delegation decisions. Three primary architectures have emerged in production A2A deployments.

Centralized orchestrator. A dedicated orchestrator agent receives incoming requests, breaks them into subtasks, selects the appropriate specialist agent for each subtask, delegates via A2A, collects results, and assembles the final output. The orchestrator maintains knowledge of all available agents (their Agent Cards and capabilities) and makes all routing decisions. Specialist agents only communicate with the orchestrator, never directly with each other.

This architecture is the easiest to reason about and debug because all communication flows through a single point. The orchestrator has full visibility into the workflow, can log every delegation decision, and can implement centralized error handling. The downside is that the orchestrator becomes a single point of failure and a potential bottleneck. If the orchestrator goes down, the entire system stops. If it makes a poor routing decision, there is no mechanism for agents to self-correct. Centralized orchestration works best for workflows with a manageable number of specialist agents (typically fewer than ten) and well-defined task decomposition patterns.

Hierarchical delegation. Instead of a single flat orchestrator, agents form a hierarchy where each level handles increasing specificity. A top-level orchestrator delegates to team-level coordinators, which in turn delegate to individual specialist agents. Each coordinator manages a team of related specialists and handles the coordination logic specific to that team's domain.

For example, a top-level orchestrator receives a request to "prepare the quarterly business review." It delegates the financial section to a finance team coordinator, the operations section to an ops team coordinator, and the executive summary to a writing specialist. The finance coordinator further delegates to a revenue analysis agent, a cost analysis agent, and a forecasting agent. Each level of the hierarchy focuses on its own coordination concerns without needing to understand the details of agents lower in the tree.

This architecture scales better than flat orchestration because it distributes coordination logic across multiple agents. Each coordinator is simpler than a centralized orchestrator because it only manages its own team. The hierarchy also mirrors how human organizations work, making it intuitive to design and reason about. The tradeoff is increased latency (each level of delegation adds communication overhead) and more complex error propagation (failures must bubble up through multiple levels).

Peer-to-peer collaboration. Agents communicate directly with each other without a central orchestrator. Each agent knows about its potential collaborators (through pre-configured Agent Card URLs or a shared registry) and initiates delegation when it encounters a subtask outside its expertise. A research agent that finds it needs data visualization delegates directly to a visualization agent. A coding agent that needs its output tested delegates directly to a testing agent.

Peer-to-peer systems are the most flexible because agents can form ad-hoc collaboration patterns that were not predetermined by an orchestrator's logic. They are also the most resilient because there is no single point of failure. But they are the hardest to monitor and debug because there is no central point that sees all interactions. Workflows emerge from individual delegation decisions rather than being planned upfront, making it difficult to predict or guarantee the path a complex task will take through the system.

Task Delegation Patterns

Within any orchestration architecture, several patterns describe how tasks flow between agents.

Sequential chain. Agent A delegates to Agent B, which delegates to Agent C, each passing its output as input to the next. This pattern suits workflows with clear dependencies: gather data, then analyze it, then format the results. Each agent completes its task fully before the next agent begins. The final result flows back up the chain from C to B to A. Sequential chains are simple and predictable but slow because each step must wait for the previous one to finish.

Fan-out and fan-in. One agent delegates multiple independent subtasks to different agents simultaneously, then collects and combines all the results. The orchestrator sends a research task to three different specialist agents (one for market data, one for competitor analysis, one for customer feedback), waits for all three to complete, and then synthesizes the combined results into a unified report. Fan-out dramatically reduces total execution time for independent subtasks because the work happens in parallel. The fan-in step, where results are combined, is where the orchestrator adds value by resolving conflicts, eliminating redundancy, and creating a coherent final output.

Conditional routing. The orchestrator examines the incoming request and routes it to different agents based on content, type, or other criteria. A customer service orchestrator might route billing questions to a billing agent, technical issues to a support agent, and account management requests to an account agent. The routing logic can be rule-based (keyword matching, request type fields) or LLM-based (the orchestrator's model evaluates the request and selects the most appropriate agent from the available Agent Cards).

Iterative refinement. Two or more agents pass work back and forth, each improving the output. A content generation agent produces a draft. A review agent evaluates it and provides feedback. The generation agent revises based on the feedback. The review agent evaluates again. This cycle continues until the output meets quality criteria. Iterative refinement produces high-quality results but requires careful termination conditions to prevent infinite loops. Common approaches include setting a maximum iteration count, defining quality thresholds, or letting the review agent signal when the output is acceptable.

Managing Dependencies Between Tasks

Complex multi-agent workflows involve dependencies where one task cannot begin until another completes. Managing these dependencies correctly is essential for both correctness and performance.

The simplest approach is to have the orchestrator manage all dependencies explicitly. The orchestrator maintains a task graph where nodes are tasks and edges are dependencies. It submits tasks whose dependencies are all satisfied, monitors their progress, and submits dependent tasks as prerequisites complete. This gives the orchestrator complete control over execution order and allows it to optimize by identifying independent tasks that can run in parallel.

For more complex dependency graphs, orchestrators can use patterns from workflow engines. A DAG (directed acyclic graph) scheduler processes tasks in topological order, running parallel branches simultaneously and synchronizing at join points. Some orchestrator agents implement this scheduling logic directly, while others delegate it to external workflow engines (Temporal, Apache Airflow) that manage the execution graph while the agents handle the actual work.

Data dependencies, where one task needs the output of another as input, are handled through artifacts. When a prerequisite task completes, the orchestrator extracts the relevant artifacts and includes them as parts in the message for the dependent task. The orchestrator may need to transform the data between tasks if the output format of one agent does not match the expected input format of the next. This transformation logic is part of the orchestrator's coordination responsibility.

Error Handling Across Agent Boundaries

Errors in multi-agent systems are more complex than in single-agent systems because a failure in one agent can cascade through the entire workflow. The A2A task lifecycle provides the foundation for error handling (tasks can fail with descriptive error messages), but the orchestration layer must implement policies for how to respond to failures.

Retry policies. When a specialist agent fails, the orchestrator can create a new task with the same or modified instructions. Simple transient failures (network timeouts, temporary resource constraints) often succeed on retry. The orchestrator should implement exponential backoff and maximum retry counts to prevent infinite retry loops. Some failures are clearly not retryable (invalid input, unsupported task type), and the orchestrator should recognize these and escalate rather than retry.

Fallback agents. For critical subtasks, the orchestrator can maintain a priority list of agents capable of handling the same task. If the primary agent fails, the orchestrator delegates to a secondary agent. This requires that multiple agents advertise compatible skills in their Agent Cards. The fallback agent might be a different implementation (different framework, different model) that offers a different reliability-quality tradeoff.

Partial result handling. When a fan-out workflow has some tasks succeed and others fail, the orchestrator must decide whether to return partial results, retry the failed tasks, or fail the entire workflow. The right choice depends on the use case. A report with three of four sections completed might still be valuable. A financial calculation with one missing data source might be dangerously misleading. The orchestrator's error handling logic should encode these domain-specific decisions.

Timeout escalation. If a specialist agent's task remains in the working state beyond the expected duration, the orchestrator can cancel the task, try a different agent, or alert a human operator. Setting appropriate timeouts requires understanding the expected processing time for each skill, which can be informed by historical task completion data or by the skill description in the Agent Card.

Designing Agent Teams

The effectiveness of a multi-agent system depends heavily on how you decompose capabilities into individual agents. Several principles guide this decomposition.

Single responsibility. Each agent should do one thing well. An agent that handles both data analysis and report generation is harder to test, harder to optimize, and harder to replace than two separate agents each handling one function. When an agent tries to do too much, its prompts become long and conflicting, its tool set becomes bloated, and its error modes multiply.

Clear interfaces. The skills defined in each agent's Agent Card should have precise input and output specifications. Vague skill descriptions lead to mismatched expectations: the orchestrator sends a task expecting one output format, and the agent returns something different. Input and output schemas (JSON Schema in the Agent Card) formalize these interfaces and enable automated validation.

Independent deployability. Each agent should be deployable, updatable, and scalable independently. Upgrading the data analysis agent's model or prompts should not require redeploying the document generation agent. A2A enables this naturally because agents communicate through the protocol, not through shared code or runtime dependencies. But teams must resist the temptation to create tight couplings through shared databases, configuration files, or deployment pipelines.

Appropriate granularity. Too few agents create the same problems as a single monolithic agent. Too many agents create excessive communication overhead, complex orchestration logic, and fragile dependency chains. The right granularity depends on the workflow complexity, the team's operational capacity, and the desired level of specialization. A starting point is to create one agent per distinct domain expertise area, then split or merge agents based on operational experience.

Monitoring and Observability

Multi-agent systems require distributed tracing to understand how requests flow through the agent network and where problems occur. Standard distributed tracing approaches from microservices (OpenTelemetry, Jaeger, Zipkin) apply directly to A2A systems.

The most useful practice is to propagate a correlation ID through all A2A requests in a workflow. The orchestrator generates a unique correlation ID when it receives an incoming request and includes it as metadata in every task it delegates. Specialist agents include the same correlation ID in their own delegations. Log aggregation systems can then filter by correlation ID to see the complete execution trace of a single user request across all agents.

Metrics to track include: task completion rates per agent (how often each agent's tasks complete versus fail), task latency per agent and skill (how long each agent takes to process different types of work), input-required frequency (how often agents need clarification, which might indicate unclear task descriptions), and orchestration overhead (the time spent on routing, data transformation, and result aggregation versus actual agent processing time). These metrics identify bottlenecks, reliability issues, and optimization opportunities.