Your support queue is three queues. Route it that way.

Every vendor on the shortlist is best for somebody. The useful question is not which type of company you are. It is how many different kinds of question land in your inbox before lunch.

What happened

Technology.org published a rundown of seven agentic AI platforms for customer support. It is a competent list. What makes it worth reading is not the ranking but the sorting logic underneath it.

Read the "best for" lines and you see a market that has segmented itself by buyer profile rather than by problem. One is for large contact centres running voice and digital at volume. One is for consumer brands that need tight control over tone. One is for small and mid-market teams that want to be live in a week. One is for regulated sectors that need redaction and audit trails. One is for global firms with legacy systems nobody wants to touch. Two are for companies already standardised on a particular helpdesk.

So the buying question the list poses is: which of these descriptions is you? Pick your box, buy the matching product.

Why this matters to your business

The trouble is that the box describes a company, and your costs are driven by tickets. Those are not the same unit.

Open last month's queue and look at what is actually in it. A large slice is repetitive and low stakes: order status, password resets, opening hours, changing a delivery address. A middle slice needs someone to read a policy properly, like a warranty edge case, a return outside the window, or a discount that should have applied and did not. A small slice touches money, health data, identity or a contract, where being wrong is not an inconvenience but an incident.

Those three groups have wildly different economics. The first should cost pennies and resolve in seconds. The third should cost more per ticket than a human hour, because the alternative is a chargeback, a regulator, or a customer who leaves and tells people why.

Buy one platform tuned to one profile and you pay for that mismatch twice. Pick the compliance-grade option and you are running redaction, audit logging and slow careful reasoning over the 60 per cent of traffic that is somebody asking where their parcel is. Pick the fast, cheap, live-in-a-week option and the 5 per cent that should never have been automated goes down the same pipe as everything else, at speed, with confidence.

There is a second trap in lists like this, and it is the resolution rate. One vendor in the roundup cites 83 per cent automated resolution. That number is real and it is also not yours. It is an average across their customer base, which skews toward the mix of tickets their product was built for. Your 83 per cent might be 95 on the routine lane and 20 on the messy one. The blended figure hides exactly the thing you need to see.

Why this is a CX-Builder use case

If your queue holds three kinds of question, the first decision is not which model answers them. It is which lane each question goes down.

That is a routing problem, and it is the shape CX-Builder builds well. Classify at the front door, then give each lane its own handling. The routine lane gets a small, fast, cheap model and a short retrieval step over your help content, and it closes the ticket. The policy lane gets grounded retrieval over the actual terms and warranty documents, so the answer cites something rather than recalling it. The sensitive lane gets held: the agent drafts, a person approves, and the whole exchange is logged.

These are not three products. They are three paths in one flow, sharing your connectors, your knowledge base and your brand voice, with different cost and different caution applied on purpose instead of by accident.

It also changes what you can measure. Once traffic is split by lane, you get a resolution rate and a cost per ticket for each one, on your own volume. That is the number a budget conversation actually needs, and no vendor case study can give it to you.

What this looks like if you build it

One agentflow, a classifier at the entry, and a condition node that fans out to three branches. Each branch names its own model, so you are not paying frontier prices to confirm a delivery date. The policy branch points at a vector store built from your terms, returns policy and product documentation, so the answer is grounded in a document you can show a customer. The sensitive branch adds a human approval step before anything is sent or executed, and it is the only branch with permission to touch a refund or an account change.

It runs self-hosted, so regulated traffic never leaves infrastructure you control, and the classification decision itself is logged with the ticket. When someone asks why a case took the slow route, there is an answer.