ClaimPilot

• 

Inspiration

A warranty claim should be simple: find the invoice, call the service center, explain the fault, and save the case number. In reality, the invoice is buried in an inbox, the policy is difficult to interpret, the serial number is missing, and people postpone the call until the warranty is nearly over.

India's Right to Repair portal exists to make warranty and post-sales information easier to find, but acting on that information still requires a consumer to assemble evidence, understand what matters, and navigate a repetitive service call.

We built ClaimPilot for that gap. It is an Everyday Agent that turns “my product is broken” into “here is your transcript-backed case number,” while keeping the owner in control of every real commitment.

What it does

ClaimPilot:

1. reads an invoice or warranty card into structured, sourced evidence;
2. checks the purchase against a specific, versioned warranty policy;
3. asks only for information the evidence cannot provide;
4. prepares the exact call plan and runs 17 deterministic safety checks;
5. waits for the owner to approve that exact plan;
6. places one allowlisted service call through CALL-E;
7. reconciles the provider result without unsafe automatic redialing; and
8. verifies the reported outcome against the transcript before showing it as fact.

The completed experience shows the call transcript, the evidence supporting the result, the case reference, and the next action for the owner.

ClaimPilot deliberately cannot accept a fee, agree to a waiver, authorize data deletion or remote access, call an emergency or consumer-helpline number, or silently accept an appointment outside the owner's approved window. Those outcomes become decisions for the human.

How we built it

ClaimPilot is not a chat wrapper. We implemented a small Strands Agents assessment graph containing agent nodes and deterministic code nodes:

• evidence_check determines which call-critical facts are usable;
• missing_info asks a bounded set of clarifying questions;
• eligibility_analyst is a Strands agent that returns a typed, citation-carrying preliminary assessment;
• plan_compiler is a Strands agent that writes the proposed call wording and questions;
• manifest_builder seals the exact plan;
• safety_gate runs 17 deterministic checks; and
• result_verifier may make an uncertain verdict stricter, but can never override a deterministic rejection.

The graph has conditional paths and a bounded clarification cycle. Every agent returns a Pydantic model, and all outputs are validated again at the boundary. Warranty-date arithmetic and action authority remain ordinary code.

The most important architectural decision is that phone dispatch is not a tool inside the agent graph. The graph ends at a proposed CallManifest. That manifest contains the destination, disclosures, goals, questions, appointment windows, fee limit, and prohibited commitments. Human approval is bound to a canonical hash of those contents. If anything material changes, the hash changes and the old authorization becomes invalid.

The AWS deployment uses:

• Amazon API Gateway and AWS Lambda for the FastAPI service;
• Amazon DynamoDB for claims, authorizations, call intents, and audit state;
• Amazon S3 for private documents;
• Amazon Cognito for verified identity and tenant isolation on the live team stack;
• Amazon SQS, a dead-letter queue, and a worker Lambda for durable reconciliation;
• Amazon EventBridge for recovery scheduling;
• Amazon CloudWatch and AWS X-Ray for privacy-safe metrics, traces, dashboards, and alarms;
• AWS Systems Manager Parameter Store for the application cost circuit; and
• AWS Amplify Hosting for the React PWA.

Sarvam Document AI performs schema-based extraction for Indian invoices. The Strands graph uses a model-provider adapter; the deployed team stack currently runs OpenAI through Strands because Bedrock model authorization was unavailable in our AWS account. CALL-E is the real-world phone-action layer. Amazon Bedrock AgentCore remains an optional deployment path in the repository, and we do not claim that it ran in this submission.

The public judge deployment uses the same domain workflow with deterministic fixture adapters. It requires no credentials, spends no provider credits, and cannot place a phone call. The video demonstrates the separate team environment exercising the real integrations with synthetic evidence and a consenting demo recipient.

Challenges we faced

Making retries safe

An HTTP timeout after a call submission does not prove that the call failed. Automatically retrying could ring the same person twice. ClaimPilot therefore writes an idempotency reservation before contacting CALL-E. An uncertain submission moves to SUBMISSION_UNKNOWN; workers may only read authoritative provider state for that reservation, never submit another call.

Separating reasoning from authority

A capable model can still be confidently wrong or influenced by instructions hidden in an uploaded document. We treated documents as evidence, never instructions, and kept disclosure rules, prohibited commitments, authorization checks, and dispatch gates outside the model.

Proving outcomes instead of trusting labels

A structured provider response claiming claim_registered is still only an assertion. ClaimPilot accepts a case reference only when normalized transcript text supports it. Unsupported results become NEEDS_HUMAN rather than a polished but unproven success screen.

Adding observability without leaking claim data

We needed correlation across API requests, agent runs, queues, and calls without putting invoices, transcripts, phone numbers, or prompt payloads in logs. Operational events therefore carry bounded labels, masked identifiers, and hashes; the full transcript remains tenant-scoped evidence visible to the owner.

Building around provider availability

Bedrock model authorization and AgentCore were unavailable in our account during the build. Instead of hiding that, the runtime exposes exactly which provider executed each node. Strands can route to the configured OpenAI fallback, and if no model is usable the workflow records deterministic rather than pretending an agent ran.

What we learned

The biggest lesson was that autonomy is not the same as authority. An agent can read, reason, prepare, reconcile, and verify without being allowed to authorize its own irreversible action.

We also learned that idempotency is not merely an API header. When a real-world side effect is involved, it must be a durable state transition written before the network request. Likewise, structured output is not automatically truth: important fields need evidence and authority checks after the provider returns them.

Finally, the cloud architecture is part of the agent's behavior. Cognito tenant boundaries, DynamoDB conditional writes, SQS retry semantics, EventBridge recovery, CloudWatch alarms, and the cost circuit determine whether the agent is safe to leave running.

Accomplishments we are proud of

• One end-to-end product rather than a collection of prompts.
• Explicit consent bound to a content hash.
• Transcript-backed verification of call outcomes.
• Tenant isolation across claims, documents, authorizations, tasks, and calls.
• Durable reconciliation that never treats uncertainty as permission to redial.
• A 30-case offline evaluation and adversarial coverage for prompt injection, stale consent, duplicate dispatch, fabricated references, unauthorized appointments, and false fee acceptance.
• A credential-free public demo plus a separately protected live integration stack.

What's next

Next we would add sourced warranty-policy snapshots for more manufacturers, improve semantic transcript matching while preserving evidence requirements, expand multilingual claim preparation, and activate Bedrock/AgentCore when account authorization is available.

ClaimPilot started with one annoying support call. It became our answer to a broader question: how can an agent do real work without asking people to surrender control?

Built With

• amazon-api-gateway
• amplify
• aws-lambda
• calle
• cloudwatch
• cognito
• dynamodb
• eventbridge
• fastapi
• openai
• pydantic
• python
• react
• s3
• sarvam
• sqs
• strands-agents
• typescript
• vite