IVR Voice Agent — Work Case Study

Problem

Resolve Systems' virtual support agent was built for asynchronous chat, where a two-second reply feels snappy. A phone call is a blocking, real-time channel — callers hear every hop in the pipeline as silence. The platform needed a voice channel without rewriting the existing chatbot backend.

My role

Designed the architecture end to end and implemented it: intent routing, speech-to-text and text-to-speech orchestration across Amazon Connect, Amazon Lex, AWS Lambda and Polly, and the handoff into existing fulfillment.

The part that made it possible was not voice-specific. I designed and built the Factory Method integration layer the chatbot platform runs on: every channel normalizes into one envelope, a factory instantiates the right adapter, and fulfillment operates on intents and entities without ever branching on channel.

The property that mattered is that the abstraction is neutral about time. Slack, Teams, Google Chat and Webex are asynchronous; a phone call is synchronous and blocking. Both are adapters. The interface makes no claim about whether a reply arrives in two seconds or two hundred milliseconds, so voice was added against an interface that already existed rather than forking production infrastructure to accommodate it. Getting that boundary right first is the reason the hardest channel was addable at all.

Constraints

• Voice latency budgets are unforgiving — callers notice sub-second gaps that chat users never see.
• The asynchronous fulfillment backend was production infrastructure shared with every chat channel; it could not be forked for voice.
• Enterprise security requirements — authentication, secrets handling — applied to every new hop.

Architecture

Amazon Connect captures audio and streams to Lex for intent resolution; a Lambda bridge translates between the synchronous IVR flow and the asynchronous chatbot backend, then Polly synthesizes responses back into the call. Downstream lookups start speculatively on utterance-start instead of after intent resolution, and a caller's journey is correlated across Connect, Lex, Lambda, and downstream APIs so traces survive the channel boundary.

Outcome

Shipped as a production channel of the virtual support agent platform that helped reduce help-desk call volume by 40–60%.

Where it went next

The channel has since moved off the AWS stack to Vapi, which does more of the real-time orchestration as a platform than the assembled-primitives approach did. That is worth stating plainly: after the effort of building the bridge, a purpose-built voice platform turned out to be the better agent. Evaluation of further voice platforms is ongoing and runs in parallel with that work, because the deciding constraints on this kind of system are rarely only technical.

What survived the migration is the part I would keep building the same way — the integration layer underneath. Because fulfillment never branched on channel, replacing the voice front end did not touch it.

What I'd do differently

Design cross-service correlation in from day one rather than adding it during hardening — traces that die at a channel boundary are not traces. And budget for barge-in cancellation semantics early: every in-flight synthesis becomes cancellable, which changes idempotency requirements downstream.