Scaling Agentic Software

Most teams building multi-agent systems make the same mistake: they over-engineer the orchestration layer before they understand the workload.

I've seen teams build elaborate agent meshes with custom message brokers, shared memory stores, and complex routing logic — before shipping a single user-facing feature. The orchestration becomes the product, and the actual problem gets lost.

Here's the simplest architecture that actually scales:

1. A single orchestrator agent that owns the task decomposition.
2. Stateless worker agents that execute subtasks and return structured results.
3. A durable task queue (anything reliable — SQS, Redis streams, Postgres) connecting them.
4. A shared read model for results that both agents and humans can query.

That's it. No mesh topology. No peer-to-peer agent communication. No shared mutable state.

The orchestrator-worker pattern has been proven at scale in distributed systems for decades. The only thing that changes when you add agents is that the orchestrator's task decomposition is now a reasoning step rather than a fixed algorithm.

Start here. Add complexity only when you have concrete evidence that this architecture is the bottleneck. It almost never is.