Insurance leaders asking about an AI agent for first notice of loss usually start with the wrong cost question. They want to know what the model costs per claim. The honest answer is: very little. The expensive parts are connecting the agent to systems built in a different decade, proving it behaves, and producing the paperwork a market conduct examiner will ask for.
This guide breaks down both sides, run cost and build cost, using published prices you can check, and gives you a way to scope a first version that is small enough to ship and big enough to learn from.
What a claims intake agent actually does
Before pricing anything, be precise about the job. A claims intake agent is not a claims adjuster. In the version worth building first, it does five things:
- Identifies the claimant and the policy. Looks up the policy by number, name and date of birth, or by the logged-in account, and confirms the policy was in force on the date of loss.
- Collects the facts of loss. Asks the questions your adjusters need for this line of business and this type of loss, in plain language, and adapts follow-up questions to the answers.
- Gathers documents and photos. Requests the police report, repair estimate, medical bill or photos, and extracts the fields that matter.
- Checks completeness and flags obvious issues. Missing information, a date of loss outside the policy period, a duplicate submission.
- Creates the claim and routes it. Writes a structured first notice of loss into the claims system, attaches a summary, and assigns it to the right queue, with a clear reason when it hands off to a human.
Notice what is missing: coverage decisions, reserves, settlement offers and fraud determinations. Those can come later, and some of them, such as fraud scoring, are better handled by separate, purpose-built models. Keeping intake narrow keeps both cost and regulatory exposure down.
Run cost: the per-claim math
Here is a worked example using Anthropic's published API pricing as of October 2026. Claude Sonnet 5.5 is listed at $2 per million input tokens and $10 per million output tokens, with prompt cache hits at $0.10 per million and five-minute cache writes at $2.50 per million. The smaller Claude Haiku 5.5 is listed at $0.10 and $0.50 per million for prompts up to 100,000 tokens.
Assume a web chat intake for a home or auto claim with these characteristics:
- 12 turns of conversation.
- About 8,000 input tokens per turn: a system prompt with the intake script and policy summary, tool definitions, and the conversation so far. Roughly 6,000 of those tokens are the stable prefix that can be cached.
- About 300 output tokens per turn, including tool calls.
| Cost line | Without caching | With prompt caching |
|---|---|---|
| Input tokens (12 × 8,000 = 96,000) | 96,000 at $2/M = $0.192 | 24,000 uncached at $2/M = $0.048, plus 72,000 cached at $0.10/M = $0.007 |
| Cache write (one-time, 6,000 tokens) | n/a | 6,000 at $2.50/M = $0.015 |
| Output tokens (12 × 300 = 3,600) | 3,600 at $10/M = $0.036 | 3,600 at $10/M = $0.036 |
| Classification and routing steps on Haiku 5.5 (about 4,000 in, 200 out) | about $0.0005 | about $0.0005 |
| Model cost per claim | about $0.23 | about $0.11 |
Your numbers will differ. Long policy wordings, image-heavy claims and agents that call many tools push token counts up. But the order of magnitude holds: model cost per intake is measured in cents, not dollars. At 50,000 claims a year, even the uncached figure is around $11,500 in model spend.
Document extraction is the line people miss
Attachments change the picture. If you use a dedicated document service rather than sending every page to the language model, the price depends on how much structure you ask for. AWS lists Textract pricing at $0.0015 per page for plain text detection on the first million pages, and $0.07 per page when you combine forms, tables and queries.
For a claim with six pages of attachments, that is roughly one cent at the cheap end and 42 cents at the expensive end. In other words, structured extraction can cost more than the entire conversation. That is fine if those fields save an adjuster ten minutes. It is waste if you are running the full analysis on photos of a dented bumper.
The practical rule: run cheap OCR on everything, classify the document type with a small model, and only send the document types that need it, such as repair estimates, medical bills and police reports, through structured extraction. If documents are a large part of your claims volume, the pipeline design is closer to document management software than to chatbot work, and deserves its own scoping.
Other run costs to budget
- Voice. Phone intake adds telephony, speech-to-text and text-to-speech, each billed by the minute or by the character by its vendor. Price it separately from your chat channel and expect it to dominate per-claim run cost for phone claims. Designing AI voice agents also brings its own latency and interruption problems, which is another reason to start with chat.
- Hosting, logging and storage. Every conversation, tool call and model output should be stored for audit. Retention periods set by your records policy will matter more than compute.
- Human review time. If adjusters review every AI-created claim at first, that review time is a real cost. It should fall as accuracy is proven, and tracking it is how you prove the case.
Build cost: where the budget really goes
We will not quote a single dollar figure, because any number without your systems, volumes and lines of business would be made up. What we can do is show how a realistic first version breaks down by effort. The proportions below are how we would expect a scoping exercise to land for a mid-sized carrier or MGA with an existing claims platform. Treat them as a planning lens, not a benchmark.
| Workstream | Share of effort | What drives it up |
|---|---|---|
| Integration with policy admin and claims systems | 25 to 35% | No usable API, batch-only interfaces, on-premise systems, strict change windows |
| Conversation and intake design | 10 to 15% | Many loss types, multiple languages, accessibility requirements |
| Agent logic, tools and guardrails | 15 to 20% | Complex routing rules, coverage pre-checks, multi-party claims |
| Evaluation: test sets, scoring, red-teaming | 15 to 20% | Lack of labelled historical claims, privacy constraints on test data |
| Security, privacy and governance documentation | 10 to 15% | Health data, multi-state footprint, EU claimants, vendor risk reviews |
| Monitoring, hand-off tooling and launch | 10% | Adjuster workflow changes, contact center integration |
Two things stand out. First, the AI-specific work (prompting, tools, model selection) is a minority of the effort. Second, evaluation is a full workstream, not a final QA step. If you cannot answer "how often does the agent record the wrong date of loss?" with a number, you are not ready to launch, and you will not be able to answer the regulator either.
Why integration dominates
An intake agent that cannot read the policy or write the claim is a fancy web form. Many core insurance platforms expose modern APIs, but many carriers run customized versions, older releases or in-house systems where creating a claim means a batch file or a screen-scraping bot. The integration estimate is the one to pressure-test hardest, and it is the reason we usually recommend a short discovery phase with your claims IT team before anyone commits to a delivery date. If your core systems need work anyway, that sits closer to insurance software development than to an AI project, and it is better to know that early.
Why evaluation is not optional
Language models are probabilistic. The same claimant story told two ways can produce two different extractions. The only defence is a test set built from real, de-identified claims covering your common loss types and your awkward edge cases, scored automatically on every change to prompts, tools or model version. Building that set takes adjuster time, which is the scarcest resource in most claims departments. Budget for it explicitly.
Working on something like this? See our Claude Agent Development →
The compliance work insurers forget to price
In the US, the National Association of Insurance Commissioners adopted its model bulletin on the use of AI systems by insurers on December 4, 2023. States adopt it individually: when Wisconsin issued its bulletin in March 2025, it became the 24th state to do so, according to law firm Troutman Pepper Locke. The bulletin expects insurers to maintain a written AIS Program for AI systems that make or support decisions related to regulated insurance practices.
Three details in the text matter directly for an intake agent:
- The program should cover the whole insurance life cycle, and the bulletin lists "claim administration and payment" by name.
- It applies to AI systems "whether developed by the Insurer or a third-party vendor". Buying a product does not move the obligation.
- In an investigation or market conduct action, an insurer "can expect to be asked about its development, deployment, and use of AI Systems" and their outcomes.
For an intake agent, that means design documents, test results, change logs, monitoring reports and records of every conversation are deliverables, not nice-to-haves. Producing them during the build is far cheaper than reconstructing them after a regulator asks.
If you serve claimants in the EU, two parts of the AI Act are relevant. Article 50 requires that people are informed they are interacting with an AI system unless that is obvious from context. And Annex III classifies as high-risk AI systems "intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance". A pure intake agent does not do risk assessment or pricing, which is one more reason to keep the first version narrow and to keep scoring and pricing logic out of it.
Build, buy or configure: a decision matrix
Claims intake is a crowded vendor market, and for some carriers buying is the right call. Here is how we would think about it.
| Situation | Leaning | Why |
|---|---|---|
| Standard personal auto or home, mainstream claims platform with vendor connectors | Buy | The intake questions are well known and the integration is someone else's maintained product. |
| Specialty commercial, embedded or parametric products | Build | Off-the-shelf scripts will not fit, and your intake logic is part of your edge. |
| Agent must live inside your own customer app or broker portal | Build or configure an agent framework | Vendor widgets rarely match your UX or your authentication model. |
| Vendor cannot give audit rights, model change notices or full conversation logs | Build | Your AIS Program still needs that evidence. |
| Low volume, under a few thousand claims a year | Improve the form first | A better structured web form and document upload may deliver most of the value at a fraction of the cost. |
That last row deserves emphasis. An AI agent is not automatically better than a well-designed form. If your claim types are few and predictable, a smart form with conditional questions and good document upload will be cheaper to build, easier to audit and faster for most claimants. The agent earns its cost when stories are messy, documents vary and follow-up questions depend on what the claimant just said.
How to scope a first version that ships
The fastest way to blow an AI budget is to start with every line of business, every channel and every language. Here is the sequence we recommend:
- Pick one line of business and one channel. Web chat or in-app is easier to evaluate than voice. Choose a line with enough volume to measure and enough mess to justify an agent.
- Measure the current baseline. Time from first contact to a complete claim file, share of claims needing follow-up, and adjuster time spent on intake. Without this, nobody can tell whether the agent helped.
- Build the test set before the agent. A few hundred de-identified historical claims with the correct structured output. This becomes your acceptance test.
- Run a proof of concept on historical data. Replay past claims through the agent and score it. This is the cheapest point to discover that extraction is unreliable for a given document type. A focused AI proof of concept should answer that in weeks.
- Launch in assist mode. The agent creates draft claims that adjusters confirm. Track correction rate per field.
- Move fields to straight-through as they prove out. When the correction rate on, say, date and location of loss stays low for a sustained period, stop requiring confirmation for those fields.
- Only then expand. Add a second line of business, then voice, then decision support for adjusters.
Each step produces evidence for your AIS Program as a side effect. That is the real advantage of a staged build: the compliance work and the product work stop competing for the same budget.
Where per-claim costs creep up in production
Once live, watch for these patterns. They are the usual reasons a cents-per-claim estimate turns into dollars:
- Prompt bloat. Every incident leads to another paragraph in the system prompt. Without caching discipline, input costs climb quietly.
- Using the biggest model for everything. Routing, document classification and simple yes/no checks run fine on small models priced at a fraction of the large ones.
- Re-extracting the same documents. Claimants upload the same estimate twice. Hash files and cache extraction results.
- Retry loops. A tool call fails, the agent retries, the conversation grows, and each retry re-sends the whole context.
- Unbounded conversations. Set a turn budget. After it, summarize and hand off to a human.
All of these are visible if you instrument the agent properly: tokens, latency and outcome per conversation, broken down by step. That kind of agent monitoring is also exactly what your governance program needs, so it pays twice.
Our take
The economics of AI claims intake are better than most carriers assume on the run side and worse than vendors imply on the build side. Model cost per claim is small enough to ignore in the business case. Integration, evaluation and governance are not, and they are where projects stall.
So scope narrowly, measure against a real baseline, keep decisions with humans until the evidence is in, and treat documentation as part of the product. A carrier that does that can have a useful intake agent on one line of business in months and a clear, defensible case for expanding it.
If you are weighing an intake agent and want a second opinion on scope, integration risk or build versus buy, Northell can run a short discovery with your claims and IT teams and give you an estimate grounded in your systems. Get in touch and tell us which line of business you would start with.
