Architecture Patterns

"One agent solves a problem. Two agents solve it differently. Three agents schedule a meeting to discuss the problem."

Census, Hierarchically Orchestrated AI Agent

1. Foundational Patterns

Multi-agent architectures define how agents are organized, how work flows between them, and how decisions are made. The choice of architecture pattern has a profound impact on system reliability, latency, cost, and the types of tasks the system can handle. Six patterns have emerged as the most practical for production systems: supervisor, pipeline, mesh, swarm, hierarchical, and debate.

The supervisor pattern places a single orchestrating agent in charge. The supervisor receives tasks, decides which specialist agent should handle each subtask, routes work accordingly, and synthesizes results. This is the most common pattern in production because it provides a clear control point for monitoring, cost management, and error handling. The supervisor's routing logic can be as simple as a classification prompt or as complex as a planning agent with its own tool set.

The pipeline pattern arranges agents in a linear sequence where each agent transforms the output of the previous one. A content generation pipeline might flow through Research Agent, Outline Agent, Draft Agent, Edit Agent, and Fact-Check Agent. Pipelines are simple to understand and debug because the data flow is predictable. They work well when the task naturally decomposes into sequential stages with well-defined inputs and outputs.

2. Advanced Topologies

The mesh pattern connects agents in a peer-to-peer network where any agent can communicate with any other. This is the most flexible topology but also the hardest to debug and monitor. Mesh patterns emerge naturally in systems where agents need to negotiate or share information bidirectionally. The A2A protocol discussed in Section 23.3 provides a standard for mesh communication.

The swarm pattern (popularized by OpenAI's Swarm framework) uses lightweight agents that hand off tasks to each other through a simple transfer mechanism. Each agent in the swarm has a focused role and a set of handoff targets. When an agent determines that the task needs a different capability, it transfers the conversation to the appropriate agent. This pattern is particularly effective for customer service scenarios where different query types require different specialist knowledge.

The debate pattern assigns agents opposing roles and has them argue toward a conclusion. One agent advocates for a position, another challenges it, and a judge synthesizes the best arguments into a final answer. Research shows that debate produces higher-quality outputs for tasks involving judgment, evaluation, and analysis. The key risk is sycophantic convergence, where agents agree with each other too readily rather than maintaining genuinely opposing perspectives.

Input: task T, specialist agents {A1, ..., An} with descriptions, LLM M, max rounds R
Output: synthesized result

1. Initialize results = []
2. for round = 1 to R:
 a. route = M("Given task T and results so far, select next agent or DONE")
 b. if route == DONE:
 break
 c. agent = lookup(route, {A1, ..., An})
 d. subtask = M("Extract the subtask for agent from T and context")
 e. result = agent.execute(subtask)
 f. results.append((agent, result))
3. final = M("Synthesize results into final answer for T")
return final
 

# Supervisor pattern with LangGraph
from langgraph.graph import StateGraph, END

def supervisor(state):
 """Route the task to the appropriate specialist."""
 response = llm.invoke(
 f"Classify this task and route to the best specialist:\n"
 f"Task: {state['task']}\n"
 f"Available specialists: research, coding, writing, analysis\n"
 f"Respond with just the specialist name."
 )
 return {"next_agent": response.content.strip().lower()}

def route(state):
 return state["next_agent"]

graph = StateGraph(AgentState)
graph.add_node("supervisor", supervisor)
graph.add_node("research", research_agent)
graph.add_node("coding", coding_agent)
graph.add_node("writing", writing_agent)
graph.add_node("analysis", analysis_agent)
graph.add_node("synthesize", synthesize_results)

graph.set_entry_point("supervisor")
graph.add_conditional_edges("supervisor", route, {
 "research": "research",
 "coding": "coding",
 "writing": "writing",
 "analysis": "analysis",
})
for agent in ["research", "coding", "writing", "analysis"]:
 graph.add_edge(agent, "synthesize")
graph.add_edge("synthesize", END)

from crewai import Agent, Task, Crew, Process

supervisor = Agent(role="Supervisor", goal="Route tasks to specialists")
researcher = Agent(role="Research Analyst", goal="Find information")
coder = Agent(role="Software Engineer", goal="Write code solutions")
writer = Agent(role="Technical Writer", goal="Produce clear reports")

task = Task(
 description="Research quantum computing advances and write a summary",
 agent=supervisor,
 expected_output="A researched summary report",
)

crew = Crew(
 agents=[supervisor, researcher, coder, writer],
 tasks=[task],
 process=Process.hierarchical,
 manager_agent=supervisor,
)
result = crew.kickoff()

3. Pattern Selection Criteria

Selecting the right architecture pattern depends on several factors. Task decomposability: can the task be broken into independent subtasks (favors supervisor or mesh) or sequential stages (favors pipeline)? Quality requirements: does the output need adversarial review (favors debate) or is a single pass sufficient? Latency budget: sequential patterns add latency proportional to the number of stages; parallel patterns trade latency for cost. Debuggability: simpler topologies (pipeline, supervisor) are easier to trace and debug than meshes or swarms.

Exercises