Healthcare.com ↗
National health insurance marketplace · contract voice engineering · 2026, ongoing
Building voice agents inside a national health insurance company
Under contract
Everything I build for Healthcare.com belongs to them, and their operational detail sits inside a confidentiality clause. No screenshots, no flows, no prompts, no call volumes. What follows is how the work was run, and the method I brought to it.
01
Built with the leadership team, not from a spec
Nobody handed me a requirements document.
- I scoped all 3 agents from scratch, sitting with non-technical executives and the leads of the teams whose numbers the agents were going to move.
- Mapped the use cases with those stakeholders, designed the conversation flows, then presented them back in plain language so the people signing off could actually judge them.
- Coordinated the build across product, engineering, marketing, compliance and operations. Inside a company this size, getting those 5 groups to agree is most of the work.
- Every flow had to clear compliance review before it could go near production. In a HIPAA-regulated business that is a gate, not a formality.
02
What the agent is not allowed to say
Everything the agent says has to survive a compliance review.
- Disclose that it is AI, early enough to matter and clearly enough that a distressed caller registers it.
- State it is not the government. Nothing may imply endorsement by Medicare, CMS or any federal agency.
- Read the Medicare disclaimer. Anyone marketing Medicare Advantage has to say specific wording set by CMS: that not every plan in the caller’s area is on offer, plus the pointer to 1-800-MEDICARE.
- Never state an answer it was not given. Not whether someone qualifies, not what it costs, not whether something is covered, and no softened version of any of those.
In most voice projects the hard part is making the agent sound natural. Here it is the opposite: making it stop cleanly, stay inside what it is allowed to discuss, and hand over before it guesses.
Callers make that harder, because they describe a situation rather than a product. I lost my job, my daughter ages off my plan in March. A phone menu sends them to the wrong place before the agent ever gets a chance.
03
How it decides what it can say
My framework, not theirs, so I can show it in full.
- Answer. In scope, and the answer already exists in approved copy.
- Answer, with the required wording attached. Allowed, but the law attaches specific words to it. Those words go out every single time, not when the model decides they are relevant.
- Refuse and point elsewhere. Close to what it covers, but not allowed. It says it cannot answer, says who can, and offers to transfer.
- Stop and transfer. Anything about whether someone qualifies, what it costs, or what is covered goes straight to a licensed human.
Most teams build the last step as a failure case. It is not a failure, it is the agent working correctly. Designing the handoff as a real path rather than a fallback is most of the job.
04
How I test it
The refusal path is the product, so it gets tested hardest.
- Write the hard questions first. “So will my insulin be covered?” asked 6 different ways, the polite ones and the desperate ones.
- Test where the transfer lands. A handoff that rings into nothing is worse than no agent at all, and you only catch it by calling the other end, not by checking that the agent tried.
- Re-test the required wording after every prompt change. An edit that improves the greeting can stop the legally required line firing 3 turns later. That is a compliance problem, not a bug.
- Watch the delay. A correct answer that arrives 2 seconds late loses the call anyway.
If any of this is the shape of your problem, I’d like to hear about it.
Eastern time, New Jersey, US
Client names and internal details omitted where I am under confidentiality.