A support agent built for your industry fits your rivals too

The agent market is splitting into platforms you build on and specialists that arrive ready to go. A specialist is tuned to the typical company in your sector, and the part of your service worth keeping is where you differ from typical.

What happened

BBN Times published a survey of the companies building AI agents in 2026. It covers the model makers, the enterprise software firms adding agents to products you already run, and a group of specialists: Cognition for software engineering, Harvey for legal work, and Sierra and Decagon for customer service.

The useful part is the split the piece draws across all of them. Horizontal platforms give you tools to build agents for almost any function, and they sell flexibility. Vertical companies focus on one job, and they sell an agent already tuned to "a particular workflow, dataset, evaluation method and business outcome." The article expects both models to last and suggests many large organisations will buy from each.

Its list of what makes an agent valuable is shorter than its list of vendors. Access to proprietary data comes first. Then depth of integration into the actual workflow, whether the agent completes tasks correctly rather than demonstrating well, and whether it earns more than it costs to run, monitor and govern.

Why this matters to your business

A vertical support agent is a sensible purchase for the part of your queue that looks like everyone else's. Password resets, order tracking, a returns policy that reads like every other returns policy in retail. A specialist vendor has seen those conversations by the thousand and tuned for them, and rebuilding that yourself would be money spent to stand still.

The trouble is in what tuned means. An agent shaped around your sector's workflow is shaped around the average company in your sector, and your competitors are in that average too. The reasons customers stay with you tend to live where you depart from it: the goodwill credit your best agents grant without asking, the order in which you check a warranty claim, the way you handle a customer on their third contact in a week. A packaged agent either lacks those rules or asks you to squeeze them into its settings screen.

Now look at which of the article's success factors belong to the vendor. The proprietary data is yours: the tickets, the resolved cases, the account history. The integration runs into your systems. What the specialist brings is the tuning and the evaluation method. Hand the whole support operation to one package and the two assets that make an agent valuable end up improving a product your competitor can buy next quarter.

Specialisation also does not settle the accuracy question. Harvey's own benchmark found that under a strict all-pass standard, frontier models completed fewer than 10% of the legal tasks it tested end to end. Whoever you buy from, the test that counts runs on your work, against your definition of a correct answer.

Why this is a CX-Builder use case

The article frames the choice as one kind of vendor or the other. For a support operation, the more practical line runs through your own queue. Buy generic handling where your service is generic, and own the logic where your service is yours.

CX-Builder is the build side of that line, running on your own servers. You assemble the agent that carries your exceptions: retrieval over your policy documents and past resolutions, connectors into the CRM and order system you already use, and a human approval step on the decisions where your judgement departs from the industry default. The tickets and outcomes it works from stay on infrastructure you control, and the rules sit in a flow your team can open, read and change.

It can also work beside a specialist rather than replacing one. Let the vertical agent take the routine volume, and send the cases that need your rules to a CX-Builder flow through its API. You pay for packaged tuning where it helps and keep ownership of the part that makes you different.

What this looks like if you build it

Start before any tooling. Ask your most experienced agents which rules they apply that the policy document does not mention, and which customers get treated differently and why. That list is the specification.

In CX-Builder it becomes one agentflow. A document store holds the written policy alongside those unwritten rules, now written down, and a vector store over resolved tickets lets the agent find how similar cases were actually settled. Tool nodes read order and account history from your systems of record. A condition node checks whether the case falls under one of your exceptions, and an approval node puts anything involving credit, a refund or a policy override in front of a person before it commits. Every run is logged with the documents it retrieved, so over time you collect an evaluation set drawn from your own tickets instead of a vendor's benchmark.