Anyone can spin up a hundred AI agents. The frameworks are open-source, the models are commodity, the tutorials write themselves. The hard part — the part nobody shows in the demo — is getting those hundred agents to behave like a team instead of a hundred independent contractors all emailing the same client at once.
Orchestration is the actual problem in multi-agent systems. Specialization is easy.
What orchestration actually solves
When you put more than a handful of agents in the same workflow, four problems show up immediately:
- Shared context. Who knows what, and when. Agent A finishes a task; does Agent B see the result, a summary, or nothing?
- Conflict resolution. Two agents reach contradictory conclusions about the same customer. Which one ships?
- Escalation paths. An operator hits a case it cannot handle. Where does it go, and who decides?
- Scope boundaries. An agent designed to write subject lines should not also be deciding budget reallocations. How is that enforced at runtime, not just at prompt-design time?
Flat peer-to-peer agent meshes — the default in most agent frameworks — fail all four at scale. They work for three agents in a demo. They fall apart at thirty.
Hierarchy as a primitive
S.V.I. is built on a 3-tier core that nests fractally. The base pattern is small:
- Tier 1 — Mai (1 agent). The AI concierge. One face to the client, the single entry point for every cross-department request.
- Tier 2 — Board of Directors. A small group of strategy-level agents who analyse, prioritise, and coordinate across departments. Usually 3–7. For SVI Marketing we run 4.
- Tier 3 — Server-level Agents / Department Heads. One per sub-server, one per functional department. Each runs its own department end-to-end.
That same 3-tier pattern then duplicates inside each department. The Server Agent of a department plays the role of "local Mai" for its own subtree, with its own Managers and Employees underneath. So the full visible system is five layers:
Mai → Board → Server Agents (Department Heads) → Managers → Employees
The architecture is self-similar. If a company needs more depth, the same 3-tier block keeps nesting further down. Five layers is currently enough to cover any company of any size we have encountered.
Numbers are calibrated per client
There is no fixed agent headcount. The shape stays constant; the population per layer changes per company.
- SVI Marketing's own deployment runs about 225 agents: 1 Mai + 4 Board + 10 Server Agents (we have ten functional departments) + 40 Managers (4 per department) + 170 Employees (~17 per manager). The Employees are the actual workers — performance marketers, copy strategists, GDPR analysts, frontline operators, recruiting screeners.
- A large enterprise running HandOfHands-style end-to-end coverage scales the same shape into the thousands of agents. The Board may sit at 5–7, departments at 15–20+, Managers per department and Employees per Manager all calibrated to the workload.
This five-layer shape solves the four problems above directly. Conflict resolution has a path — escalate to the Server Agent, then to the Board. Scope stays enforced by routing — Employees reach other departments only through their Manager, then their Server Agent, then Mai. Context flows up and down predictable channels instead of broadcasting to the whole mesh.
The work hierarchy: Bundle, Scenario, Module
The agent hierarchy is who does the work. There is a parallel hierarchy for what they assemble. Orchestration only makes sense once you separate the two.
- Bundle (stack). A combination of several neural networks working together to solve one specific task. Each model is a narrow specialist at its own stage. Example — the "video script" bundle: Net 1 gathers information, Net 2 generates text, Net 3 processes visuals, Net 4 edits and verifies.
- Scenario. A sequence of several bundles for a complex multi-stage task. Bundles run in the right order and pass their output along. Example — the "produce a social-media video" scenario: bundle "video script" → bundle "video generation" → bundle "titles and descriptions".
- Module. A reusable block built from several scenarios. Modules cover whole business functions, and the entire platform is assembled from modules. Example — the "publish video" module: scenario "produce video" → scenario "publish to social networks" → scenario "first-pass analytics".
So the hierarchy of work artifacts is Bundle → Scenario → Module. The agent hierarchy above decides who owns and runs each one. An Employee typically owns a bundle. A Manager composes scenarios out of those bundles. A Server Agent owns whole modules — that is what makes it a department head rather than a worker. Mai and the Board reason at the level of modules and the policies that bind them together.
Confusing the two hierarchies is the most common mistake we see in early multi-agent prototypes. Who the agent is and what the agent assembles are independent design problems and need separate vocabulary.
Message routing and Mai's gateway role
Every cross-department message routes through Mai. If marketing needs sales pipeline data to time a campaign, the request goes Mai → sales board → specialist → back through Mai with the validated response. No direct calls between departments.
This sounds like a bottleneck. In practice it is the opposite — it is the only way to keep audit trails coherent, to enforce data scope per department, and to give the client a single coordinated voice instead of five agents from five teams emailing them in the same hour.
Mai is also where the client talks to the system. One concierge, one history, one tone. Behind her there might be ninety agents collaborating on a single answer. The client sees a conversation.
State management
Memory is partitioned at three levels: per-client, per-department, per-agent. A specialist in client A's marketing department cannot see anything from client B or from client A's support department. The boundaries are enforced by the sub-server isolation described in our security model — different processes, different storage, different audit streams.
Every state change is logged. Every memory read is logged. When something looks wrong six months later, you can replay the exact context an agent had at the moment it made a decision.
Failure handling
Agents fail. Models hallucinate, APIs time out, third-party services rate-limit. The orchestration layer assumes failure as the default state and is designed to absorb it.
Fallback chains route around degraded specialists to backup specialists. When a node goes down, the system fails over to a backup facility within seconds. Self-healing routines — themselves run by AI agents — restart failed processes, replay state from the audit log, and notify coordinators of what happened. No human on a pager waiting to manually restart a worker.
SVI Marketing holds 99.9% SLA. HandOfHands holds 99.95%. Those numbers are achievable because failure handling is part of the orchestration, not a separate ops team's problem.
Why hierarchy beats flat at this scale
Peer-to-peer agent meshes are elegant on a whiteboard. They scale like O(n²) communication overhead in practice, conflicts have nowhere to escalate to, and scope creep is structural — every agent can in principle call every other agent.
Hierarchy gives you bounded communication paths, explicit decision authority, and enforceable scope. It is how every functional organization with more than ten people has been structured for the last few thousand years, and it works for the same reasons when the agents are software instead of humans.
How to start
If you want to go deeper on the architecture itself, read the platform architecture page and our companion piece on how multi-agent platforms work. The enterprise deployment that puts the full fractal hierarchy behind one client — scaling from a couple of hundred agents to several thousand depending on the org — is covered in the HandOfHands overview. The isolation guarantees that make per-department memory enforceable are detailed in our security model. When you are ready to see what your own org chart looks like rendered as an agent hierarchy, talk to Mai.