One agent can't know your whole business. Use specialists.

A security firm split its AI investigator into twelve narrow agents. The lesson for support teams is where the hard work moved: deciding who answers, and noticing when the answers don't agree.

What happened

Group-IB, a security company, published a description of how its AI investigator is built. Instead of one agent that knows everything, it runs twelve specialists, each with its own tools: one for threat actors, one for malware, one for vulnerabilities, one for leaked credentials, and so on. An orchestration layer decides which specialist works next and pulls their findings together.

The authors are candid about where the difficulty sits. They name two problems as the hardest: routing, which means sending each question to the right specialist, and synthesis, which means deciding what the combined evidence actually supports. Their safeguards are plain ones. Specialists cross-check each other, answers have to be grounded in retrieved data, and chains of steps stay short, with a check back against the original goal at each step.

This is a vendor describing its own product, and the quality gains it reports come from its own testing. The design is the part worth borrowing, and it travels well outside security.

Why this matters to your business

Most companies build their first support agent as a generalist. One prompt, one knowledge base holding every policy, every tool attached. It demos well. In production it handles billing, returns and troubleshooting adequately and none of them well, and every mistake gets patched with another paragraph in the prompt. Eventually a fix for refunds breaks something in shipping, and nobody can say why, because there is only one thing to look at and it does everything.

There is a risk side too. Every tool the generalist holds can be triggered by any question. An agent that can both issue refunds and answer product questions can issue a refund while answering a product question.

Specialists change the cost of fixing things. When the returns agent gets something wrong, you change the returns agent, test it on returns, and nothing else moves. Each one carries only the documents and permissions its job needs, so a bad answer stays inside one topic.

Why this is a CX-Builder use case

The shape is a small team with a dispatcher. A routing agent reads the customer's message and hands it to a worker: a billing agent with read access to invoices, a returns agent with the returns policy and an order lookup, a technical agent searching only the product manuals. A final step assembles one reply from whatever came back.

Group-IB's two hard problems show up here unchanged. A router that sends a refund question to the technical agent produces a confident, well-sourced answer to the wrong question. So when the message is mixed or the router is unsure, the flow asks the customer a clarifying question or passes it to a person rather than guessing. And when two specialists disagree, say billing shows the customer inside warranty while returns says the window has closed, the flow hands both answers to a person, who decides. That disagreement is usually a gap in your own policy, and it is worth finding.

What this looks like if you build it

In CX-Builder this is one agentflow. A condition agent classifies the message and branches. Each branch is its own agent node with its own document store and its own short tool list. Each worker returns structured output (the answer, the source it relied on, how sure it is), which is what lets the merge step spot a conflict instead of blending it away. Conflicts and low-confidence routes go to a human input step, and iteration limits keep the chain short.

The execution trace records which specialist said what. When a customer disputes an answer, you can open the run and see which agent produced it and which document it leaned on.