Something has happened to customer service in the last two years that most enterprises still haven’t fully absorbed: the first line of support stopped being human, and nobody voted on it.
The capital tells the story. In June 2026, Salesforce agreed to acquire Fin, formerly known as Intercom, for approximately $3.6 billion, folding its AI customer service agent directly into Agentforce. Sierra, Bret Taylor’s AI agent company, raised $950 million in May 2026 at a $15.8 billion valuation, on the strength of more than $150 million in annual recurring revenue and a customer list that includes over 40% of the Fortune 50. Decagon, Ada, Cresta, and a dozen others are chasing the same opportunity. This isn’t an emerging trend anymore. It’s a land grab, and it’s going to keep growing.
Why this makes sense
Every enterprise with a contact center is looking at this and asking the same question: why are we still paying humans to answer “where's my order.”
The economics are straightforward, and they’re not going away. Agentforce alone crossed $1.2 billion in annual recurring revenue in Q1 of Salesforce’s fiscal 2027, up 205% year over year. Fin claims to handle more than two million customer conversations a week. Human agents who receive AI-generated context resolve tickets 35 to 45% faster than agents starting from scratch. When a single AI agent can plausibly absorb a shift’s worth of tier-one support volume, the board math writes itself. Every enterprise with a contact center is looking at this and asking the same question: why are we still paying humans to answer “where’s my order.”
For simple questions, they’re right to ask. The problem starts one step past that.
The problem
There’s a real line in what these systems are being asked to do, and most of the market is pretending it doesn’t exist.
Task Type
What the Bot Needs
Risk Level
Answering a question is low risk because being wrong just means a bad answer. Executing something is a different category entirely, because being wrong means an action actually happened. And when that action sits inside a regulated workflow, being wrong isn’t an inconvenience, it’s an incident.
These systems are already producing them. Virgin Money’s AI chatbot mistakenly reprimanded a customer for using the word “Virgin” while asking about merging ISAs. DPD had to disable part of its AI chat system after a customer got it to swear and write a critical poem about the company, blamed on a bad update. Cursor’s own support chatbot, run by an AI agent named “Sam,” confidently told a user that a device-limit policy existed when it didn’t, and the company had to walk it back as a hallucination, notable because this is a company built by AI engineers, still getting caught flat by their own support bot inventing policy. And the legal exposure is no longer theoretical: courts have treated the Air Canada chatbot case as establishing that a company is responsible for what its chatbot says, full stop.
This isn’t a fringe problem. The MIT AI Incident Tracker classifies more than 1,300 real-world reported incidents drawn from the AI Incident Database, and the database added 108 new incidents in just the November 2025 to January 2026 window alone. The failure rate isn’t shrinking as adoption grows. It’s compounding.
If your chatbot invents a return policy, that’s a bad day. If your chatbot invents a step in a GLBA-regulated account change, or skips a disclosure requirement in a healthcare intake, that’s a compliance incident with a regulator’s name attached to it.
Two schools of thought
Everyone chasing this market has landed in one of two camps.
School one: make the AI model trustworthy.
This is Sierra’s bet, and a well-funded one. Take a frontier LLM, wrap it in guardrails, supervise it, iterate until the error rate is low enough to put in front of customers. The pitch to a regulated enterprise is, in effect: trust us, we’ve trained this hard enough that it won’t embarrass you. It’s real engineering, and it produces real results. It is also, at its core, a probabilistic promise. The model is still guessing. Guardrails lower the odds of a bad guess. They don’t remove the guess.
School two: make the AI model unnecessary for execution
This is Callvu’s bet. AI agents still sit at the front of the interaction, still assess the request, still evaluate risk and context, same as School One. The difference is what happens next. The agents don’t execute anything. They hand a directive to a deterministic orchestrator, and the orchestrator, not a model, is what touches the system of record and runs the workflow. The AI’s job ends at judgment. Execution is code, not inference.
Why this isn't just a different flavor of the same thing
Two claims get made in every AI vendor pitch right now: this will cut your service costs, and this is safe enough to trust. School One and School Two make the exact same cost claim, for the exact same reason. Both put an AI agent at the first line of contact. Both deflect the easy tier-one volume away from human agents. The cost efficiency story isn’t a Sierra innovation, it’s what happens any time you put a competent LLM in front of a queue. Callvu captures it identically. Cost is not the differentiator. Anyone telling you otherwise is selling you the part of the story that isn’t actually in dispute.
The claim that’s actually in dispute is safety. And here School One has a ceiling it cannot engineer past: no matter how much guardrail work goes into it, the system is still a model deciding what to do, and a model deciding what to do is still capable of deciding wrong. You can push the error rate down. You cannot push it to zero, because the architecture itself is probabilistic. It’s a better-trained black box. Still a black box.
School One (Sierra)
School two (Callvu)
That last row deserves its own explanation, because it’s the part most vendor pitches skip.
The economics of the arms race
School One isn’t a one-time engineering cost, it’s a subscription to an arms race, and arms races don’t have a finish line.
The math is unforgiving. Getting an LLM from 85% reliable to 95% is real work, but it’s tractable, you’re fixing the common cases. Getting from 99% to 99.9% costs more than everything before it combined, because you’ve run out of common cases. What’s left is a long tail: the customer who phrases a request in a way nobody trained for, the account state nobody anticipated, the policy exception nobody wrote a guardrail for. Every one of those gets caught, triaged, and tuned out one at a time. Then the product changes, or a regulation updates, or a new workflow gets added, and the tail grows back. There is no version of “we finished chasing the error rate.” There’s only “we’re still chasing it, and the bill is still running.”
The data backs this up. Testlio found that 39% of AI-powered customer service bots got pulled back or significantly reworked because of hallucination-related errors, not launched once and left alone. Independent measurements put ungrounded hallucination rates in live customer service interactions at 15 to 27%. That’s not a rounding error you patch in a weekend. That’s a standing engineering commitment.
That commitment shows up in the pricing, because it has to. A model that needs continuous tuning needs continuous people tuning it. Sierra’s own pricing structure tells the story without anyone having to argue it: a subscription floor that starts around $150,000 and scales past $1.5 million a year with complexity and volume, professional services layered on top for implementation, and a per-resolution fee stacked above both. The floor moves because the tuning work moves. More workflows, more channels, more edge cases, more services hours, more invoice. That’s not a criticism of the execution, the team is good at this. It’s a statement about what the architecture requires. A probabilistic model in the execution path has to be kept in line by someone, indefinitely, and someone is paying that someone.
Callvu doesn’t carry that tax, because we’re not tuning a model’s behavior toward compliance, we’re writing the compliance down once as a rule and enforcing it structurally. A GLBA identity-verification requirement doesn’t get “mostly” enforced and then improved next quarter. It’s enforced at runtime, every time, from the day the rule is written. When a regulation changes, someone edits a rule. Nobody retrains a model and holds their breath hoping it didn’t regress three other behaviors while fixing this one. The cost of staying compliant scales with how many rules exist, a number you control and that goes down as you consolidate, not with how many ways a language model can be wrong, a number nobody controls and that never goes down.
So the honest long-run comparison isn’t cheaper AI versus more expensive AI. Both schools put an agent at the front door for roughly the same economics. The real comparison is a bounded, falling cost to write and maintain a rule versus an open-ended bill to chase a model that will never quite stop being wrong. One of those has an end state. The other is priced like it never will.
Where school one breaks: a regulated example
Take the single most common regulated interaction in banking: a customer asking to update their mailing address. It sounds trivial. It isn’t. An address change is a known vector for account takeover fraud, it can trigger identity re-verification requirements, and under GLBA it has to be authorized, disclosed, and consented to in a way the bank can prove after the fact, not just assert.
School One
School one’s version: a conversational agent, guardrail-trained to ask for identity verification before changing sensitive account data. Most of the time, it works exactly as designed. But the guardrail is still a learned behavior sitting on top of a probabilistic model, and probabilistic behavior has edge cases. Maybe the account already carries a fraud flag the model wasn’t weighted to catch. Maybe the customer’s phrasing routes around the verification prompt, the same way DPD’s and Cursor’s support bots got routed around their own guardrails in public, documented incidents. When it fails, what does the bank have? A conversation transcript. Not a record of what was verified, what was disclosed, what was consented to, just a log of what was said. That’s not evidence a regulator accepts. It’s a starting point for an investigation.
School Two
School two’s version: the same request hits six pre-flight agents before any screen even renders. They evaluate identity verification status, fraud risk, and which disclosures the policy requires, in this case GLBA. The orchestrator issues one of three directives, deterministically. If the account is clean and low-risk, Execute. If it’s not, Execute With Safeguards, meaning the customer sees the identical, seamless experience, but the runtime silently requires stronger identity verification. In Callvu’s live banking workflow, that’s knowledge-based authentication plus a one-time passcode, before the write to the system of record is allowed to happen at all. If something’s structurally wrong, Block. The customer never gets an address change that skipped verification, because the architecture makes that outcome unreachable, not just unlikely.
Every step produces an immutable evidence artifact: identity verification method and timestamp, disclosure acknowledgment, consent acknowledgment, execution result, all tied to a specific workflow version and policy version, reconstructible to that single transaction months later. That’s the difference between “we believe this was handled correctly” and “here is the record proving it was.”
Same customer request. Same front-line AI cost savings. One architecture produces a transcript. The other produces evidence.
Where this leaves you
Every vendor in this category will tell you their AI makes fewer mistakes. Some of them are even right. But “fewer mistakes” was never the question a regulator, a compliance officer, or your own board actually asks. The question is: can you prove, for any given transaction, that the wrong thing could not have happened. School One can’t answer that question no matter how good the model gets, because the model is still the thing making the decision. School Two doesn’t have to improve the model to answer it, because the model was never the thing deciding in the first place.
If you’re running AI in front of a regulated workflow today, or about to, that’s the question worth asking your vendor before you ask about resolution rates. And if you want to see the answer instead of taking our word for it, the sandbox is live at try.callvu.com. Run a real regulated workflow, on our AI or point your own AI at it, and look at the Audit Trace yourself.
