Building a Multi-Agent AI Claims Processing Assistant on AWS with Strands Agents SDK and Amazon Bedrock

11:58Claude responded: A four-agent insurance claims pipeline on AWS that automates document intake, fraud scoring, coverage adjudication, and claimant communication — with a human-i…A four-agent insurance claims pipeline on AWS that automates document intake, fraud scoring, coverage adjudication, and claimant communication — with a human-in-the-loop escalation gate for high-risk claims.

sweta jha

Published Jun 26, 2026

Last modified Jun 26, 2026

Building a Multi-Agent AI Claims Processing Assistant on AWS with Strands Agents SDK and Amazon Bedrock

GitHub: https://github.com/its-me-sweta/Claim_Processing_AI_Assistant.git

Introduction

Insurance claims processing is one of the most document-heavy, rule-intensive, and fraud-prone workflows in the industry. A single claim touches document extraction, policy validation, fraud scoring, coverage adjudication, and multi-channel communication — all before a dollar is paid out.

In this post, I'll walk you through how I built a production-ready, four-agent AI pipeline that automates this entire workflow using:

Strands Agents SDK with @tool decorators
Amazon Bedrock Nova Pro (us.amazon.nova-pro-v1:0) as the LLM backbone
Amazon Textract for document extraction
Amazon SageMaker for fraud scoring
Amazon RDS Aurora for policy and claim storage
Amazon SES + SNS for claimant and adjuster notifications
Amazon DynamoDB for pipeline state and audit trails
AgentCore Runtime for serverless deployment
FastAPI as the REST layer

The system includes a human-in-the-loop approval gate for high-value or high-fraud-risk claims — a pattern that aligns with both EU AI Act compliance requirements and real-world enterprise risk controls.

Architecture Overview

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
                        ┌─────────────────────────────────────┐
                        │         FastAPI / REST Layer         │
                        │    POST /claims/submit               │
                        └──────────────┬──────────────────────┘
                                       │
                        ┌──────────────▼──────────────────────┐
                        │         Orchestrator Agent           │
                        │   (Routing · State · Coordination)   │
                        └───┬───────────────────────────┬─────┘
                            │                           │
              ┌─────────────▼────┐         ┌────────────▼──────────┐
              │   Intake Agent   │         │  Fraud Detection Agent │
              │  Textract · RDS  │         │  SageMaker · Watchlist │
              └─────────────┬────┘         └────────────┬──────────┘
                            │                           │
                            └──────────┬────────────────┘
                                       │
                        ┌──────────────▼──────────────────────┐
                        │       Adjudication Agent            │
                        │  Coverage · Deductible · Settlement  │
                        └──────────────┬──────────────────────┘
                                       │
                       ┌───────────────┼───────────────────┐
                       │               │                   │
          ┌────────────▼────┐   ┌──────▼──────┐   ┌───────▼──────┐
          │ Communication   │   │ Human Review│   │  SIU Referral│
          │ Agent (SES/SNS) │   │  Queue      │   │  (SNS Topic) │
          └─────────────────┘   └─────────────┘   └──────────────┘

The Four Agents

Agent	Role	AWS Services
Intake Agent	Parse, validate, and store incoming claims	Textract, RDS Aurora
Fraud Detection Agent	Score fraud risk using ML + rule signals	SageMaker, DynamoDB
Adjudication Agent	Evaluate coverage, apply deductibles, settle	RDS Aurora, DynamoDB
Communication Agent	Notify claimants, adjusters, and SIU	SES, SNS

The Orchestrator Agent ties them together, managing routing decisions and human escalation gates.

Why Strands Agents SDK?

Strands gives you a clean, Pythonic way to define agent tools using the @tool decorator. No boilerplate JSON schema — the SDK infers parameter types and descriptions from your Python type hints and docstrings.

1
2
3
4
5
6
7
8
from strands import tool

@tool
def evaluate_coverage(policy_details: dict, loss_type: str, date_of_loss: str) -> dict:
    """
    Checks whether the policy covers the claimed loss type and date.
    ...
    """

Each agent is then constructed by passing the model and a list of tools:

1
2
3
4
5
6
7
8
9
from strands import Agent
from strands.models import BedrockModel

agent = Agent(
    model=BedrockModel(model_id="us.amazon.nova-pro-v1:0", region_name="us-east-1"),
    system_prompt=SYSTEM_PROMPT,
    tools=[evaluate_coverage, apply_deductible, calculate_settlement, ...],
    name="adjudication_agent",
)

The agent handles tool selection, parameter extraction, and multi-turn reasoning entirely on its own.

Deep Dive: The Pipeline Stages

Stage 1 — Intake Agent

The Intake Agent is the gateway to the pipeline. It handles three input modalities:

Structured JSON — Direct API submissions
PDF/Image documents — Processed via Amazon Textract
Form data — Key-value extraction from claim forms

1
2
3
4
5
6
7
8
@tool
def extract_claim_document(s3_bucket: str, s3_key: str) -> dict:
    """Runs Amazon Textract FORMS analysis on a claim document in S3."""
    response = textract.analyze_document(
        Document={"S3Object": {"Bucket": s3_bucket, "Name": s3_key}},
        FeatureTypes=["FORMS", "TABLES"],
    )
    # ... key-value pair extraction logic

After extraction, it validates all required fields:

claim_id, policy_number, claimant_name, date_of_loss
loss_type must be one of: medical | auto | property | liability
claimed_amount must be positive
date_of_loss cannot be in the future

If validation passes, the claim is persisted to RDS Aurora and returned to the Orchestrator.

Stage 2 — Fraud Detection Agent

The Fraud Detection Agent computes a composite fraud score using four signals:

1
2
3
4
5
Composite Score =
    0.40 × ML Model Score (SageMaker endpoint)
  + 0.20 × Claim Frequency Anomaly
  + 0.25 × Watchlist Match
  + 0.15 × Document Integrity Score

Risk thresholds:

Score Range	Risk Level	Action
0.0 – 0.3	Low	Proceed to adjudication
0.3 – 0.6	Medium	Proceed with enhanced flags
0.6 – 0.8	High	Route to human review
0.8 – 1.0	Critical	SIU referral

The SageMaker integration calls a pre-trained fraud detection endpoint:

1
2
3
4
5
6
7
8
9
10
11
@tool
def run_fraud_model(claim_features: dict) -> dict:
    """Invokes the SageMaker fraud detection endpoint."""
    payload = json.dumps({"instances": [feature_vector]})
    response = sagemaker_runtime.invoke_endpoint(
        EndpointName="claims-fraud-detection-endpoint",
        ContentType="application/json",
        Body=payload,
    )
    score = float(json.loads(response["Body"].read())["predictions"][0][0])
    return {"ml_fraud_score": round(score, 4), ...}

A rule-based fallback activates automatically if the SageMaker endpoint is unavailable — a production reliability pattern I'd recommend for any mission-critical pipeline.

Stage 3 — Human-in-the-Loop Gate

Between fraud detection and adjudication, the Orchestrator checks two escalation triggers:

1
2
3
4
5
6
# Trigger human review if:
# 1. Fraud score > 0.7, OR
# 2. Claimed amount > $50,000

if fraud_score > 0.7 or claimed_amount > 50_000:
    trigger_human_review(claim_id, reason, fraud_score, claimed_amount)

The trigger_human_review tool:

Writes the claim to a Human Review Queue in DynamoDB
Publishes an SNS notification to the senior adjuster pool
Returns a queue ID with a 3-business-day SLA

This pattern satisfies both enterprise risk governance requirements and the EU AI Act's Article 14 human oversight provisions for high-risk AI systems.

Stage 4 — Adjudication Agent

The Adjudication Agent is the most rule-intensive component. It evaluates three dimensions:

1. Coverage Evaluation

1
2
# Policy must be ACTIVE, loss_type must be in covered_perils,
# and date_of_loss must fall within the policy period.

2. Exclusion Check
Each loss type has a catalogue of exclusions. For example, auto claims check:

Driving under influence
Unlicensed driver
Racing or speed contests

3. Settlement Calculation

1
2
3
4
net_settlement = min(claimed_amount, coverage_limit)
               × co_insurance_factor
               - deductible
               - salvage_value

1
2
3
4
5
6
7
8
9
10
11
@tool
def calculate_settlement(
    claimed_amount: float,
    coverage_limit: float,
    deductible_amount: float,
    salvage_value: float = 0.0,
    co_insurance_factor: float = 1.0,
) -> dict:
    capped = min(claimed_amount, coverage_limit)
    net = max(0.0, capped * co_insurance_factor - deductible_amount - salvage_value)
    return {"net_settlement": round(net, 2), ...}

Decision outputs: APPROVED | PARTIAL | DENIED | PENDING

Stage 5 — Communication Agent

The Communication Agent generates legally compliant, empathetic letters and dispatches them via Amazon SES. It also routes internal alerts:

1
2
3
4
@tool
def send_adjuster_alert(claim_id, reason, fraud_score, claimed_amount, priority) -> dict:
    """Publishes to the adjuster SNS topic for human review escalations."""
    sns.publish(TopicArn=ADJUSTER_SNS_TOPIC, Message=json.dumps({...}))

Key communication rules:

SIU referrals: The claimant receives a neutral holding notice — never a fraud disclosure
Denials: Must include the 30-day appeals window
Every communication is logged to DynamoDB for audit trail compliance

Deployment: AgentCore Runtime

The pipeline is deployed as a serverless function using AWS Bedrock AgentCore Runtime:

1
2
3
4
5
# agentcore_handler.py
def handler(event: dict, context) -> dict:
    claim_payload = event.get("claim", event)
    result = orchestrate_claim(claim_payload)
    return {"statusCode": 200, "body": json.dumps(result)}

The FastAPI layer wraps this for REST access:

1
2
3
4
5
6
7
8
9
10
11
# Submit a claim
curl -X POST https://your-api/claims/submit \
  -H "Content-Type: application/json" \
  -d '{
    "policy_number": "POL-2024-001234",
    "claimant_name": "Jane Smith",
    "date_of_loss": "2024-11-15",
    "loss_type": "auto",
    "claimed_amount": 18500.00,
    "claimant_email": "jane.smith@email.com"
  }'

AWS Infrastructure Summary

Resource	Purpose
Amazon Bedrock Nova Pro	LLM for all four agents
Amazon Textract	Document extraction (Intake Agent)
Amazon SageMaker Endpoint	Fraud ML model inference
RDS Aurora (PostgreSQL)	Policy database + claim records
DynamoDB (`claims-pipeline`)	Pipeline state + audit log
DynamoDB (`fraud-watchlist`)	Fraud entity watchlist
DynamoDB (`claims-history`)	Historical claims for frequency analysis
Amazon SES	Decision letter delivery
Amazon SNS	Adjuster alerts + SIU referrals
AgentCore Runtime	Serverless agent deployment

Key Design Patterns

1. Tool-First Agent Design

Every agent capability is a discrete, testable @tool function. This makes unit testing straightforward and keeps business logic out of the system prompt.

2. Graceful Degradation

The fraud detection agent falls back to rule-based scoring if SageMaker is unavailable. Critical paths should never have single points of failure.

3. Human-in-the-Loop Gate

Threshold-based escalation ensures high-risk decisions get human review before settlement — a pattern required for enterprise compliance and responsible AI deployment.

4. Audit Trail by Default

Every pipeline stage, status change, and communication is logged to DynamoDB. This is non-negotiable in regulated industries like insurance.

5. Separation of Concerns

Each agent has a single responsibility. The Orchestrator routes and coordinates — it does not evaluate fraud or calculate settlements.

What's Next

This pipeline is a solid foundation. Here are extensions worth exploring:

RAG-powered exclusion lookup: Replace the static exclusion catalogue with a FAISS or OpenSearch index over policy documents
AgentCore Memory: Add cross-session claim memory using Amazon Titan Embed v2 for repeat claimant context
Multi-modal intake: Process claim photos directly with Nova's vision capabilities
Compliance layer: Add a dedicated GDPR/HIPAA compliance agent using the Strands Compliance Review pattern

Try It Yourself

The full source code for this project is available on GitHub:

https://github.com/its-me-sweta/Claim_Processing_AI_Assistant.git

1
2
3
4
git clone https://github.com/its-me-sweta/Claim_Processing_AI_Assistant.git
cd claims-processing-assistant
pip install -r requirements.txt
uvicorn main:app --reload

Built with Strands Agents SDK · Amazon Bedrock Nova Pro · AgentCore Runtime

# aws-builders # ai-agents # strands

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

Building a Multi-Agent AI Claims Processing Assistant on AWS with Strands Agents SDK and Amazon Bedrock

sweta jha

Building a Multi-Agent AI Claims Processing Assistant on AWS with Strands Agents SDK and Amazon Bedrock

Introduction

Architecture Overview

The Four Agents

Why Strands Agents SDK?

Deep Dive: The Pipeline Stages

Stage 1 — Intake Agent

Stage 2 — Fraud Detection Agent

Stage 3 — Human-in-the-Loop Gate

Stage 4 — Adjudication Agent

Stage 5 — Communication Agent

Deployment: AgentCore Runtime

AWS Infrastructure Summary

Key Design Patterns

1. Tool-First Agent Design

2. Graceful Degradation

3. Human-in-the-Loop Gate

4. Audit Trail by Default

5. Separation of Concerns

What's Next

Try It Yourself