When AI voice agents made our core product obsolete, we didn’t upgrade it — we launched a new one alongside it.

XOIP provides phone numbers to small and medium businesses with a simple call configuration layer: routing, voicemail, office hours, blocked numbers. The differentiator has always been approachability — unlike enterprise telecom, SME owners can configure this themselves, without a telecoms engineer.

AI voice agents change the competitive landscape entirely. An agent can do everything XOIP’s legacy routing does, and also answer questions from a knowledge base, handle appointments, look up customer data, and respond naturally in any language. This capability was previously inaccessible to SMEs at an affordable price point.

The question wasn’t whether to build it. It was whether to bolt it onto the existing product, or treat it as something fundamentally new.

I explored whether the voice agent could be introduced as a progressive enhancement to the existing call plan — an AI layer on top of the current product. I did the design work to test this path. It didn’t hold.

The existing product’s philosophy is simplicity through constraint: SME owners configure a finite set of rules. An AI voice agent removes those constraints entirely — its behavior is open-ended by design. Fitting an unlimited-behavior product into a limited-behavior interface would have communicated exactly the wrong thing to customers: that this was just a smarter IVR.

The decision: launch as a separate product with its own onboarding, its own pricing tier, and a clear migration path from classic subscriptions. There was reasonable pushback — separate products mean more surface area to maintain. A live demo resolved it.

The initial design direction was conventional: a form-based UI where SME owners fill in fields to configure how the voice agent behaves. Cards, inputs, dropdowns. It worked. But it was a category error.

Asking someone to configure an AI agent through a settings panel is like building a touchscreen interface you can only operate with a keyboard. The paradigm doesn’t fit the medium. If the product is intelligent enough to answer calls naturally, the owner should be able to instruct it naturally too.

Early testing revealed a consistent failure pattern: when configuring a new call routing rule, the agent would correctly ask for some required details but miss others. Setting up ”Transfer billing questions to the Billing Department” might capture the phone number but omit office hours — or capture both but fail to ask what happens after hours. And if it did ask that, it might forget to request the voicemail email address.

The fix combined prompt engineering with guardrails in the orchestration layer — ensuring the agent completes a full configuration checklist before confirming any rule as set. Each routing configuration now has a defined set of required fields that must be resolved before the agent closes the loop.

Manual review of voice sessions doesn’t scale. Every call is an implicit test, but without structure, the learnings evaporate. So I built an automated evaluation layer that runs on every user session.

It operates in two passes. The first is deterministic: did the agent capture all required fields for each configuration action? Did it confirm back correctly? The second is AI-judged: did the user actually achieve their intent by the end of the conversation? A separate judge model reviews the full transcript and returns a verdict with the evidence it used.

The output is a set of prioritized eval cards — concrete, actionable findings I can review directly. The next step is routing those cards to AI coding agents for automatic remediation: a voice agent product that identifies its own gaps and closes them without a human in the loop for every session.

The chat configuration UI is functional. The multi-modal voice interface is operational. The routing, knowledge, and agent settings views are complete. The eval system is running on live sessions. What’s ahead: customer-facing launch, pricing model validation, and building out the self-healing loop from eval cards to automated fixes.

What I’d do differently: I’d design the configuration completeness guardrails before the first user test, not after. The checklist logic for each routing rule type was obvious in retrospect — it should have been in the prompt design from the start, not remediated after watching users hit the gap in testing.

I’d also have invested in the agent persona earlier in the process. The trust effect — that SME owners give richer, more complex instructions to a named, characterful agent — only became clear in testing. We shipped the persona picker as a direct response. But had I designed for this from the start, persona selection would have opened the onboarding flow, not lived inside settings.