Why we built 6 AI specialists instead of one AI assistant

The first version of SideKyk was one AI assistant. It was terrible.

Not terrible in the obvious way — it didn't crash, it didn't hallucinate constantly, it answered questions correctly often enough to demo well. It was terrible the way a generalist consultant who's read every book but worked no real job is terrible: technically competent, contextually useless. It wrote a sales follow-up in the same breath as a sprint retro and treated both like homework assignments. A prospect's objection about pricing and a stand-up update about a blocked ticket share zero context, but our one AI carried both anyway, in the same conversation memory, using neither well. That's the JARVIS fantasy — one AI that does everything — and the fastest way to ship a mediocre product.

We killed that version in about six weeks. Here's the multi-agent AI architecture B2B teams actually need — how we chose AI specialist agents over a general assistant, why we drew the domain boundaries where we did, the routing mistake that shipped to production before we caught it, and what we'd change if we started over.

The JARVIS fantasy and why it ships a mediocre product

Anyone building AI agents for business in 2026 starts with the same instinct on the first whiteboard: one AI business assistant architecture, one chat window, ask it anything. It's the natural first build. It's also, we think, structurally doomed for B2B operations — not because the model isn't smart enough, but because "does everything" and "does everything adequately" are the same sentence.

A general-purpose assistant carrying sales, marketing, ops, support, and social in one context window doesn't get smarter by holding more domains — it gets vaguer. Ask it to draft a cold email and it hedges toward generic B2B copy because it's also holding a support ticket's tone in short-term memory. Ask it for a sprint retro and it drifts toward marketing-speak because that's what half its recent turns looked like. Context doesn't average out cleanly across domains; it pollutes.

This isn't just our anecdote. Gartner projects that by the end of 2026, roughly 40% of enterprise applications will include task-specific agents, up from under 5% in 2025 — and the direction of travel is unambiguous: purpose-built beats general-purpose once you're past the demo stage. Salesforce's 2026 Connectivity Report found enterprise IT leaders expect multi-agent adoption to grow 67% by 2027. Nobody's converging on "one bigger assistant." Everyone's converging on specialists.

How we drew the boundaries — and the test we used

The harder question wasn't "should we split this up." It was "into how many pieces, drawn where." Our first temptation was to mirror an org chart — a founder-facing agent, a manager-facing agent, an IC-facing agent. That's the wrong axis. Org hierarchy doesn't predict shared context; workflow does.

So we mapped the workflows that actually repeat, week over week, for an early-stage AI/SaaS team: content, sales, support, ops, social. Then we ran one test on every candidate boundary: would a human with this job title carry radically different context day to day? If yes, that's a real boundary — split it. If two workflows shared roughly 80% of their working context, that became a skill inside one agent, not a separate agent.

That test is why we landed on 6, not 3 and not 12. Three would have re-merged genuinely distinct contexts — Sales and Marketing don't share a working memory just because they both touch "the pipeline." Twelve would have split single workflows into fragments no human would recognize as a job. Six specialists, each owning a domain a real operator would recognize: Ops & PM, Sales & Lead Gen, Marketing & Content, Customer Support, Social Media, and the Concierge that fronts all five.

This is one of our core AI agent design principles now: draw boundaries around where context actually diverges, not around where an org chart says it should.

The concierge router: one experience, six specialists

None of that matters to the person on the other end of the chat, and it shouldn't. The user never picks a specialist. They send one message, in one conversation, and concierge agent routing decides which of the six AI specialists actually owns that context — we just call the router "the Concierge." This is the same pattern LlamaIndex and others describe as concierge-style orchestration — a single visible chat surface, hidden multi-agent routing underneath, with persistent state so the seams don't show. We didn't invent the pattern. We just needed it to actually work for a WhatsApp-native operator.

It mostly did, immediately. Then it hit the failure mode every concierge-routed system eventually hits: ambiguous intent. "Update the pitch deck" — is that Sales, protecting a live pipeline conversation, or Marketing, protecting brand narrative? Early on, the router guessed, and guessed wrong often enough that we noticed a pattern in the flagged conversations.

The fix wasn't a smarter classifier. It was a tiebreaker rule: when intent is genuinely ambiguous, route to the user's last active context rather than trying to out-think the ambiguity. If you were just talking pipeline with Sales, "update the pitch deck" stays with Sales. If you were just in a content review with Marketing, it stays there. Simple, legible, and it turned out to match what users actually expected far better than a more "intelligent" disambiguation layer did.

The handoff mistake we made (and fixed) in production

The boundary and the router were the easy parts to get conceptually right. The handoff protocol between specialists is where we actually shipped a bug.

Our first version passed only the current message across a handoff — Sales routes a support-adjacent question to Support, and Support receives just that one line. It reads clean in a design doc. In production it meant the receiving specialist had none of the prior turns, so it re-asked questions the user had already answered two messages earlier. "What's your account email?" — already given. "Which plan are you on?" — already given. Nothing breaks loudly here; it's a slow trust leak. Users don't file a bug report for "the AI asked me something twice." They just get quietly more skeptical of the whole system.

The fix: a handoff carries the full session state, not the triggering message. The receiving specialist inherits the entire working context — what's been asked, what's been answered, what the user is actually trying to accomplish — and picks up mid-thread instead of cold-opening. It sounds obvious written down. It wasn't obvious the first time we designed it, because "just pass the message" is the version that ships fastest and looks correct in a demo with one exchange.

What we'd do differently — and why SideKyk runs this architecture for every client

If we were starting over, we'd draw the six boundaries around decision authority from day one instead of discovering it after a few conflicts. Sales owns pipeline prioritization. Marketing owns the content calendar. When those collide — a big-logo prospect wants a custom one-pager that would blow the week's content plan — the agents don't silently negotiate a compromise. They escalate to the human operator, who sits above all six the way a board sits above a management team, setting priorities the specialists execute against. We think of it as a board-of-directors model: the specialists run the business day to day, the operator makes the calls that require judgment.

We'd also warn our past selves about the temptation to keep splitting. There's a well-documented trap where teams building multi-agent vs single agent SaaS products push toward 8-15 agents for a single workflow, chasing ever-finer specialization, and end up with 10x the cost, agent-to-agent behavior nobody can predict, and a system that's genuinely not production-ready. We stopped at six by refusing to add a seventh until the first six had proven their value in real usage — multi-agent architecture is a cost you pay for a real problem, not a default you reach for because it sounds sophisticated.

This is the architecture every SideKyk client actually gets, not a special version we built once and wrote about: a concierge fronting six domain specialists, full-context handoffs between them, and the human operator sitting above all six as the board that sets priorities when two specialists want different things. If that's the operating model you've been trying to approximate with a single chatbot and a lot of prompt engineering, sign up at sidekyk.ai/ai-business — we walk you through which specialist handles what in the first session.