Serve AI Rewrites Its Voice Agent on LiveKit and Lifts Call Containment 15%

From a 224-node graph to one prompt

Serve AI provides AI-powered phone agents that handle inbound customer calls for field service companies, calls that would otherwise reach a contact center. One of its largest customers is a pest control company doing about $150M a year that was spending $8M on a 100-person contact center. Serve now handles every inbound call for that customer, including account lookups, eligibility, scheduling, billing, and cancellations, and transfers calls to a human when needed.

The agent was originally built on Retell, where behavior is defined in a conversation flow graph. For this one customer, the graph grew to 224 nodes and over 600 edges, and a single change had become a day of work, according to LiveKit's account.

Anthony Rassi, Serve's CTO, decided to collapse the whole graph into one prompt on LiveKit, with the right procedure injected at each turn. LiveKit says this only became viable once smaller, faster models caught up. Rassi had read LiveKit's write-up on latency-optimized voice agents with Gemma and wanted to know whether a single-prompt agent on such a fast model could still hold the behavior the graph had enforced.

Testing the rewrite with Agent Simulations

The difficult part, the case study says, was not writing the new agent but knowing whether it did everything the old one did and could meet Serve's evolving needs. Rassi put it this way: "When you go from one agent architecture to another, you want to make sure the second works at least as well as the first, ideally better."

Rassi had been running evaluations on Hamming and had also looked at Coval and Bluejay. For his setup, each required more integration work than he wanted, including connecting external test harnesses into LiveKit rooms before he could begin evaluating. His needs were specific:

• Did the call end in the right state, such as an appointment booked for the correct Wednesday?
• Did the agent confirm the date before booking it?
• How long did the caller wait for a response?

Agent Simulations let him define and run those checks directly against the agent. He picked about a hundred production calls that the Retell agent had handled and used Claude to turn each into a simulation scenario. He then ran the rewritten agent against the set.

Results: 98% pass rate and 1.3 second latency

Over ten to fifteen iterations, Rassi adjusted the prompt until the suite reached a 98% pass rate. Median turn latency came in at 1.3 seconds, against a 1.5 second ceiling. Then Serve shipped. The first account took a week, and the migration involved no rollback.

In production, the rewritten agent did more than match Retell. According to the source, it increased containment by 15%, which Serve estimates saves the customer an additional $320,000 a year.

LiveKit attributes the gain to the architecture. In the old graph, a caller at the booking node who suddenly raised a billing question might have no defined path to follow, which caused the agent to improvise. With a single prompt, the full procedure is available at every turn, so the agent can handle those shifts more reliably.

What it means for voice agent teams

The case shows how a team can change the architecture of a live voice agent without relying on guesswork. By converting real production calls into test scenarios and setting explicit thresholds for outcomes and latency, Serve could iterate until the new agent matched expected behavior and only then cut traffic over.

For teams maintaining large flow graphs, the account suggests that a single-prompt design can reduce the cost of changes and handle off-script caller requests better, provided the behavior is verified before launch. The figures come from LiveKit's customer story and Serve's own estimates, and the source describes one customer's deployment.