Multi-Agent vs Single Assistant: When to Split Roles

In enterprises, “multi-agent” means several executable role packs—each with its own knowledge boundary, tool allowlist, refuse rules, and acceptance metrics—wired by a router or workflow. It is not one mega-prompt that claims to be sales, legal, and ops at once. A single assistant fits few intents, one ACL tier, and almost no writes. When secrecy, write rights, or model cost collide, forcing one assistant raises both hallucination and blast radius. GeonAI designs splits and orchestration per scenario; /agents are capability references only (not a public trial of all 363+ presets). Email [email protected]. Selection: /blog/ai-agent-selection-checklist.

Define the split: role packs, not chat windows

Decide on conflicting boundaries, not how many avatars appear in a vendor demo.

Four hard signals—treat split seriously if ≥2 apply

0–1 signals: harden the single assistant (intents, citations, handoff). ≥2: do a minimal split—usually one router + 2–3 specialists, not eight at once.

Three topologies that ship

1) Router + specialists (most common)

An entry classifier (rules or small model) sends intents to specialists. Specialists do not share write tools. Fits support: policy Q&A / tracking read-only / refund drafts. Accept on route accuracy and cross-specialist leakage.

2) Sequential pipeline

A extracts fields → B retrieves policy → C drafts → human confirms. Fits pre-sales packs and QC summaries. Each step has structured I/O and timeouts; never let step N invent on top of step N−1 noise.

3) Parallel retrieve + merge (with human)

Hit KB and ticket/OMS together, then merge before generation. The merge layer must handle conflicts (disagreeing sources → handoff). Fits “policy + order status” questions.

Worked example: e-commerce after-sales

Most teams earn B after A has citations/handoff and refund mis-ops become the risk. Jumping to C is a common crash. Support: /blog/custom-customer-service-agent. Commerce: /blog/ecommerce-agent-conversion.

Real multi-agent costs (put them in the budget)

• Mis-routes: wrong specialist → wrong promise or useless handoff; needs its own QA
• State passing: session id, retrieved docs, slots must be explicit across specialists—not “the model remembers”
• Duplicated knowledge: copied policies drift; keep one source of truth + role views
• Harder observability: split latency, missing-citation, missed-handoff by specialist (/blog/poc-to-production-agent-checklist)
• Larger tool surface: each writable specialist adds blast radius and audit fields

Anti-patterns (stop if you see them)

1. “Multi-agent debate” with no human node and no audit, then auto-send externally
2. Specialists freely calling each other’s write tools without a gateway allowlist
3. Treating many preset persona names on /agents as a live orchestration
4. Splitting bots but keeping one ACL-free mega KB
5. Drawing an “Agent mesh” for a deck when the business has five FAQ intents

Pilot split checklist (paste into the SOW)

1. List conflicting boundaries: ACL / writes / model tier / external vs internal
2. Pick a topology (default router+specialists); draw entry and human nodes
3. Per specialist: intents, refuses, tool allowlist, acceptance metrics
4. Define degrade copy for route failure and specialist timeout
5. Gray one channel first; report route accuracy and leakage weekly
6. Add specialists only after pass—do not spawn empty shells in parallel

Tool calling with ERP/CRM: /blog/agent-function-call-mcp-integration. Delivery: /blog/enterprise-ai-agent-delivery-4-steps.

How to brief GeonAI

Say which hard signal is blocking your single assistant, what entry UX you must keep, max specialist count you will operate, and whether routing rules already exist. Email [email protected], /pricing, or Live chat. We favor the smallest acceptable split—not a decorative multi-agent diagram.