December 2025 Update: Now includes patterns from OpenAI’s Swarm, Anthropic’s multi-agent research, and production examples from leading AI companies.
What is Agentic Architecture?
Agentic Architecture refers to design patterns for building AI systems where multiple specialized agents collaborate to solve complex problems. Instead of one monolithic agent, you have:- Specialized agents with focused capabilities
- Orchestration to coordinate agents
- Communication protocols between agents
- Shared memory/state for collaboration
Key Insight: Complex tasks are better handled by multiple specialized agents than one generalist agent trying to do everything. This is how OpenAI’s o1 and Claude’s research capabilities work internally.
Why Multi-Agent?
Real-World Multi-Agent Examples
Architecture Patterns
1. Supervisor Pattern
One agent orchestrates specialized worker agents.2. Debate Pattern
Agents argue different perspectives to reach better conclusions.3. Pipeline Pattern
Sequential processing through specialized agents.4. Swarm Pattern
Dynamic team of agents that can spawn/dismiss members.Memory Patterns
Shared Memory
Long-Term Memory with Vector DB
Communication Patterns
Message Bus
Error Handling & Reliability
Observability
Best Practices
Keep Agents Focused
Keep Agents Focused
Each agent should have a single, clear responsibility. Avoid “god agents” that try to do everything.
Define Clear Interfaces
Define Clear Interfaces
Specify exactly what each agent expects as input and produces as output.
Implement Timeouts
Implement Timeouts
Always set timeouts for agent operations to prevent hanging.
Log Everything
Log Everything
Log agent decisions, inputs, outputs, and errors for debugging.
Test in Isolation
Test in Isolation
Test each agent independently before integrating.
When to Use Multi-Agent
Interview Deep-Dive
You are designing a multi-agent system for an enterprise workflow. How do you decide between the Supervisor pattern and the Swarm pattern?
You are designing a multi-agent system for an enterprise workflow. How do you decide between the Supervisor pattern and the Swarm pattern?
Strong Answer:
- The Supervisor pattern is the right default for most enterprise workflows because it provides a single point of control, making it easier to reason about execution order, debug failures, and enforce business rules. The supervisor acts as an explicit router: it receives the task, decides which agent to delegate to, collects results, and decides what to do next. This maps well to workflows with well-defined stages like “research, then analyze, then write.”
- The Swarm pattern is appropriate when the task is highly dynamic and you cannot predict at design time how many agents you need or what types. For example, an incident response system where you might need to spawn a log-analysis agent, a metrics-analysis agent, and a customer-communication agent depending on the nature of the incident. Swarm excels when parallelism and adaptability matter more than predictable execution.
- The key trade-off is control versus flexibility. Supervisors give you deterministic routing and clear audit trails but can become bottlenecks if the supervisor LLM makes poor routing decisions. Swarms give you emergent problem-solving behavior but are harder to debug, harder to test, and harder to set cost guardrails on because agents can spawn other agents unpredictably.
- In practice, most production systems I have seen use a hybrid: a supervisor pattern for the top-level orchestration with swarm-like behavior within specific subtasks. For example, the supervisor routes a research task to a research sub-system, and that sub-system uses a small swarm of specialized search agents internally. This gives you control at the macro level and flexibility at the micro level.
- One often-overlooked factor: the supervisor pattern degrades more gracefully. If one worker agent fails, the supervisor can retry, route to an alternative, or return a partial result. In a swarm, a failing agent can create cascading confusion because other agents may depend on its output without clear fallback paths.
The Debate pattern has agents argue different sides of an issue. When does this actually improve output quality versus just wasting tokens?
The Debate pattern has agents argue different sides of an issue. When does this actually improve output quality versus just wasting tokens?
Strong Answer:
- The Debate pattern genuinely improves output quality in specific scenarios: when the task requires considering trade-offs, when there are legitimate multiple perspectives (policy decisions, architecture choices, risk assessments), or when you need to stress-test a conclusion. The mechanism works because each agent is forced to find weaknesses in the other’s argument, which surfaces edge cases and counterexamples that a single agent would miss.
- It wastes tokens when the answer is factual and unambiguous. Having agents debate whether Python was created in 1991 is pure waste. It also underperforms when the LLM does not have strong enough knowledge to construct genuine counterarguments, in which case the “con” agent generates superficial objections that dilute rather than sharpen the analysis.
- The biggest value I have seen from the Debate pattern is in code review and architecture decisions. Having a “pro” agent argue for a particular design and a “con” agent argue against it produces surprisingly thorough analysis. The judge agent then synthesizes a recommendation that accounts for trade-offs neither side would have surfaced alone.
- For production, I limit debates to 2-3 rounds. Research shows that most of the information gain happens in the first 2 rounds; beyond that, agents start repeating themselves with slight variations. Each additional round costs 2 LLM calls (pro + con) plus the context of all previous arguments, so the cost grows quadratically with context.
- An underappreciated optimization: instead of running the debate at generation time (making the user wait), run it offline as a batch process for common query types. Pre-debate the top 100 most-asked questions in your domain and cache the judge’s synthesis. Then at serving time, retrieve the cached debate outcome and only run a live debate for novel queries.
Walk me through how you would add observability to a multi-agent system in production. What metrics matter most?
Walk me through how you would add observability to a multi-agent system in production. What metrics matter most?
Strong Answer:
- Observability in multi-agent systems is harder than single-model applications because you need to trace a request across multiple agents, each with their own LLM calls, tool invocations, and state mutations. The foundation is distributed tracing: assign a trace ID to each user request and propagate it through every agent invocation, so you can reconstruct the full execution path.
- The metrics I track fall into three categories. First, per-agent metrics: latency per agent call, success/failure rate, token consumption, and the distribution of tool calls each agent makes. Second, orchestration metrics: how many agents were invoked per request, how many rounds of debate or supervisor loops, and which routing paths are most common. Third, quality metrics: user satisfaction signals (thumbs up/down), answer accuracy on a held-out evaluation set, and the percentage of requests that hit the max-iterations safety cap.
- The most important single metric is “steps to completion,” which tells you how efficiently the agent system is solving tasks. A rising trend means either the tasks are getting harder or the agents are degrading. Combined with per-agent failure rates, this helps you pinpoint which agent is struggling.
- For implementation, I use structured logging where each log entry includes the trace ID, agent name, step number, input summary, output summary, latency, and token count. I pipe these into an observability platform (Langfuse, LangSmith, or a custom Grafana dashboard) that lets me search by trace ID to reconstruct any request. The AgentTracer class in this chapter is a good starting point, but in production you want this integrated with your existing observability stack rather than standalone.
- A practical tip: log the full LLM prompts and responses for a sample of requests (say, 5%) rather than all requests. Full logging of every request generates enormous data volumes and privacy concerns. But having no prompt logs makes debugging hallucinations or routing errors nearly impossible.