A developer built a seven-agent sales pipeline and discovered something nobody talks about: the architecture matters more than the agents.
The system routes leads through qualification, research, proposal generation, objection handling, follow-up scheduling, sentiment analysis, and final summarisation. Seven specialised agents, each handling one slice of the pipeline. The interesting bit isn't what each agent does - it's how they talk to each other.
Most people assume multi-agent systems work like a conversation: agents passing messages back and forth, negotiating, deciding together. That's the dream. The reality is messier. Agent-to-agent communication creates exponential complexity. Seven agents means 42 potential communication paths. Add one more agent and you're at 56 paths. The coordination overhead kills you before you ship anything useful.
Star Topology: One Router, Many Leaves
The solution that actually works in production: star topology. One central router. All agents are leaves. The router reads shared state from Firestore, decides which agent to invoke next, calls it, waits for the result, updates state, and repeats. No agent talks directly to another agent. No negotiation. No consensus-building. Just clean, conditional routing logic in one place.
This isn't a new idea - it's how orchestration works in distributed systems. But the pattern is quietly spreading across agentic architectures because it solves the same problem: when you have specialised workers, you need a conductor who knows the score.
The router checks four things: Has qualification happened yet? Did the prospect respond? Is there an objection logged? Has follow-up been scheduled? Each check routes to the next agent. The logic sits in one function. You can read the entire flow in 50 lines of code. That's the win - not clever agent communication, but boring, debuggable control flow.
Observable State Changes Everything
Shared state in Firestore means every decision is auditable. The router doesn't remember what happened - it reads it. Each agent writes its output to a known location. The next agent reads from there. If something breaks, you open Firestore and see exactly where the pipeline stalled. No distributed tracing. No log aggregation. Just a document that shows the current state of the lead.
This matters more than people realise. Multi-agent systems fail in weird ways. An agent hallucinates a fact. Another agent takes that fact as input and compounds the error. A third agent generates a proposal based on nonsense. Without observable state at every step, you're debugging blind. With it, you can replay the exact decision trail that led to the failure.
The system also handles conditional branching without agents needing to understand the pipeline. If sentiment analysis detects frustration, the router skips proposal generation and goes straight to objection handling. The sentiment agent doesn't need to know that rule exists. It just writes a score. The router reads the score and decides. Clean separation of concerns.
What This Means for Real Systems
This pattern is showing up everywhere production agentic systems actually ship. Anthropic's computer-use demo uses a similar structure - a controller decides which tool to invoke based on current state. LangGraph calls it a "supervisor pattern". Microsoft's Semantic Kernel has a planner that routes between skills. Different names, same topology.
The reason is simple: agentic systems are state machines with LLM-powered nodes. Trying to make them self-organising swarms adds complexity without solving the core problem. You still need someone to decide "qualification failed, skip to nurture sequence" or "proposal accepted, trigger contract generation". That decision logic has to live somewhere. Putting it in a central router means it's testable, debuggable, and maintainable.
For anyone building multi-agent systems right now, the lesson is this: start with the topology, not the agents. Figure out the state transitions first. Draw the decision tree. Then build agents that fit the tree. The agents are the easy part - they're just LLM calls with prompts. The hard part is knowing when to call which agent, and making that logic visible to the humans who have to maintain it.
The seven-agent pipeline isn't impressive because it has seven agents. It's impressive because someone thought hard about how they'd coordinate before writing a single line of agent code. That's the architecture choice that makes the difference between a demo and a system that runs in production for six months without falling over.