Your SOP Is Not the Spec

Most insurance AI is built from the process document. That's why so much of it breaks in production.

Ask a carrier for its FNOL workflow and you'll get an SOP. Ask the adjuster who has worked that queue for eight years and you'll get the real workflow. The two overlap. They are not the same.

That gap is where insurance AI fails. Not in the demo. Not in UAT. In the second week of production, when a caller says something the document never anticipated.

Here is our position. An SOP is a summary of how an operation runs, and every summary leaves things out. An AI agent built from that summary inherits every gap. The only reliable way to close those gaps is to put engineers inside the operation, sitting with the people who do the work, before and after go-live. That is why Liberate deploys forward.

The SOP describes the happy path

A process document captures the required fields, the sequence of steps, the systems and the escalation criteria. It rarely captures the exceptions experienced staff handle without thinking:

• "If the policy was migrated from the old system, we look here instead."
• "If that field is blank, don't assume there's no coverage. Check this screen."
• "We do steps four and five in reverse so we don't enter the same information twice."
• "That rule changed last year, but this book of business still follows the old process."
• "If the claimant says this particular thing, I stop and get a supervisor."

None of these are errors in the SOP. They are judgment a team builds over thousands of interactions. A new hire learns them by sitting next to a colleague for six months. An AI agent doesn't get six months. It needs those rules the day it goes live.

Why most AI gets built from the document anyway

Because it's easier to implement. A platform that ingests requirements and configures a workflow needs fewer people per deployment. The buyer sees a clean demo on the documented path. Everyone signs.

The cost shows up later. The agent handles the scripted call well, then stalls on the migrated policy, the blank field, the legacy book still on the old rules. Each miss becomes a transfer, a complaint or a bad write-back into the System of Record. Confidence erodes and the project stalls.

Forward deployed engineering is the harder path. It takes more people and more time inside the customer's operation than configuring from a spec. We do it anyway, because the alternative quietly moves that cost onto the carrier.

"FNOL" is not one workflow

Two carriers can describe FNOL in identical language and run it differently. Different core systems. Different books of business. Different authority limits. Different rules for when a human takes over. Policy servicing is no different.

This is how Liberate splits the work. We ship a library of proven use cases: FNOL, claim status, billing and payments, policy changes, Rate/Quote/Bind. That library covers the structure most carriers share, so nobody starts from a blank page. Forward-deployed engineers capture the parts that work for your operation. The library gets you live fast. The forward-deployed customization keeps the agent working once real calls arrive.

What forward-deployed work looks like

Liberate's agent engineers and product managers work inside the customer's operation. In practice, they:

• Sit with the people doing the work. Listen to calls, watch screens, and ask where staff hesitate, improvise or skip a documented step.
• Write the unwritten rules down as scenarios before agent logic gets built, so the exceptions are part of the design, not a patch after launch.
• Turn each scenario into something the agent can act on: a workflow branch, an integration rule, or an escalation path in the Supervisor Layer.
• Stay through go-live and tune against real traffic, not test scripts.

The output isn't a better requirements document. It's an agent that already knows the exceptions.

One scenario we occasionally encounter involves caller identification. Based on the SOP, an insurer might appear to be a good candidate for phone lookup, which lets the agent identify a caller by the phone number associated with the customer record. 

But there’s a catch: if the insurer’s operational practice is to populate that policyholder’s phone number field with the insurance agent’s phone number, it won’t work. An agent built around the standard workflow would follow the process correctly and still fail at lookup. Understanding how the customer maintains its data exposes the exception before it becomes a production problem.

Test the exceptions, not the requirements

If UAT only confirms the agent follows the documented workflow, you've proven it works under documented conditions. That's the easy part.

Good UAT uses the cases staff already know cause trouble. The odd policy number. The blank field. The conflicting information. The call where a veteran would say, "I'd get someone involved here." Forward-deployed engineers bring those cases into testing because they collected them on the floor.

The goal isn't proving the agent never fails. It's knowing exactly what it does when it isn't sure, and confirming it hands off to a human with full context when it should.

The deeper AI goes, the more this matters

Traditional software could leave the exceptions to people indefinitely. Agentic AI can't, because we're asking it to execute the work, not just store it. Every step an agent takes deeper into the workflow is a step into the unwritten rules.

So when you evaluate an AI vendor, look past the demo and ask one question: who on your team will sit with my people, and for how long? If the answer starts with "send us your SOPs," you already know how the deployment will go.

Forward-deployed engineering is one part of how Liberate takes AI agents from demo to production in weeks. See the full process in our white paper, From Demo to Production in Weeks.