AI Agents for InsuranceClaims Adjusting in 2026

Every conversation about AI agents in claims eventually arrives at the same wall, and it is never the wall people expect. It is not that the model cannot read a first notice of loss, summarise an adjuster's file, spot a subrogation opportunity or draft a coverage analysis. Current models do all of that competently. The wall is that a P&C claim lives inside a system of record your organisation licenses but does not control, and the ability to write into that system is a privilege granted by a contract somebody else drafted.

In P&C claims the situation is unusual, and worse than in most industries, because there are two systems of record and two write paths, owned by two different vendors on two different contracts.

The first is the claims core. The names you encounter at the enterprise tier are Guidewire ClaimCenter, Duck Creek Claims and Sapiens IDITSuite; in the mid-market and digital tier you encounter Majesco, Insurity, EIS, OneShield, Snapsheet, Origami and ICE. That tiering is consistent across the sources we checked and is safe to treat as the landscape. What is not safe is any statement about how much of the market each holds — see the limitations section, where we explain why we refuse every 2026 claims-core market-share percentage in circulation.

The second is the estimate. On property claims the estimate typically does not live in the claims core at all — it lives in Verisk's estimating environment, principally Xactimate and XactAnalysis. That is a separate vendor, a separate agreement, and a separate integration project. Partners in that ecosystem integrate by pushing data intoVerisk's system rather than by owning the estimate: roof-measurement providers, 3D-model capture providers, building-code data providers and restoration-workflow platforms all feed the estimating environment. The posture is worth internalising, because it tells you what your agent can realistically do there. It can supply inputs. It does not hold the pen.

Here is the trap that follows. Because Guidewire, Verisk and their peers do not publish partner terms, a would-be integrator cannot price the integration before entering a sales conversation. That is the actual story, and it is more useful than the story people usually tell. We looked specifically for documented litigation, regulatory complaints or published partner-terms disputes establishing that a named P&C core vendor blocks competitors, and we found none. We are not going to assert it. The verifiable statement is weaker and still decisive for your planning: their partner terms and fees are not published, so your integration cost is unknowable at business-case time unless you force it into the open.

The cluster pillar defines a five-rung ladder for integrating agents with closed systems of record: documented public API, certified partner program, EDI or batch file, screen scraping or RPA, and no path at all. You are standing on exactly one rung per system, whatever your architecture diagram says. In claims, most carriers discover they are on different rungs for different systems in the same workflow — Rung 1 or 2 into the core, Rung 2 into the estimating platform, and Rung 4 into whatever legacy sub-system holds salvage, medical bill review or a state-specific form.

Two notes on the lower rungs, because they are where claims organisations get hurt.

On EDI and batch: the standards are licensed rather than free. X12 publishes its license types — commercial, internal, developer, a premium subscription tier, a code-list update subscription and a free registered-user account for non-premium resources — and access to the EDI Standard itself requires a paid tier. The prices are not displayed. Write “licensed, priced on application,” never a number. The compensating virtue is real, though: for an agent, a batch interface is often the safest write path available, because the file is a natural reconciliation checkpoint. Real-time API writes give you no such checkpoint for free; you have to build it.

On screen scraping and RPA: it deserves an honest treatment rather than a dismissal, because it is frequently the only rung on offer and a great deal of claims automation already runs on it. Technically it works almost everywhere. Contractually it is exposed almost everywhere. And structurally it is fragile, because you are consuming a presentation layer the vendor may change without notice or versioning.

Van Buren v. United States is the other citation everyone reaches for, and it too is usually overstated. The Supreme Court held that an individual “exceeds authorized access” when he accesses a computer with authorization but then obtains information located in particular areas of the computer — such as files, folders, or databases — that are off limits to him. But the Court expressly reserved the question that matters for terms-of-service violations, writing that “For present purposes, we need not address whether this inquiry turns only on technological (or ‘code-based’) limitations on access, or instead also looks to limits contained in contracts or policies.” Anyone who tells you Van Buren settled whether a terms-of-service breach can create CFAA liability is overstating a case that left it open.

The practical translation for a claims executive: do not treat “our RPA bot already does this” as evidence that an agent may do it. Read the agreement you are bound by, keep scraped surfaces low-volume and low-stakes, and understand that when the agent improvises around a changed screen — which is exactly what an agent does and a scripted bot does not — it may write something wrong rather than failing loudly. That is a new failure mode, not an inherited one.

The useful way to plan an agent programme in claims is to walk the lifecycle and ask three questions at each stage: what does the statute demand here, what would the agent actually do, and what write path exists. The table below is analysis grounded in the verified statutory text discussed in the next section — it is our reasoning about where an agent belongs, not a regulatory pronouncement.

Read the table top to bottom and a shape emerges that should govern your roadmap. Exposure rises monotonically as you move toward the money.Intake and acknowledgment are the stages where automation is not merely tolerated but rewarded by the statute. Triage and assignment are governed by a reasonableness standard applied to your internal rules. Investigation, coverage and settlement are where a human adjuster's judgement is the product being regulated.

That is why we recommend, almost universally, that the first agent a carrier or TPA ships is FNOL intake plus acknowledgment plus triage recommendation, and the second is subrogation identification. The first is the lowest-exposure, highest-frequency workflow in the building. The second is analysis on a closed record with a task-level write, which makes it unusually safe for the value it returns. Neither requires the agent to hold a credential that can move money or change a claim's status.

The real gate on agent autonomy in claims is not the API. It is the NAIC Unfair Claims Settlement Practices Act, Model #900, adopted as a free-standing act in June 1990 and enacted in substantially similar form by most states. A commonly repeated count puts that at 44 states; we did not extract the NAIC state-adoption page and so we write “most states” rather than a number. Check your own jurisdictions — your compliance function almost certainly already has the list.

Three structural facts about the model act are consistently misstated in AI-and-insurance commentary, and each one changes an architecture decision.

Two: a single bad act is not a violation. Section 3 provides that it is an improper claims practice to commit a section 4 act only if “(A) It is committed flagrantly and in conscious disregard of this Act or any rules promulgated hereunder; or (B) It has been committed with such frequency to indicate a general business practice to engage in that type of conduct.” That is the full sentence, and the qualifier in (B) is where the element actually lives.

Now the argument, offered as an argument. We could not locate any case or regulatory action applying section 3(B) to an automated claims system — none exists that we could find, and we are not going to imply that automation satisfies the element as a matter of construction. What can fairly be said to a claims executive is this: a defective rule applied at scale is far easier to characterise as a general business practice than a single adjuster's error is. Automation does not create the element; it makes frequency trivial to demonstrate. If your agent applies a subtly wrong reading of a policy exclusion to four thousand claims in a quarter, the evidentiary work of showing a pattern has already been done for the examiner, by your own logs. Treat that as a risk to design against, not as settled law to panic about.

Three: the model act creates no private right of action. Section 1 provides that “Nothing herein shall be construed to create or imply a private cause of action for violation of this Act”, with a drafting note observing that the act “is inherently inconsistent with a private cause of action.” Enforcement runs through the commissioner: market conduct examination, statement of charges under section 5, and cease-and-desist and penalty orders under sections 6 and 7. But states vary.Some states' versions permit private suits or feed bad-faith claims, and we did not verify which. Do not generalise from the model to your own states without checking.

The prohibited acts in section 4 that an autonomous agent is most likely to trip are worth quoting exactly, because paraphrase softens them:

• §4(B): “Failing to acknowledge with reasonable promptness pertinent communications with respect to claims arising under its policies” — the one provision that runs in automation’s favour.
• §4(C): “Failing to adopt and implement reasonable standards for the prompt investigation and settlement of claims arising under its policies” — your triage and routing rules are those standards.
• §4(D): “Not attempting in good faith to effectuate prompt, fair and equitable settlement of claims submitted in which liability has become reasonably clear.”
• §4(F): “Refusing to pay claims without conducting a reasonable investigation” — an agent that closes files without one manufactures a violation at scale.
• §4(G): “Failing to affirm or deny coverage of claims within a reasonable time after having completed its investigation related to such claim or claims.”
• §4(L): “Failing in the case of claims denials or offers of compromise settlement to promptly provide a reasonable and accurate explanation of the basis for such actions” — the provision that decides how much autonomy an agent can ever have.

Also in scope and worth reading before you scope a project: §4(A) on knowingly misrepresenting facts or policy provisions, §4(E) on compelling insureds to litigate by offering substantially less than they ultimately recover, §4(K) on duplicative proof-of-loss demands, and §4(N) on repair workmanship standards. Section 4(J) is the one that bites on the payment write: payments must indicate the coverage under which each payment is made.

The intuitive thesis — an agent cannot adjudicate because only a licensed human adjuster may — is weaker than most writers assume, and it is also not uniformly wrong. It depends entirely on who is doing the adjusting, and getting this split right is the difference between a defensible architecture and a compliance argument that collapses on contact with your general counsel.

The NAIC State Licensing Handbook states it directly: “40 states license public adjusters, 33 states license independent adjuster licenses, and only 15 states require company adjusters to be licensed.” It also states, and the qualifier is load-bearing: “Public adjusters represent the insured, while independent and staff adjusters represent the insurer. More than 30 states require licensure of one or more of these types of adjusters.”

What that means for two very different deployments:

• A carrier running agents behind its own staff adjusters: Licensure binds in only 15 states. Most carrier staff adjusters are unlicensed in most states, so licensure is a weak constraint on this posture. Do not build your compliance story on it — build it on §3(B), §4(L), the NAIC AI bulletin's insurer-accountability regime, and market conduct examination, all of which bind everywhere.
• An independent adjusting firm or TPA running agents: 33 states license independent adjusters, and Model #900 §2(C) folds adjusters and third party administrators into the definition of insurer. This deployment sits in the 33-state bucket, not the 15-state one. Here licensure is a real, operative constraint, and the carrier-versus-vendor distinction should appear explicitly in your architecture documentation.

The handbook adds that approximately 18 states have continuing-education requirements for their resident adjusters, and names the relevant NAIC instruments: the Public Adjuster Licensing Model Act (#228), the Independent Adjuster Licensing Guideline (#1224), and the Independent Adjuster Reciprocity Best Practices Guidelines. For multi-state licensing mechanics, NIPR — operated by the NAIC — is a centralised electronic filing portal reported as accepted by 47 states and the District of Columbia for nonresident licensing.

One refusal, because it circulates and it is wrong: we encountered a claim that California and Florida have no adjuster licensing requirement. It is self-contradictory within its own source, which in the same passage describes a California-specific examination with no reciprocity. We could not verify anything about either state's adjuster licensing and we therefore write nothing about it. If your programme touches either state, that is a question for licensed counsel, not for an article.

The NAIC's Model Bulletin: Use of Artificial Intelligence Systems by Insurers was adopted December 4, 2023, and it is the instrument most often invoked in vendor decks as the reason your AI programme needs governance. It is a real instrument and the invocation is broadly fair. The adoption picture, however, is routinely misdescribed, and the misdescription runs in the direction of urgency.

Date-stamp the count, always.An undated number in an evergreen document silently becomes wrong the moment a twenty-sixth jurisdiction adopts. Write it as “as of the NAIC's August 6, 2026 map,” and re-check the PDF before you rely on it.

There is a second, more interesting fact hiding in the same document. The NAIC's April 1, 2026 map carried an identical adopted list. Zero jurisdictions were added between April 1 and August 6, 2026. Adoption is slow and roughly flat — which is a defensible, checkable corrective to the momentum framing that accompanies most AI-governance sales conversations. Your regulatory calendar is not on fire. It is, however, permanently fragmented, which is a harder problem than urgency.

The fragmentation shows up in a separate bucket on the same map, which must not be merged with adoption. The NAIC tracks four jurisdictions under insurance-specific regulation and guidance — instruments that are not Model Bulletin adoptions:

Not adopted does not mean unregulated. Four of the largest insurance markets in the United States regulate AI in insurance through their own instruments. Any vendor or consultant describing a single national compliance posture has not read the map.

Colorado deserves a specific note because it is the state with the most quantitative teeth, and because it is frequently over-claimed. Its regulation, 3 CCR 702-10, requires insurers using external consumer data and information sources — ECDIS — and algorithms or predictive models that use ECDIS to establish a risk-based governance and risk-management framework to assess unfair discrimination. Reporting obligations attached to private passenger auto insurers using ECDIS include a narrative progress report due December 1, 2025 and a compliance report due July 1, 2026 and annually thereafter; we attribute those dates to Colorado's ECDIS regulation as reported rather than to extracted rule text.

The relevance boundary matters. Colorado's framework addresses unfair discrimination in the use of ECDIS and models, which reaches underwriting and pricing most directly. We do not claim it squarely governs claims adjudication agents, because we could not verify that with a primary citation. We also could not verify the scope or final status of Colorado's separate quantitative testing regulation as of August 2026 — drafts reference life insurers with expansion discussed — so we state neither which lines are covered nor that it is final.

Every claims agent programme needs this table written down, agreed with compliance, and enforced in code rather than in policy. The distinction that matters is not “is a human involved” — a human is always involved somewhere — but whether the agent is technically capable of taking the action without one. A control that depends on the agent choosing to ask is not a control.

Two practical failure modes to watch in the middle rows. The first is approval collapse: when a reviewer is asked to approve four hundred agent proposals a day, approval latency falls toward zero and the gate becomes ceremonial. Detect it by monitoring time-to-decision and disagreement rate; when disagreement approaches zero, either the agent is genuinely excellent or the human has stopped reading, and you cannot tell which from the outcome data alone. Fix it by reducing volume through the gate, batching by exception, or raising the agent's confidence threshold — never by removing the gate.

The second is drafting that reads as deciding. If the agent produces a denial rationale so complete that the reviewer's only realistic action is to click send, you have built autonomous denial with extra steps, and §4(L) will not care about the interface. The countermeasure is to make the draft explicitly incomplete in the places where judgement lives: present the policy language and the record, present the tension, and require the human to write the conclusion. This is less satisfying as a demo and considerably more defensible in a market conduct examination.

The single most valuable thing a claims organisation can do in the first month of an agent programme is to establish, in writing, what its systems of record actually permit. Not what the sales engineer demonstrated. Not what the marketplace listing implies. What the contract permits, at which endpoint, at what price, for how long.

Assume until proven otherwise that your certified or documented access is read-heavy and write-thin. That is the norm across systems of record, not the exception, and it is the specific reason so many agent pilots look brilliant and ship nothing. A documented API with no usable write surface is a Rung 5 wearing a Rung 1 badge.

For property lines, run the same nine questions against the estimating platform, and add a tenth: which direction does data flow, and who owns the resulting artefact? In that ecosystem the answer is consistent — partners push data in, and the estimating vendor retains the estimate. Design accordingly: your agent supplies measurements, scope items and code data, and an estimator produces the estimate.

A second useful analogue comes from healthcare, where the two-tier pattern is stated openly. Epic publishes industry-standard FHIR APIs on its open developer site, and separately operates a paid vendor enrollment tier. Its support page states that “Enrolled vendors also can access an expanded API specifications catalog to enable their data exchange where industry-standard APIs may not yet exist or fully meet the needs of a specific use case.” Epic's enrollment fees are not public. Strip the industry specifics and the structure is the one you should expect in claims: the free or standards-mandated tier gets you read access; the commercial tier gets you the write paths and the long tail.

Integrations do not fail dramatically. They fail on a Tuesday, quietly, in a way that produces plausible wrong output for eleven days before anyone notices. Below are the failure modes specific to claims, each with the detection signal you should build before launch and the rollback you should rehearse before you need it.

One structural observation that applies across the whole table. Vendor concentration is your real exposure, and it is doubled in claims.The estimating write path and the claims core belong to different companies on different contracts and different release cadences. Either can change a schema, reprice access, or ship your workflow natively, and neither has any obligation to coordinate with the other. A single integration dashboard that shows one green light for “integrations” is actively misleading; instrument them separately and alert separately.

The second observation is about market conduct. Everything your agent does produces a log, and those logs become examination evidence.Sections 5 through 7 of Model #900 give commissioners statement-of-charges and cease-and-desist authority, and an examiner asking how a class of claims was handled will be handed your agent's decision trail. Build the trail to be read by a regulator rather than by an engineer: claim identifier, what the agent saw, what it proposed, which rule or retrieval supported it, who approved it, when, and what was communicated. If reconstructing that requires a database query and an afternoon, it is telemetry, not evidence.

A claims agent is, structurally, one of the most exposed agent designs there is. It reads content it did not author — insured emails, contractor invoices, adjuster notes, photographs, PDFs from vendors and portals — and in any interesting design it also holds a credential into a system of record. Prompt injection is not solved, and anyone who tells you their product solved it is selling detection, which is a different thing.

The clearest available frame is the lethal trifecta: access to your private data, exposure to untrusted content, and the ability to externally communicate in a way that could be used to steal data. On whether it is fixable, the honest assessment from that source is that “we still don't know how to 100% reliably prevent this from happening.” On the vendor countermeasures you will be pitched: they “almost always carry confident claims that they capture ‘95% of attacks' or similar… but in web application security 95% is very much a failing grade.”

The Model Context Protocol security specification is worth reading even if you never adopt MCP, because it is a standards-body articulation of exactly this discipline. Its requirements are normative: MCP servers “MUST NOT accept any tokens that were not explicitly issued for the MCP server”; proxy servers must implement per-client consent before forwarding to a third-party authorization server, with redirect-URI validation by “exact string matching (not pattern matching or wildcards)”; and servers “MUST NOT treat possession of a state handle as authentication.” Its scope-minimisation section names the risks directly — “Expanded blast radius: stolen broad token enables unrelated tool/resource access”, privilege chaining, and “Audit noise: single omnibus scope masks user intent per operation” — and names the anti-patterns: wildcard or omnibus scopes, publishing all scopes as supported, bundling unrelated privileges.

Notice what none of that does. Every one of those controls is blast-radius reduction; none of them prevents injection.That the protocol's own security document is entirely about confused deputies, token scope and consent is the tell. Design your claims agent on the same assumption.

For the numbering everyone quotes: the OWASP GenAI LLM Top 10 for 2026 places LLM01:2026 Prompt Injection, LLM03:2026 Excessive Agency and LLM10:2026 Improper Output Handling. For agents with tool access to production systems, LLM03 and LLM10 are the priority pair, and the mitigations cited for excessive agency are unglamorous and correct: least privilege, confirmation for high-impact actions, and tool-usage logging. Note that the 2025 numbering is different — in the 2026 list, LLM05 is Data and Model Poisoning and LLM06 is Unbounded Consumption — so a document citing “LLM06 and LLM05” while describing excessive agency and output handling is working from the old list.

Finally, the part that actually causes incidents in production claims systems: idempotency. There is no standard for it. The IETF Idempotency-Key header draft sits at revision -07, dated 15 October 2025, in IESG state Expired, and it is not an RFC. The de-facto convention is Stripe's, and its documentation is the best available reference: the mechanism works by saving the status code and body of the first request for a given key regardless of success, so subsequent requests with the same key return the same result including 500 errors; parameters are compared against the original and mismatches error; and keys may be pruned after at least 24 hours, meaning a retry a week later is a brand-new write. That last detail is where duplicate transactions actually come from.

• Derive the key from business intent, not from the attempt: Key on something like (carrier, claim number, transaction type, effective date) rather than a fresh identifier per retry. A new UUID per attempt defeats the mechanism entirely, and it is the single most common implementation error.
• Persist the key before the call, not after: A key that exists only in the agent's context window is lost on crash, which is the classic duplicate source in agent systems specifically.
• Never let the model choose the key: Non-determinism in key generation is indistinguishable from having no idempotency at all.
• Outlive the downstream retention window: If the system of record prunes keys at 24 hours, your own dedupe table must live longer, or a delayed retry writes twice.
• Reconcile rather than trust: Read back against the claims core on a schedule and compare. Treat the system of record as truth and the agent's belief as a hypothesis — agents write over unreliable networks and get interrupted mid-plan.
• Prefer reversible writes: A draft note beats a posted transaction; a proposed assignment beats a committed one. Reversibility is the cheapest blast-radius control available and it composes with everything above.
• Take the free checkpoint where batch exists: Batch and EDI rungs get reconciliation almost for free, because the file is the checkpoint. Real-time API writes do not; budget for building it.

One last note on protocols, because it comes up in every vendor conversation. MCP and A2A are transport and discovery, not permission. The current MCP specification, dated 2026-07-28, describes the protocol transforming from a bidirectional stateful protocol into a request-response stateless one — a genuine breaking change roughly eight months after the prior stable specification, and a real consideration if you are betting a claims integration on that cadence. A2A reached v1.0 in April 2026 under Linux Foundation governance; the foundation's own press release cites 150-plus organisations and 22,000-plus GitHub stars, which is a support and membership count rather than a count of production deployments. None of it gives you a write path into a claims core that your contract does not already grant.

This is a delivery plan, not a benefits list. Each phase has a week range, a named owner, an entry and exit criterion, and an explicit instruction for what to do when it fails. Week ranges overlap deliberately — Phase 3 is a parallel track for property lines and should never gate Phases 1, 2 and 4.

A note on Phase 0, which is the phase most organisations skip and most regret skipping. The write-path discovery is not an IT formality — it determines whether the programme you have budgeted is possible at all. If the answer comes back that production writes require partner enrollment at an undisclosed fee with a nine-month procurement cycle, that is not a setback, it is information you needed in week two rather than week twenty. And the fallback is a genuinely good product: an agent that drafts, summarises, triages and recommends, with a human committing every write through the existing interface. That is a legitimate architecture. In regulated claims it is frequently the correct one regardless of what the contract permits.

On sequencing across workflows: build FNOL intake and acknowledgment first if your service-level metrics on acknowledgment are visibly under pressure, because §4(B) exposure and customer experience move together and the write surface is the friendliest in the core. Build subrogation identification first if your recovery function is under-resourced, because the analysis runs on closed records and the write is a task rather than a transaction. Build the estimating feed first only if you have a specific catastrophe-season capacity problem and the second vendor agreement is already in place.

The claims AI market is crowded, and most of the differentiation in the pitch decks is in numbers nobody can trace. The table below is the diligence checklist we run for clients, in the order the flags usually appear.

Two of those rows deserve expansion, because they are the ones that most often survive diligence unchallenged.

These are Frenchy Digital's engagement bands for agent work in regulated claims environments. They exclude your vendor's partner or API fees, which — as established throughout this article — we cannot price, because no claims-core or estimating vendor we checked publishes them.

Frenchy Digital cost bands for P&C claims AI engagements, 2026.

Senior-led delivery runs $150 to $225 per hour, and ongoing retainers run $2,500 to $9,500 per month covering model and dependency upgrades, evaluation expansion, incident response, integration contract tests, and a quarterly technical review. Every engagement carries a 30-day post-launch warranty, and you receive a written scope with a fixed-price phased proposal within 5 business days of the discovery call.

One budgeting caution specific to this industry. If your business case depends on production write access to the claims core, treat the partner or API fee as a recurring cost, forever, and get the fee model in writing even when the amount is unavailable. A flat annual fee and a per-transaction fee produce very different economics at claim volume, and the shift from one to the other is a known pattern at renewal in partner programs generally. If a per-transaction model would break your business case, you need to know that before you build, not at your first renewal.

The regulatory citations in this article are traced to primary text. A good deal of what surrounds them is not, and it is worth being precise about which is which — because the gaps below are exactly where a vendor deck will offer you a confident number.

• The NAIC AI Model Bulletin's own text: We verified adoption from the NAIC's August 6, 2026 map. We did not fetch the bulletin itself, so we quote none of its sections and describe its requirements only in general terms attributed to law-firm summaries. If your compliance function needs the operative language, read the bulletin, not this article.
• Whether any regulator has acted against an automated claims system under §3(B): We found no case, enforcement action or published complaint applying the general-business-practice element to an automated claims system. That is why the frequency argument in this article is framed as an argument rather than as law. It is also why nobody can tell you how a market conduct examiner will actually treat your agent's logs.
• Which states permit a private right of action under their UCSPA variants: The NAIC model expressly creates none, and its drafting note says the act is inherently inconsistent with one. But state enactments vary, some feed bad-faith claims, and we did not survey them. This is a question for your counsel in each state you write in.
• Claims-core market share, in any form: Every 2026 source we chased was SEO content marketing or a report-selling press release with no visible methodology, and we could not obtain neutral analyst data. We also could not retrieve an audited customer count from public filings. So we name the vendors and refuse the percentages, along with the market-sizing projections that circulate alongside them.
• Any vendor's partner or API fees: Not published, at any claims-core or estimating vendor we checked, in any form. This is a finding rather than an omission — but it means every cost figure in a vendor business case that includes integration fees is an estimate someone made up.
• The corporate status of any vendor named here: We make no ownership, listing-status, independence or acquisition claim about any vendor in this article, because we did not research it. If a vendor's corporate stability matters to your decision — and at renewal it should — verify it directly from public filings rather than from commentary.
• The auto physical damage estimating ecosystem: This article covers the property estimating write path. The equivalent posture on the auto physical damage side was not researched for this piece, and we will not characterise integration terms we did not check. If your book is predominantly auto, treat that as an open question in your own Phase 0.
• Colorado's quantitative testing regulation: We could not verify its scope or final status as of August 2026. Drafts reference life insurers with expansion discussed elsewhere. We therefore state neither which lines it covers nor that it is final, and we do not claim Colorado's ECDIS framework squarely governs claims adjudication agents.
• California and Florida adjuster licensing: The claim we encountered was self-contradictory within its own source, and we could not verify either state independently. We write nothing about it, and you should discount any article that does so casually.
• Whether any protocol or standard will change the write-path picture: MCP is a wrapper around whichever rung you are already on. ID-JAG is an Internet-Draft at revision -04, IESG state “I-D Exists” — not an RFC, and not expired. The separate IETF Idempotency-Key header draft is expired at revision -07, so there is no standard for idempotency keys at all. None of the standards work in flight today gives an agent a contractual right to write into a system of record, and we found no credible timeline suggesting it will.
• Any independent measurement of agent-integration success rates: None exists that we could find, in this industry or any other. We are not going to imply one does — and that includes the widely circulated pilot-failure percentages, all of which we refuse on the same grounds we refuse the leakage figures.

The most valuable output of a claims AI discovery is rarely the model architecture. It is a one-page answer to the question nobody asked at the kickoff: which of our systems will actually let us write, under which agreement, at what price, for how long.

— Frenchy Digital, on scoping claims agent programmes

Which returns the argument to where it started. The interesting constraint in P&C claims is not model capability, and it has not been for some time. It is that the claims core owns one write path, the estimating platform owns another, neither publishes what access costs, and the Unfair Claims Settlement Practices Act decides independently of both what a licensed human must still do personally. An organisation that maps those three things honestly — before it selects a vendor, before it writes a prompt — will ship something durable. One that starts from the model will build a very impressive demonstration of a workflow it is not permitted to complete.