Verity

Inspiration

AI claims automation is not speculative. Lemonade approves and pays some claims via AI in about two seconds, with roughly 30 to 40 percent of claims now touchless. Tractable's computer-vision damage assessment runs at about 95 percent accuracy. Shift Technology catches over five billion dollars a year in claims fraud using AI. Insurance fraud costs the United States an estimated 308.6 billion dollars a year (Coalition Against Insurance Fraud), with 10 to 20 percent of all claims estimated fraudulent. Regulators are responding directly: the NAIC Model Bulletin on the Use of AI by Insurers, now in force in more than 24 states, requires insurers to maintain a documented AI governance program whose outputs can be explained in plain terms, not just to the engineers who built the system.

Most "AI agent with memory" projects treat memory as retrieval: embed something, look up similar things, hand it to a model. That solves one problem and ignores two others that actually break in production. First, once more than one agent is working at once, they race for the same task, and a simple retrieval layer has no way to guarantee two agents never grab the same case. Second, a regulator or an auditor will eventually ask what the system knew at the exact moment it made a specific decision, and a system that only stores "the current state" cannot answer that honestly once the data has changed.

Verity exists to demonstrate that a persistent, provable memory layer can solve both problems at once.

What it does

Verity is a fleet of autonomous AI agents that process insurance claims end to end:

• Claims are submitted with a policy number, description, and amount, and immediately embedded into a distributed vector index for semantic search.
• Any number of agent workers can pull from a shared pending-claims queue at once. Exactly one of them ever claims a given case, proven under real concurrent load, not assumed.
• Before deciding, an agent gathers grounded context: the policy's actual coverage and deductible, the claimant's own history, and semantically similar historical claims, then calls an LLM (Claude, via Amazon Bedrock) to approve, deny, or flag the claim.
• Approved claims generate a payout that the database itself guarantees can never happen twice for the same claim, a schema-level constraint, not application logic that could have a bug.
• Flagged claims go to a human reviewer. Nothing pays out on a flagged case without an explicit human decision.
• Any past decision can be replayed: Verity reconstructs the exact historical database state the agent read at decision time, and shows it side by side with the current state, so you can prove exactly what the agent knew and when, even after the underlying data has changed.
• The dashboard can also trigger a decision on demand: submit a claim, click "Run agent now," and watch it gather context, call the model, and decide, live.
• A separate capability, Fraud Ring Buster, finds claims that look unremarkable one at a time but are connected through shared identity attributes (a bank account, an address) across different claimant names, including cases where the connection is indirect, through a bridging claim two hops away.
• The whole system is deployed and publicly reachable, not a local demo.

How I built it

Backend: Python, FastAPI running identically locally and on AWS Lambda, psycopg3 against CockroachDB, Amazon Bedrock for both generation (Claude) and embeddings (Titan Text Embed v2).

Frontend: React 19, TypeScript, Vite, Tailwind CSS v4, a custom-designed dashboard built from scratch, deployed as a static site behind CloudFront.

Infrastructure: AWS SAM and CloudFormation for the backend, GitHub Actions for CI, an OIDC-federated IAM role so no long-lived AWS credentials live in CI.

The core technical decisions all trace back to two problems most "AI agent" demos don't actually solve: concurrency and provable memory. CockroachDB was chosen specifically because it makes both structural rather than something the application has to get right in code: every transaction is serializable by default (so the "exactly one agent claims this case" guarantee doesn't depend on a developer remembering to set an isolation level), and its native point-in-time query capability (reading the database as it existed at an exact past moment) makes the replay feature a real reconstruction of history, not a best-effort snapshot that could be stale or forged. Fraud ring detection is implemented as a Union-Find (disjoint-set) graph computation over shared-attribute edges between claims, run as ordinary SQL against the same store, so a claim connected only indirectly (through a bridging claim) still correctly lands in the same ring, something a single-claim-at-a-time model cannot see.

Challenges I ran into

Nearly every subsystem here had a real bug that only surfaced by running it against live infrastructure, not by reading documentation:

• The LLM's model entitlement never activated despite an accepted marketplace agreement, a known rollout delay; switched to a different inference profile as a workaround.
• Mixing a point-in-time historical read with a plain current-time read inside one database transaction raises a feature error; fixed by pinning the historical read's timestamp as the transaction's leading statement instead of inlining it into each query.
• A cloud provisioning CLI had a narrower command surface than its own public reference documentation described; all provisioning scripts were rewritten against the CLI's actual, verified behavior instead of the docs.
• A circular dependency between a storage bucket and the function it triggers has no clean declarative solution in our infrastructure-as-code tool; resolved with an explicit permission grant using a computed ARN, plus a small post-deploy script that wires the actual event notification outside the tool's dependency graph.
• A fresh cloud account's Lambda concurrency floor made any positive reserved-concurrency value mathematically invalid on that account. Removed it entirely: the real concurrency-safety guarantee lives in the database's serializable isolation, not in a compute-layer setting.
• Granting model-invoke permission on a cross-region inference profile's own identifier was not enough: the cloud provider's access check for that profile evaluates against a different, underlying resource identifier with part of the name stripped, a behavior visible only in the live access-denied error, not in any documentation consulted beforehand.
• An uncaught exception in a serverless function behind an API gateway returns a generic error page with no CORS headers, which the browser reports as a CORS failure, completely masking the real error underneath. The actual cause was a database retention window: replaying a decision older than the retention period correctly fails, just not with an error message that says so.

Accomplishments that I'm proud of

The concurrency guarantee, the payout-uniqueness constraint, and a full multi-region node-failure survivability drill are proven with real tests and real, captured output, not just asserted in a README. Fraud Ring Buster's transitive graph detection, catching a claim connected only through a bridging record two hops away, is, as far as we could verify against comparable projects, a genuinely uncommon capability in this space. And the entire system is a real, live, publicly reachable deployment: every claim, decision, and fraud ring shown in the demo is a real record in a real database, not scripted or hardcoded.

What I learned

That an agentic memory layer's hardest problems are not retrieval problems. They are concurrency problems (many agents, one queue, zero double-claims), correctness problems (a financial action that must never duplicate), and accountability problems (proving what a system knew after the fact, honestly, once the data has moved on). A database with strong distributed transactional guarantees and a native point-in-time query primitive maps directly onto those three problems in a way that bolting a vector store onto an ordinary database does not.

What's next

Extending document ingestion to structured extraction from real claim attachments (photos, PDFs) rather than plain text, combining the exact-match fraud-ring signal with the existing semantic-similarity signal into a single, calibrated risk score once there's a larger real claims corpus to tune it against, and deploying the validated multi-region design to production infrastructure for real regional-outage survivability.

Built With

• amazon-api-gateway
• amazon-cloudfront
• amazon-titan
• amazon-web-services
• anthropic
• aws-bedrock
• aws-cloudformation
• aws-eventbridge
• aws-iam
• aws-lambda
• aws-sam
• claude
• cockroachdb
• d3.js
• fastapi
• github-actions
• mangum
• playwright
• psycopg3
• pytest
• python
• react
• tailwind-css
• typescript
• vite