Agent Architecture and Orchestration
Multi-agent Orchestration — Stack
Multi agent orchestration › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
The substrate you pick decides what topologies are expressible, what you can see while they run, and whether a failing participant takes everything with it.
- Topology expressiveness. Whether the mechanism can represent the arrangement you want, or whether you will be bending a supervisor abstraction into a pipeline shape.
- Communication substrate. Direct calls, a message broker, or a shared artefact — and specifically whether a participant can observe another's work without being sent it.
- Cross-participant observability. Whether a single trace spans the whole effort with causal ordering, or whether you get one trace per participant and a correlation identifier to join them by hand.
- Collective budget enforcement. Whether spend, wall clock, and iteration count can be capped for the group, not merely per participant.
- Replay and determinism. Whether an effort can be re-executed from its record, which is the only practical way to debug emergent behaviour.
- Failure containment. What a worker crash does: fails the objective, triggers a retry, or is absorbed and reported.
- Human insertion points. Whether a person can be made a participant, inspect the shared artefact mid-effort, or stop the group.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Framework graph runtimes (LangGraph, AutoGen, CrewAI, Google ADK, Semantic Kernel agent framework) | Teams wanting topologies as code with checkpointing and tracing already wired in | Framework-shaped topologies; replay fidelity varies widely and is rarely as complete as advertised |
| Durable workflow engine with agents as activities (Temporal, Restate, AWS Step Functions) | Long-running efforts where surviving restarts and auditability outrank iteration speed | Determinism rules constrain agent code; the engine's retries and the agent's retries must be reconciled |
| Message broker with agents as consumers (Kafka, NATS, RabbitMQ) | Loosely coupled fleets, cross-team ownership, high participant counts | Causal ordering must be built by you; emergent interaction patterns are extremely hard to reason about |
| Actor runtimes (Ray, Dapr, Orleans) | Compute-heavy efforts with many concurrent participants and placement control | Operational surface of a distributed runtime for what is often a coordination problem, not a scaling one |
| Shared artefact over a database or object store | Efforts that converge on a document, plan, or dataset rather than a message exchange | Concurrency control is entirely your problem; participants need discipline about what they may amend |
| Cross-organisation agent protocols (A2A and similar) | Participants owned by different companies or trust domains | Identity, authorisation, and liability questions arrive before the technical ones |
| Single agent with sub-agents behind tool calls | Most products that believe they need a multi-agent topology | Loses peer interaction entirely, which is the point — verify the interaction was actually needed |