How to Build a claims processing Agent Using CrewAI in Python for insurance

A claims processing agent takes in a claim, extracts the relevant facts, checks policy coverage, flags missing evidence, and drafts a decision packet for an adjuster or claims ops team. For insurance, that matters because claims handling is where cycle time, leakage, compliance risk, and customer experience all collide.

Architecture

Build this agent as a small workflow, not a single “smart” prompt.

• •

  Claim intake layer

  • •Accepts FNOL payloads, emails, PDFs, photos, and structured claim forms.
  • •Normalizes inputs into a single claim record.
• •

  Document extraction component

  • •Pulls out claimant name, policy number, loss date, loss type, location, damages, and supporting evidence.
  • •Uses OCR or document parsing before the LLM sees anything.
• •

  Policy and rules checker

  • •Compares extracted facts against policy terms, exclusions, deductibles, limits, and waiting periods.
  • •Applies deterministic business rules before any recommendation is made.
• •

  Claims analyst agent

  • •Summarizes the case, identifies gaps, and drafts next actions.
  • •Produces an auditable rationale tied to source data.
• •

  Compliance and audit layer

  • •Logs prompts, tool calls, outputs, and final decisions.
  • •Enforces human review for high-value or high-risk claims.
• •

  Storage and integration layer

  • •Writes results back to the claims platform via API.
  • •Stores artifacts in-region to satisfy data residency requirements.

Implementation

1) Install CrewAI and define your claim workflow

Use CrewAI agents for roles and tasks. Keep the LLM responsible for analysis and drafting; keep coverage decisions grounded in tools and policy data.

pip install crewai crewai-tools pydantic

from crewai import Agent, Task, Crew, Process
from pydantic import BaseModel
from typing import Optional

class ClaimInput(BaseModel):
    claim_id: str
    policy_number: str
    loss_type: str
    loss_date: str
    description: str
    estimated_loss_amount: float
    documents: list[str]

claim = ClaimInput(
    claim_id="CLM-100245",
    policy_number="POL-88421",
    loss_type="water_damage",
    loss_date="2026-03-18",
    description="Kitchen pipe burst caused floor damage.",
    estimated_loss_amount=8400.00,
    documents=["policy_declaration.pdf", "repair_estimate.pdf", "photos.zip"]
)

2) Create specialized agents with clear boundaries

Don’t make one agent do intake, coverage analysis, fraud screening, and customer communication. Split responsibilities so you can test each part independently.

claims_intake_agent = Agent(
    role="Claims Intake Analyst",
    goal="Extract structured facts from claim input and identify missing information.",
    backstory="You work in first notice of loss intake for property claims.",
    verbose=True,
)

coverage_agent = Agent(
    role="Coverage Analyst",
    goal="Check the claim facts against policy terms and identify likely coverage issues.",
    backstory="You review policy language and apply claims handling rules.",
    verbose=True,
)

decision_writer_agent = Agent(
    role="Claims Decision Writer",
    goal="Draft a concise recommendation with audit-friendly reasoning.",
    backstory="You prepare adjuster-ready summaries for human review.",
    verbose=True,
)

3) Define tasks that produce auditable outputs

Each task should ask for structured output. In insurance systems you want traceability: what was known, what rule was applied, and what remains unresolved.

intake_task = Task(
    description=(
        f"Review this claim data: {claim.model_dump()}. "
        "Extract key fields: claimant details, policy number validation need, "
        "loss type, dates, estimated amount, missing documents."
    ),
    expected_output="A structured summary of the claim with missing items listed.",
    agent=claims_intake_agent,
)

coverage_task = Task(
    description=(
        "Using the intake summary only if available in context, assess likely coverage issues. "
        "Call out exclusions to check such as wear_and_tear or pre_existing_damage. "
        "Do not make a final payment decision."
    ),
    expected_output="Coverage assessment with risks and required follow-up questions.",
    agent=coverage_agent,
)

decision_task = Task(
    description=(
        "Write an adjuster-ready recommendation. Include: claim status suggestion "
        "(approve pending review / request more info / escalate), rationale, "
        "and a checklist of next actions."
    ),
    expected_output="Decision memo suitable for human review.",
    agent=decision_writer_agent,
)

4) Run the crew with sequential processing

For claims work, sequential execution is usually the right default. Intake feeds coverage analysis; coverage feeds the final memo.

crew = Crew(
    agents=[claims_intake_agent, coverage_agent, decision_writer_agent],
    tasks=[intake_task, coverage_task, decision_task],
    process=Process.sequential,
    verbose=True,
)

result = crew.kickoff()
print(result)

That pattern gives you a clean pipeline:

• •Intake normalizes the case.
• •Coverage analysis applies policy logic.
• •Decision writing produces an auditable summary for an adjuster.

If you want stronger control in production:

• •Put deterministic checks outside the LLM.
• •Use tools for policy lookup instead of embedding policy text in prompts.
• •Gate low-confidence cases to human review.

Production Considerations

• •

  Keep regulated data inside approved regions

  • •Claims often contain PII/PHI-like sensitive data depending on line of business.
  • •Pin storage buckets, vector stores if used laterally, and model endpoints to approved jurisdictions.
• •

  Log everything needed for audit

  • •Persist input payload hashes, extracted fields, prompt versions, model versions, task outputs, and reviewer overrides.
  • •Regulators will care about why a recommendation was made months later.
• •

  Add hard guardrails before any decision

  • •Never let the agent finalize denial or payment without deterministic checks plus human approval thresholds.
  • •Enforce limits by claim amount, jurisdiction, peril type, and fraud score.
• •

  Monitor drift by claim type

  • •Water damage claims behave differently from auto glass or bodily injury.
  • •Track error rates by line of business so one bad prompt doesn’t quietly poison a whole portfolio.

Common Pitfalls

• •

  Using one monolithic agent

  • •This turns every problem into prompt spaghetti.
  • •Split intake, coverage review, and recommendation into separate agents/tasks so failures are isolated.
• •

  Letting the model decide coverage from raw text alone

  • •That’s how you get hallucinated denials or approvals.
  • •Use tools or rules engines to validate policy status, deductibles,, exclusions,, waiting periods,, and limits before asking for a recommendation.
• •

  Ignoring auditability

  • •If you can’t show what input led to what output,, you can’t defend the workflow internally or externally.
  • •Store task outputs,, timestamps,, reviewer actions,, and versioned prompts alongside each claim record.

Keep learning

• •The complete AI Agents Roadmap — my full 8-step breakdown
• •Free: The AI Agent Starter Kit — PDF checklist + starter code
• •Work with me — I build AI for banks and insurance companies

By Cyprian Aarons, AI Consultant at Topiax.