Why dispatchers beat monolithic chatbots for L1 work

"One big chatbot with access to everything" is the design pattern that doesn't survive contact with real tickets.

It's the architecture that looks cleanest on a whiteboard. One LLM, one prompt, all the tools. Ask it anything. Show me your magic.

It breaks the moment your tenants have non-trivial workflows. Here's why, and what to do instead.

The monolithic-chatbot pattern

One agent. It has access to:

• The Syncro ticket
• M365 Graph (with broad permissions)
• Active Directory
• The KB
• Your custom client info
• A list of all the tools it can call

Every incoming ticket goes through the same agent. The agent figures out what kind of work the ticket is, picks the right tools, executes, and writes back.

Why it's appealing: simple to set up, easy to demo, sounds intelligent.

Why it breaks at scale:

1. Debugging is impossible. When something goes wrong, you have one giant prompt and one giant log to dig through. Was it a tool-choice problem? A reasoning problem? A context-window problem? Hard to tell, harder to fix.
2. Testing is impossible. You can't isolate the "password reset path" from the "M365 onboarding path" because they're the same agent. Every test is an integration test.
3. Updating is risky. Tuning the agent for one capability (say, better DL handling) risks regressing every other capability. You can't update one specialty without re-validating the rest.
4. Permissions are over-broad. The agent needs broad permissions because it handles everything. When the agent makes a mistake, the blast radius is "everything it has access to."

The dispatcher pattern

Split the work into two layers:

A dispatcher reads each incoming ticket, classifies what type of work it is, and routes it to a specialist. The dispatcher itself does no actual work. It's a router.

Specialist agents handle one type of work each. Password reset specialist. M365 user lifecycle specialist. DL management specialist. Printer triage specialist. Each has a tight scope, narrow permissions, and well-defined tools.

The flow:

ticket → dispatcher (classifies) → specialist (executes) → ticket update

What you get:

1. Debugging works. When something goes wrong, you know which specialist handled it. You look at that specialist's logs, with that specialist's scope.
2. Testing works. Each specialist has a contained test surface. Add a new ticket category? Test the specialist for that category. Other specialists are unaffected.
3. Updates are safe. Improving the password reset specialist doesn't risk regressions in the onboarding specialist. Each is a separately versioned, separately deployed unit.
4. Permissions are scoped. The DL specialist only has DL-management Graph permissions. The password specialist only has password-reset permissions. A bad action's blast radius is one specialty's worth.

The trade-off

Dispatchers cost more to build. You have to think about classification accuracy (does the dispatcher always pick the right specialist?). You have to design a fallback path (what if the dispatcher isn't sure?). You have a few more moving parts than the monolithic version.

What you trade for that complexity: a system that you can actually operate after the first developer leaves. Specialists you can add without re-validating everything. Logs that tell you where a problem happened.

The monolithic version looks simpler at hour one and feels simpler at hour fifty. The dispatcher version starts paying off at hour 200, when you've added the fifth specialist and nothing else broke.

When monolithic is the right call

If you have one capability (say, just password resets), a monolithic agent is fine. The overhead of building a dispatcher isn't worth it for a single specialty.

The moment you have a second specialty, the math flips. By the time you have five, the monolithic version is a debugging nightmare and the dispatcher version is just doing its job.

---

When did you last see a "we'll build one big chatbot" approach actually scale past 20 use cases?