Building and Shipping Voice AI for regulated industries
Most software teams ship code. We ship conversations.
When you're building voice AI for regulated industries - healthcare, insurance, financial services - a bad merge doesn't just break a feature. It breaks a phone call. A patient hears the wrong information. A caller gets routed to nowhere. A compliance boundary gets crossed.
The stakes are high, and it's of utmost importance that we build the confidence we need to implement the changes.
It's not a short read but I promise it's worth your time.
The problem with "CI green, ship it"
Traditional CI works fine for traditional software. Run the tests. Check the linter. If it's green, merge.
But voice AI isn't traditional software. A single pull request can change four things at once: application code, infrastructure configuration, prompt behavior, and workflow routing. Each of those can break the system independently. Together, they can break it in ways no single test catches.
Here's what we've seen go wrong:
- A prompt change passes all unit tests but produces hallucinated responses in a live conversation.
- An infrastructure update deploys cleanly but disconnects the voice channel from the right data region.
- A workflow config change routes calls to a test number instead of production.
- A code change passes locally but fails when the full service mesh is wired together.
None of these would have been caught by a green CI badge. They needed something more.
What "something more" looks like
At Kolsetu, we build Elba - a voice AI platform for regulated industries. Our team ships across multiple data regions (EU, India, Israel, US, Africa, Australia), running multiple services per region, supporting multiple languages and the backend infra needed to provide the ultra simplistic UX.
We compete with companies a hundred times our size. We can only do that because we've invested heavily in one thing: knowing - not hoping - that every pull request is safe to merge.
We wrote a three-part technical series on how we built this system. Here's the short version of what we learned.
Lesson 1: CI is not your merge gate
This is the foundation. CI tells you whether individual steps passed. It doesn't tell you whether all the right checks ran, in the right order, against the same artifacts, with the right dependencies satisfied.
That's the difference between validation (did this step succeed?) and orchestration (do we have enough confidence to merge right now?).
We moved orchestration out of people's heads and into the system.
Read the full deep-dive: CI is not your merge gate
Lesson 2: Separate the workers from the orchestrator
We use a two-layer architecture:
Layer 1 - GitHub Actions: Individual test workflows. Each one does exactly one thing: run code quality checks, build a Docker image, spin up a test environment, run a synthetic call. These are deterministic, idempotent and reproducible - run them locally or let CI run them, same result.
Layer 2 - GitHub Agentic Workflows: An orchestration layer written in plain English markdown, compiled into strict YAML contracts. The agent doesn't execute tests. It decides which Actions to dispatch, in what order, and whether the outputs meet the bar for merge.
This separation matters because the test logic stays where engineers can debug it, while the orchestration logic stays where it can enforce policy.
Read the full deep-dive: Build it so it doesn't blow up
Lesson 3: Test the whole system, not just the code
Here's what actually happens when one of our engineers or our triage agent opens a pull request; we spin up an entirely new and isolated ephermel environment for each PR. And some of the checks we do:
Code quality and security: Linting, type checks, security scans across all services.
Build and deploy: Docker images built, pushed to container registry, deployed to an ephemeral environment that exists only for this PR. No shared staging. No contamination from someone else's changes.
Wire the environment: The ephemeral backend connects to this PR's frontend. Secrets are updated. The control plane routes to the feature branch's data plane.
Create Test Data: We create all the test data required to be able to test the core platform functionality and happy paths - created automatically for this PR.
Deploy workflows: We deploy the workflows across channels deployed from our blueprint manifest. Coverage validated: every phone number wired, every language covered. It's a LOT of work to do - we have wrapped it around in a skill.
An AI calls the AI: A synthetic voice agent dials the deployed phone number with a scripted conversation; covering multiple different scenarios. The call is recorded. Latency, intent recognition, and response quality are evaluated automatically.
Previously, a human would make that phone call. Listen to the response. Check the logs. Decide if it sounded right. We still do the human annotation but that's less 5 % of the previous workload.
Now, all of such activities are automated via agentic workflows. It's a skill for the system - one that runs on every pull request, every time.
In the end we reach to: One merge decision. No ambiguity.
Lesson 3.5: Operating it is where most teams fail
The demo is easy. Month three is hard.
Three predictable gaps appear: human approval queues become bottlenecks that engineers route around, observability built for single linear jobs breaks down when you're running distributed agentic systems, and teams start measuring agent runs instead of whether delivery actually got better.
The fix is treating agentic workflows like the distributed systems they are. Build for replay, not just retry. Measure outcomes (lead time, revert rate), not activity (number of gate runs). Define human approval boundaries as architecture decisions, not habits.
Read the full deep-dive: Operating it - the part nobody shows you
Why this matters for voice AI specifically
Voice AI is unforgiving in three ways that most software isn't:
It's real-time: There's no "loading" state. A caller is waiting. Latency isn't a dashboard metric - it's an awkward silence. And if you think of voice AI as just another API, you're missing the point - your voice AI product is already an agent. It makes decisions, takes actions, and handles workflows autonomously. That's a fundamentally different risk profile than a request-response service.
It's regulated: In healthcare, insurance, and financial services, what your AI says has compliance implications. A regression isn't just a bug - it's a liability. We've written about what it takes to build GDPR-compliant systems and how we think about security and compliance as a foundation, not an afterthought. Merge gates are where that foundation meets your daily shipping workflow.
It's multi-modal: A voice AI system isn't just code. It's prompts, workflows, phone routing, language models, telephony infrastructure, and real-time audio processing - all wired together. A change in any one of those can break the conversation. When AI agents handle regulated workflows, the blast radius of a bad merge extends far beyond the code diff.
That's why "CI green, ship it" isn't good enough. You need to test the whole system - code, infrastructure, prompts, and voice - together, on every pull request.
What you can take away
If you're building voice AI - or any AI system where regressions have real-world consequences - here's what we'd suggest:
- Separate orchestration from validation: Don't conflate "this step passed" with "we're ready to merge."
- Make your constraints architectural, not procedural: Safe-outputs and hard boundaries beat policy documents and trust.
- Write prompts like protocols: "Must" and "fail if" - not "try to."
- Test the full system per PR: Code changes, infrastructure changes, prompt changes, and voice quality - together.
- Let AI test AI: Synthetic voice calls replace manual verification and scale with your team.
- Delegate to Agentic workflows: Think what do you have to do today in order to merge a PR successfully? And, start breaking it down into skills that can be executed by agents.
Come see it live
I'm presenting this system at LLMday Hamburg on June 18, 2026. If you're in Hamburg, come say hi - I'll walk through the full pipeline live, from pull request to synthetic voice call.
This post is part of our series on GitHub Agentic Workflows in production:
At Kolsetu, we build Elba - AI Workforce for regulated industries. Every pattern described here runs in our production system. Learn more at kolsetu.com.
Virendra Singh Bhalothia
