Most agentic AI projects in insurance fail at integration, not at inference. The model can classify a claim, summarize a submission, or flag fraud with acceptable accuracy in a demo. Then someone wires it to a Guidewire or Duck Creek instance through screen-scraping or a synchronous API wrapper, and the pilot dies under production load, race conditions, and audit gaps that legal will not sign off on.
The fix is not a better model. It is an event-mediated interface where the agent reads from a materialized view of policy and claims data, writes decisions to a proposal queue, and the core system remains the authoritative writer. The agent proposes. Humans or deterministic rules approve. The core system of record never becomes your agent's scratchpad.
This is an architecture problem that insurance teams keep solving as a prompt engineering problem. Below is the pattern that actually reaches production, why direct integration keeps failing, and how to sequence a migration that does not require replacing your policy admin system.
The Screen-Scraping Trap That Kills 6-Figure Pilots
The pattern shows up in almost every stalled insurance AI pilot I review. A team builds an agent to triage first-notice-of-loss claims. To get data, they point it at the claims management UI through robotic process automation, or they wrap a few brittle SOAP endpoints the core vendor never intended for high-frequency reads. The agent reads a claim screen, reasons, then writes a status change back through the same path.
It works for the demo. It works for the first fifty claims. Then volume climbs and the whole thing falls apart. RPA bots break the moment a vendor pushes a UI change. Synchronous reads against a policy administration system contend with the same connection pool your adjusters and batch jobs use. You get timeouts, partial writes, and race conditions where the agent reads a claim, an adjuster edits it, and the agent writes back stale state.
The deeper mistake is conceptual. The team is treating the agent as a UI automation layer, a faster human clicking through screens. An agent is not a macro. It is a decision service that needs structured input, produces structured output, and must be observable and reversible. When you bolt it onto the presentation layer of a legacy core, you inherit every fragility of that UI and none of the guarantees a decision service requires.
| Concern | Bolt-On (RPA / sync API) | Event-Mediated | Why It Matters |
|---|---|---|---|
| Read latency | Contends with core connection pool | Serves from read model, isolated | Agent load never degrades adjuster experience |
| Write safety | Direct writes, race conditions | Proposal queue, controlled apply | No stale-state overwrites of human edits |
| Auditability | Decision and evidence often separate | Full reasoning trace stored per proposal | Regulators can inspect any automated decision |
| Rollback | Manual, error-prone | Reversible write path by design | Bad decisions reverse without data forensics |
| Vendor upgrade risk | UI change breaks the agent | Event contract insulates the agent | Core upgrades do not require agent rework |
Why the Core System Should Never Be Your Agent's Database
Legacy core systems are systems of record. They are built for transactional integrity, regulatory retention, and controlled writes, not for the high-frequency, exploratory read patterns that agent reasoning loops generate. When an agent gathers context, it may issue dozens of queries to assemble a complete picture of a claim, a policy, prior claims history, and related parties. Firing all of that at your PAS is a fast way to degrade the system every human in the company depends on.
The alternative is an event-driven read model. Use change data capture to stream inserts and updates out of the core into a materialized view shaped for the agent's questions. Debezium against the core database, or the vendor's own event stream where one exists, feeds a projection that holds a normalized claims and policy view. The agent queries this view. The core never feels the load.
This separation also fixes the write problem. The agent does not write to the core at all. It writes a decision proposal to a queue. A controlled apply process, gated by either deterministic rules or human approval, is the only thing that writes back to the system of record. This is the same pattern we apply in our approach to agentic AI systems: the agent is a proposer, never the final authority on state.
Three properties fall out of this design that direct integration cannot offer:
- Isolation: Agent read load lives in the read model, so a runaway reasoning loop never takes down claims intake for your adjusters.
- Auditability: Every proposal carries its full evidence and reasoning trace, stored alongside the decision, so you can reconstruct why the agent proposed what it did months later.
- Reversibility: Because the core applies changes through one controlled path, every automated change has a defined reverse operation instead of a manual data-fix ticket.
Building the Agent-to-Core Interface Layer
The interface layer has three moving parts: an inbound event consumer, the agent decision service, and an outbound proposal queue. The agent consumes normalized domain events (a new FNOL, a coverage change, a third-party data enrichment result), reasons over the read model, and emits a structured proposal. The core system, or a rules engine in front of it, is the only authoritative writer.
A claims triage agent proposal should look like a first-class, inspectable object, not a free-text blob. Here is the shape we use:
{
"proposal_id": "prop_9f2a1c",
"correlation_id": "claim_2026_00184123",
"agent_version": "claims-triage-v3.2",
"action": "route_to_fast_track",
"confidence": 0.88,
"reasoning_trace": [
"Coverage verified active on loss date 2026-02-11",
"Estimated severity USD 3,400, below fast-track ceiling of 7,500",
"No prior claims on policy in trailing 24 months",
"No fraud indicators matched in rules pass"
],
"evidence_refs": [
{"type": "policy", "id": "POL-55231", "field": "coverage_status"},
{"type": "loss_estimate", "source": "photo_estimator_v2"},
{"type": "claims_history", "window_months": 24}
],
"requires_human_review": false,
"reversible": true
}Two engineering disciplines make this safe. First, idempotency: the proposal carries a correlation_id tied to the source event so the same claim event never produces duplicate write-backs, even if the consumer redelivers. Second, every action needs a reversible write path. If the agent proposes moving a claim to fast-track and that turns out wrong, the apply layer must know how to undo it cleanly. Design the reverse operation at the same time you design the forward one.
Correlation IDs also give you the audit spine regulators expect. When an examiner asks why a specific claim was routed automatically, you trace the correlation_id from the source event through the proposal, the reasoning trace, the approval decision, and the final core write. Nothing is inferred after the fact.
Exception Routing: The Handoff That Makes or Breaks Adjuster Trust
An agent that silently auto-decides everything is a liability. The agents that earn adjuster trust are the ones that know when to escalate. Low-confidence classifications and high-severity claims should route to a human every time, and the confidence threshold should not be a single global number. It varies by line of business and by claim severity tier.
The escalation itself is where most designs fail. When the agent hands a claim to an adjuster, it must pass the full reasoning context: the evidence it gathered, the factors it weighed, the confidence it assigned, and why it declined to decide. If the adjuster receives only "escalated for review," they redo the entire investigation the agent already performed, and you have added work instead of removing it.
Set thresholds deliberately. A commercial property claim above a severity ceiling always goes to a human regardless of confidence. A low-value auto glass claim can auto-route to fast-track at 0.85 confidence. The point is that the threshold encodes your risk appetite per workflow, and it should be a reviewable configuration value, not a constant buried in a prompt. When you tune it, you should be able to see the effect on escalation rate and reversal rate within days.
The Compliance Traps Unique to State-Regulated Insurance
Insurance is regulated state by state, which means a single national agent policy is a regulatory liability rather than an efficiency. Claims handling timelines, adverse action notice requirements, and rate filing rules differ across jurisdictions. An agent applying one uniform ruleset will violate the rules of some state the moment it touches a claim there.
The National Association of Insurance Commissioners issued a model bulletin on the use of AI systems by insurers, and a majority of states have adopted or adapted it [5]. It sets expectations around governance, testing, documentation, and the ability to explain automated decisions. Your agent architecture has to produce the documentation that bulletin anticipates, which is exactly why the reasoning-trace-per-proposal pattern matters. If you cannot show how an automated decision was reached, you cannot demonstrate compliance.
Map compliance requirements to each workflow explicitly. The obligations differ sharply between triaging a claim, summarizing an underwriting submission, issuing an adverse action, and touching a rate decision.
| Workflow | Primary Regulatory Concern | Agent Boundary | Documentation Required |
|---|---|---|---|
| Claims triage | State handling timelines | May route, may not deny | Reasoning trace, timestamp per state clock |
| Underwriting summary | Fair treatment, data provenance | Summarize only, no bind | Source-to-factor mapping per risk element |
| Adverse action | Notice content and timing rules | Must not auto-issue | Reason codes, human sign-off, delivery proof |
| Rate decision | Filed-rate compliance | Read-only, no rate setting | Full lineage to filed rating factors |
The safe default across every one of these rows: the agent gathers, reasons, and proposes, but a human or a filed, tested rule executes anything that carries legal consequence. Adverse actions and rate decisions in particular should never be autonomous agent outputs.
Underwriting Augmentation Without Replacing the Underwriter
Underwriting is where teams are tempted to over-automate and where restraint pays off most. The agent's job is to gather evidence and summarize risk, not to bind coverage. Treat it as the fastest analyst on the desk, one that assembles a complete picture before a human ever opens the file.
Third-party data enrichment flows through the same event layer as everything else. A motor vehicle record pull, a property inspection report, or a medical summary arrives as an enrichment event, lands in the read model, and becomes another input the agent can reason over. Routing enrichment through the event pipeline instead of letting the agent call vendors directly keeps costs, retries, and data lineage under control. This mirrors the event-driven modernization patterns we apply to legacy core systems, where every external data source becomes a governed stream rather than an ad hoc call.
Explainability is non-negotiable in underwriting. Every risk factor the agent surfaces must map to a source the underwriter can click into and inspect. If the agent flags elevated fire risk, the underwriter needs to see the property report field and vendor that produced it, not a confident sentence with no provenance.
Consider a commercial general liability submission. The agent consumes the ACORD application event, pulls loss run enrichment, cross-references the classification code against the filed rating plan, and produces a structured summary: prior losses over the trailing five years, exposure basis, missing information the underwriter should request, and a risk narrative where every claim links to its evidence reference. The underwriter opens a file that is already organized and sourced, and spends their time judging risk instead of chasing documents. The bind decision stays entirely human.
A Migration Path That Does Not Require Ripping Out Your Core
You do not need to replace your policy admin system to deploy agents against it. You sequence the work so each phase delivers value and reduces risk before the next. The order is deliberate: data plumbing first, read-only reasoning second, controlled write-back last.
- 1Build the CDC event pipeline. Stand up change data capture from the core into a materialized read model. This phase alone improves reporting and analytics and touches nothing the agent depends on yet.
- 2Deploy a read-only agent. Let it consume events, reason, and produce proposals that go nowhere but a review dashboard. Measure quality against what adjusters and underwriters would have decided. No production write path exists yet.
- 3Enable controlled write-back. Only after proposal quality is proven, add the apply layer with human or rules approval and reversible operations. Start with the lowest-severity, highest-volume workflow.
Before any agent touches a legacy core, confirm these prerequisites are in place.
| Prerequisite | Why It Blocks Deployment | Owner |
|---|---|---|
| CDC pipeline live | No read model means agent hits the core directly | Data engineering |
| Correlation ID scheme | No audit spine without end-to-end IDs | Platform architecture |
| Reversible write design | Cannot safely apply proposals without undo | Core integration team |
| State-specific rule config | National ruleset violates jurisdiction rules | Compliance and legal |
| Escalation UI with context | Handoffs without evidence create rework | Adjuster experience |
Track three metrics from week one: escalation rate (share of claims the agent routes to humans), decision reversal rate (proposals humans undo after apply), and adjuster override rate (how often humans disagree with agent proposals in review). Rising reversal or override rates tell you your thresholds are too aggressive well before anything reaches a customer.
Frequently Asked Questions
Should the AI agent write directly to Guidewire or Duck Creek? No. The core stays the authoritative writer. The agent writes proposals to a queue, and a controlled apply layer gated by rules or human approval performs the actual write-back. Direct agent writes create race conditions and audit gaps.
How do we handle 50 different state regulations? Encode jurisdiction-specific rules as reviewable configuration, not a single prompt. Map each workflow (triage, underwriting, adverse action, rate) to its state-specific requirements, and keep anything with legal consequence under human or filed-rule control.
What is the fastest safe first workflow to automate? High-volume, low-severity claims triage. It generates enough data to validate the pipeline quickly and carries limited downside if a proposal is wrong, especially with reversible write-back in place.
Do we need to replace our legacy core first? No. The phased CDC-then-read-only-then-write-back path runs entirely alongside your existing core.
Where to Start This Week
The screen-scraping pilot that stalls under load is not a model problem. It is a data-flow problem, and you fix it by refusing to let the agent read from or write to the core synchronously.
In the next 30 minutes, sketch your CDC event pipeline: which core tables or vendor events feed a read model, and what the normalized claims and policy view needs to contain for your first workflow. That single diagram tells you whether your architecture treats the agent as a decision service or as a screen-scraping macro.
This week, start tracking decision reversal rate on any agent output you already have, even if it only lands in a review dashboard. It is the earliest signal of whether your thresholds match your risk appetite, and it is the metric that keeps a pilot from quietly becoming a liability.
References
[1] Cloudera, "The Future of Enterprise AI Agents," 2025. https://www.cloudera.com/about/news-and-blogs/press-releases/2025-05-07-cloudera-survey-finds-96-of-enterprises-plan-to-expand-use-of-ai-agents.html
[2] Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027," 2025. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
[3] Asana, "The Anatomy of Work Global Index," 2025. https://asana.com/resources/anatomy-of-work
[4] McKinsey & Company, "The economic potential of generative AI: The next productivity frontier," 2023. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier
[5] National Association of Insurance Commissioners, "Model Bulletin on the Use of Artificial Intelligence Systems by Insurers," 2024. https://content.naic.org/sites/default/files/inline-files/2023-12-4%20Model%20Bulletin_Adopted_0.pdf