Claims copilot
About this agent
A broker-side agent for tracking a claim's lifecycle, flagging SLA breaches, and drafting persuasive appeal letters when a carrier denies or delays a claim, drawing on firm-wide precedent captured in zenmem. It runs as four chained stages: a deterministic lifecycle tracker that alerts an advisor when a claim sits past its SLA window with no LLM involved; a dispute analysis stage that extracts rejection codes and cited clauses from a carrier's denial letter and cross-checks them against the client's own policy, pulled read-only from the firm's connected policy database; a precedent lookup against a shared, firm-wide pool of past winning appeal tactics; and an appeal generator that combines the client's policy context with those precedents into an appeal letter, an evidence-gap checklist, and an internal advisor brief, written inside one zenmem transaction so the appeal and its log entry commit or roll back together. Only the anonymized strategy text — never a client's name, policy number, or raw denial text — is promoted to that shared pool, and only once a dispute is actually won. It falls back to a conservative placeholder rather than crashing when an LLM's output can't be parsed as structured JSON, and it flags a denial extraction for human review rather than guessing when parsing fails outright. Document text extraction (plain text, PDF, or OCR) runs ahead of any zenmem call, since zenmem's callLLM is strictly text-in/text-out.
What changed with Zenmem?
The same agent, built twice against the same contract — once on Zenmem, once on MongoDB + LangChain/LangGraph.
Before → after
Before With Zenmem
What the team gained
- Winning appeal strategies live in one shared project scope, anonymised to carrier and tactic, so every advisor's next dispute starts from what the firm already won.
- One claim's dispute — the denial extraction, the coverage notes, the drafted appeal — is session-scoped and discarded on close, so a closed claim leaves no residue in the shared pool.
- The policy database is joined into the model call through a connected-database fetch, rather than exported into a second copy that drifts.
- Sharing tactics firm-wide while keeping each dispute private is a choice of scope, not two schemas and a redaction step.
- A new denial reason needs no new column, because the extraction is a document.
How memory is scoped
Two zenmem scopes plus a read-only connected-database link. `scope="session"`, keyed to the claim's dispute session id, holds the denial extraction, the coverage-check notes, and the generated appeal for one claim's active dispute — short-lived, and discarded once the dispute closes. `scope="project"`, with a fixed projectId of DISPUTE_TACTICS, is the one pool every claim at the firm reads and writes: winning appeal strategies, anonymised down to the carrier name and the tactic, shared across every client and advisor rather than partitioned per client. `fetchMemoryFromConnectedDB` against DB-POLICIES is a separate, read-through path to the firm's own policy records — never written back to.
How it works
The claim's path from submission to a resolved dispute.
Track the lifecycle
Claim status moves through submission, pre-authorisation, adjudication and settlement in a deterministic store — SLA math is arithmetic on timestamps, so no LLM is involved.
Extract the denial and check coverage
The denial letter is parsed into rejection codes, cited clauses and the carrier's argument, then cross-checked against the client's own policy clauses pulled from the connected database.
Search firm-wide precedent
The denial reason is matched against a shared pool of past winning appeal tactics from every client at the firm, not just this one.
Draft the appeal, atomically
The appeal letter, evidence-gap checklist and advisor brief are generated in one callLLM call and written inside a zenmem transaction.
Resolve and promote the win
Once the carrier responds, the outcome updates the claim's status, and — only if the dispute was reversed — the winning, anonymised strategy is promoted back into firm-wide memory.
What it does
Independently usable pieces, chained together by one orchestrator.
Capabilities
- submit_claim / run_sla_sweep — deterministic SLA-breach detection and advisor alerts, no LLM involved.
- open_dispute — marks a claim denied and opens its zenmem dispute session.
- extract_denial_details — parses a denial letter (text, PDF or OCR) into rejection codes, cited clauses and denial arguments.
- verify_policy_coverage — cross-checks the denial against the client's own policy clauses pulled from DB-POLICIES.
- find_precedents — searches the firm-wide DISPUTE_TACTICS pool for matching winning tactics.
- generate_appeal — drafts the appeal letter, evidence-gap checklist and advisor brief inside one atomic transaction.
- resolve_dispute — promotes the winning strategy to firm-wide memory and closes the dispute session.