Forward-Deployed Engineering: How We Close Insurance's Last Mile

A voice agent on a live call gets one shot. There's no retry, no edit button, and an actual customer waiting on the other end. That's the gap most AI vendors never close. They can ship a model that sounds great in a demo, but every carrier and agency runs its own CRM, policy data, IVR menus, compliance rules and call flows. None of that shows up in a sales deck. It shows up the first week an agent goes live on real calls.

We close that gap with forward-deployed engineering: an engineer and a project manager embedded inside each carrier's or agency's actual environment, owning the deployment outcome end to end, instead of shipping software over the wall and hoping it survives contact with production.

The last mile is the hard part

The hard part is never the model. It's the last mile: the business and telephony edge cases specific to one carrier's stack, and then writing the outcome back into that carrier's own systems. A model that handles a benchmark conversation well still has to know that this carrier routes endorsements through Vertafore, that this agency's IVR drops calls after four menu options, and that this compliance team requires a specific disclosure before any payment conversation. None of that transfers from one deployment to the next without someone who has actually worked inside the account.

This is the 5% / 95% frame we build around: 5% of the value is the talking. 95% is the orchestration, navigating Guidewire, searching policies, filing claims, following compliance rules. Having smooth conversation doesn't make an agent useful. Resolving the request end to end does.

Voice raises the bar past chat or email for one reason: it's real time, with a customer on the line, and there's no retry. A hallucination, a drift in a long conversation, a slot-filling error that misreads a policy number, all of it shows up live, in front of the person it's supposed to help. You can't QA your way around a real caller. Our hallucination rate is below 1% our instruction-following accuracy is at 77% across our agents. Both numbers are strong. Neither is finished, and we'd rather say that plainly than round up. That remaining gap is exactly why embedding matters: someone has to be watching when a live call surfaces what the test suite didn't.

We embed instead of ship

We can put an engineer on the account and have them be useful in week one because the team already knows the workflows: FNOL and claims, underwriting and quoting, lead qualification. They know the carrier systems: Guidewire, Duck Creek, Snapsheet, Applied Epic, AMS360, Vertafore. They know the compliance reality each line of business carries. A generic AI vendor learns all of that at the customer’s expense, one support ticket at a time. Insurance-native domain depth is what makes the last mile tractable instead of an open-ended discovery project that never quite finishes.

How forward deployment works

1. At least one Agent Engineer and one Project Manager are embedded into the customer's real environment. They work against the actual data quirks and compliance constraints of that account, not a sandbox version of it, and they own the deployment outcome, not just the handoff.
2. Every deployment clears the same quality gate before it goes live. It doesn't matter which engineer is embedded or which carrier they're embedded with. A customer's tenth use case gets held to the same bar as their first.
3. A silent failure on a customer's live calls is the failure that matters most, so we build to catch it early and small rather than late and large.
4. Engineers build on one shared platform instead of starting over for each customer. Reusable agent components, common data models, and observability are already built in. That infrastructure is what lets a small embedded team hold the same bar across many customers, instead of re-deriving the basics on every new account.
5. Teams are organized by use case, not by account. Engineers and product co-design the solution for claims, service or sales, so expertise compounds across customers in that use case instead of resetting with every new logo.

Forward deployment in production

1. Forward-deployed voice agents are in production across several carriers and agencies, handling thousands of calls a day. This isn't a pilot running in parallel with the call center. It's production volume.
2. The model covers the full insurance value chain: acquire, sell, service. Lead qualification, quoting, policyholder services and claims all run end to end, not as isolated proofs of concept sitting next to each other. We can assist across the pipeline, not just the easiest piece of it.
3. Call center offload is real, not aspirational. We've resolved a meaningful share of incoming call volume for our customers, so human reps spend their time on the calls that actually need a person, not the ones that don't.
4. Voice is one channel of several. SMS, email and an outbound dialer run alongside it, so the agent meets the customer wherever the workflow already lives, not just wherever it's easiest for us to build.
5. A new deployment can go live within weeks of finishing discovery, operating exactly to the rules defined with that customer. Allied Trust, one of our carrier customers, went live in six weeks after being stuck with another vendor for two years. That's the kind of timeline forward deployment makes possible once discovery is done.

For an agency, the offload in item three means the CSR who used to spend the first twenty minutes of a shift on routine status calls gets that time back for the renewal conversation that actually needed a person. For a carrier, it means that when a catastrophe event drives call volume to forty times normal, the AI agent absorbs the surge, so the policyholder calling about a flooded basement gets through on the first try instead of the fortieth.

Where the headroom is

Our embedding strategy acknowledges that no amount of pre-launch testing catches everything a real caller will do. Long-form regulated conversations drift in ways a script can't anticipate. A policy number gets mumbled. A caller answers a different question than the one asked. A compliance edge case shows up in month four that never came up in discovery. That's the actual reason the ship-watch-fix loop exists, and the actual reason we ramp new deployments gradually instead of flipping a switch on full volume. The real version of "production-ready" is "ready, with the system watching and a human pulled in the moment it flags something." We'd rather say that than promise an agent that never needs one.

We think forward deployment is what separates a model that performs well on a benchmark from one that holds up on a live call with a real customer on the line. We'd rather embed an engineer who owns the outcome than ship a model and leave the hardest part to someone else. If you want to talk through how this works for your CRM, your IVR, and your compliance rules specifically, our team is the right place to start that conversation.