Architecture
Multi-agent coordination pattern where an orchestrator breaks work into subtasks, specialist agents pull from and push to a shared state store, and the orchestrator composes the final answer from that shared state. Multi-agent setups feel coherent instead of each assistant having its own inconsistent memory.
Orchestrator {
n1: circle label="Complex task arrives"
n2: rectangle label="Request shared context"
n3: rectangle label="Create research subtask"
n4: rectangle label="Create action subtask"
n5: rectangle label="Receive findings and results"
n6: rectangle label="Compile final answer"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> SharedMemory.n7.handle(top) [label="Read state"]
n3.handle(right) -> n4.handle(left)
n3.handle(bottom) -> Researcher.n9.handle(top) [label="Research task"]
n4.handle(bottom) -> Operator.n13.handle(top) [label="Action task"]
n5.handle(right) -> n6.handle(left)
Researcher.n12.handle(top) -> n5.handle(left) [label="Finding"]
Operator.n17.handle(top) -> n5.handle(right) [label="Result"]
}
Researcher {
n9: rectangle label="Receive research task"
n10: rectangle label="Read shared memory"
n11: rectangle label="Analyze with context"
n12: rectangle label="Return finding"
n9.handle(right) -> n10.handle(left)
n10.handle(right) -> n11.handle(left)
n11.handle(right) -> n12.handle(left)
n10.handle(bottom) -> SharedMemory.n7.handle(left) [label="Read state"]
}
Operator {
n13: rectangle label="Receive action task"
n14: rectangle label="Read shared memory"
n15: rectangle label="Execute with context"
n16: rectangle label="Write result to memory"
n17: rectangle label="Return result"
n13.handle(right) -> n14.handle(left)
n14.handle(right) -> n15.handle(left)
n15.handle(right) -> n16.handle(left)
n16.handle(bottom) -> SharedMemory.n8.handle(left) [label="Write state"]
n15.handle(bottom) -> n17.handle(top)
}
SharedMemory {
n7: rectangle label="Resolve memory request"
n8: rectangle label="Update shared state"
n7.handle(right) -> n8.handle(left)
}
Architecture
A supervisor-worker multi-agent architecture where an orchestrator agent receives a high-level goal, breaks it into subtasks, delegates each to specialist worker agents (researcher, writer, QA), monitors execution, handles failures, and synthesizes results. The orchestrator manages but does not execute tasks itself.
Architecture
An orchestrator-worker architecture where an orchestrator agent breaks a goal into subtasks, dispatches to specialized workers, then synthesizes a final response. This is the most common 'agent orchestration' architecture—powerful but the orchestrator can become a bottleneck as the number of workers grows. Frameworks like LangGraph focus on explicit routing/state to manage this.
Architecture
A hierarchical multi-agent architecture that scales orchestration by stacking supervisors and team leads (a tree structure), which mirrors enterprise org structures and helps partition context. This is the 'enterprise-grade agentic AI architecture' when a single orchestrator cannot manage all workers directly. Ideal for large enterprises and multi-domain workflows.
Architecture
A competitive / generator-critic architecture where multiple generators produce independent answers, then an evaluator agent scores and selects the best output. This approach improves quality and reduces single-model brittleness. It's costlier (multiple LLM calls) but pays off when correctness or creativity matters more than latency.
Architecture
A sequential pipeline multi-agent architecture where agents are arranged in a strict sequence. Each agent transforms or enriches the output of the previous one, then passes it forward. No central orchestrator — the flow is deterministic like an assembly line.
Architecture
A swarm multi-agent architecture where multiple agents work on the same or related tasks simultaneously, with no central coordinator. Their outputs are then aggregated, voted on, or merged by a dedicated aggregator node. Agents may compete — the best output wins.