AI claims processing with a specialist still deciding

Claim files read by agents, decided by your specialist

For a US health insurer we cut claim review from 3 hours to 8 minutes, and a specialist still decides on every claim.

claims-review
  1. Intake agentAgent

    1. portal.fetch_claim policy, scans and notes
    2. parser.read handwritten forms included

    A new accident claim is assembled into one case file.

  2. Review agentAgent

    1. model_a.extract dates, exclusions, procedures
    2. model_b.extract the same fields, independently
    3. checks.compare both readings, field by field
    4. benefits.get_limits limits already used

    Summary ready with one flag: the two readings disagree on the accident date. Please check it on the scan.

    Needs a personSpecialist decisionPay or deny stays with your team
    Decided by Claims specialist
  3. Review agentAgent

    1. claims.log_decision summary, flags and decision

    Decision logged with the summary and both readings, so an auditor can trace it.

Example data. An agent at work in a team channel, with a person approving the step you choose.
Mixam: conversion to a final sale from about 20% to about 40%
Where agents help

Claim files take hours to read before anyone decides.

Agents do the reading and checking, and your specialists keep every decision.

  1. 01

    Where it stallsBacklogs grow faster than you can hire reviewers.

    What we do Agents assemble and summarise each file, so a specialist starts from a checked summary with flags.

  2. 02

    Where it stallsReviewers re-read the same documents on every claim.

    What we do An agent parses policies, scans and notes once and points to the line behind each finding.

  3. 03

    Where it stallsErrors slip through when one person reads everything.

    What we do Two models read each file and code compares them. When they disagree, the claim goes to a person.

What we build

What we build for claims teams

Whatever comes in, every project is built from the same parts below, set up for your files and your systems.

Claims we handle

  • Health claims
  • Accident claims
  • Property damage
  • Motor claims
  • Travel claims
  • Liability claims
  • Warranty claims
  • Appeals and reviews

How we build it

  • Document parsing and case assembly

    Policies, scans, notes and images parsed into one case record, handwriting included.

  • Two readings and a code check

    Two models extract the same fields and an algorithm compares them.

  • Benefits and claims system connections

    Live calls to your benefits database and claims system, with the access rights you set.

  • Review rules your specialists agree

    Escalation rules agreed with your reviewers and enforced in the system.

Not seeing your case? Bring the claim type that takes your specialists longest and we start from that.

Tell us about your workflow
How we build agents

Agents that work as part of your team

They work in the tools your team already uses, take on whole tasks and stop for a person where you decide.

  1. Routines: agents that start on a schedule, on new GitHub issues or on an API delivery.
  2. Connected systems: GitHub, Linear, Notion, Slack, Jira and other tools an agent may call, each connected with its own sign-in.
  3. Approvals log: each action that waited for a person, with who asked, who decided and when.
Routines: agents that start on a schedule, on new GitHub issues or on an API delivery.
Connected systems: GitHub, Linear, Notion, Slack, Jira and other tools an agent may call, each connected with its own sign-in.
Approvals log: each action that waited for a person, with who asked, who decided and when.

Screens from the workspace our agents run in, with example data.

Engineering in the open

We help build what agentic AI runs on

Open standards, open-source tooling and published research, all public, so you can check our engineering before you hire us.

Shaping agentic AI

Agentic AI Foundation

Vstorm was the first agentic AI engineering company to join the Agentic AI Foundation and received its 2026 Open Agentic AI Innovation Award.

Read the announcement

Open source

We build open-source agent tooling that other engineering teams install

10M+ PyPI downloads
4,000+ GitHub stars
33 public repositories

Framework contributors

When the framework breaks, we fix it at the source

We maintain our own open-source agent framework and contribute fixes to the frameworks our agents run on, through official partnerships with their teams. Breaking changes reach us before they reach your codebase.

Research

Our engineers and PhDs publish peer-reviewed research

Peer-reviewed papers on agent architectures, evaluation and AI security, and an open benchmark anyone can rerun against our results.

Track record

Frontier AI teams now build on what we shipped first

Our client agents were in production before most of today's agent frameworks had a stable release. You get a team that already knows what breaks between a promising demo and a system people rely on every day.

Engagement models

Ways to start

Each path starts with a free call with a founder or senior AI engineer. A build goes ahead only after its Proof of Value meets the agreed threshold.

Start with one workflow

We map one workflow with your experts and agree a success threshold before any build.

Best whenYou want the success test agreed before you commit to a build.

  1. Process redesign and build Best whenYou want one team accountable for the outcome.
FAQ

AI claims processing, answered

What is AI claims processing? +
AI claims processing uses an agent to assemble a claim file. It parses policies, scans and notes, extracts dates, exclusions and procedures, checks benefit limits and hands a specialist a structured summary with flags. The specialist reads the summary and decides on pay or deny. The agent prepares that decision and leaves it to the specialist.
Which claims suit an agent first? +
Claims that arrive as many documents and take hours of reading before a short decision, such as accident claims with overlapping policies. Start with one claim type, agree an accuracy threshold with your reviewers and measure it on your own past files. For the insurer we worked with, the same workflow is being extended to maternity and hospital claims.
Have you built this before? +
Yes. For a US health insurer we built a claims system that combines LlamaParse, GPT and Gemini reading in parallel, an algorithmic check and a live API into the benefits database. Claim processing fell from 3 hours to 8 minutes, and a specialist still decides. For a US Medicare Advantage provider we built an agent that gathers patient information by SMS and voice.
What happens when the two models disagree? +
The claim is flagged for a person and the readings are never merged automatically. When both models agree and the algorithmic check passes, confidence is high and the summary goes to the specialist. When they diverge, the summary shows the exact field in question. Escalation rules and thresholds are agreed with your reviewers before the build.
How do you know it works before the full build? +
We agree a success threshold with your team before the build and test the agent on your own cases in a Proof of Value. It measures accuracy and running costs, and the build goes ahead only when the threshold is met. Corrections from your team go back into the test set, so every later version is checked against them.
Who owns the system, and which models does it run on? +
You own the code, prompts, evaluation sets and rules by contract. The agents run in your environment on hosted or open-weight models. The model sits behind an interface in code, so you can change it when accuracy, speed or your hosting rules change, without rebuilding the agent.
Start with one workflow

Test one workflow on your own data

A Proof of Value shows accuracy and running costs before the full build.