Countersign

• 

  Agent can take action on behalf of Underwriters proposing exclusion clauses

Inspiration

I am working in insurance industry for 20 years and is one of the slowest moving industry when it comes to tech . Underwriting is still done the way it was 20 years ago: an underwriter alone in a tab, manually cross-referencing claims history, other policies, and disclosure forms that live in different systems. The risk factors that matter most — a second policy on the same address, a claim filed right before renewal, a "no prior claims" answer that doesn't match the file — aren't hard to catch, they're just easy to miss when you're moving fast through a queue of files. We wanted to see if WebMCP could let an AI agent sit inside that same case file, alongside the underwriter, and catch what a tired reviewer on their tenth file of the day might not. Not an agent that decides. One that notices, and says so.

What it does

Countersign is a shared underwriting workspace. The underwriter reviews a live policy application — applicant details, requested sum insured, policy terms. An AI agent, connected through WebMCP tools registered directly on the page, can read the same case data (claim history, other active policies) and propose changes: a risk flag, a premium loading, a change to the excess or an exclusion — each with a plain-language reason citing the specific data behind it.

Every proposal lands in a queue, clearly attributed to the agent, and does nothing to the actual policy until the underwriter accepts or rejects it. Nothing binds without a human. Every action — human or agent — is timestamped in an activity log, so the final policy comes with a defensible trail of who decided what, and why.

Working together. Underwriter and agent. AI reads your live underwriting case, catches what you'd miss — fraud patterns, over-insurance, non-disclosure. Proposes. Waits. Nothing binds without you.

How we built it

The app is a single-page React + Vite frontend, no backend — WebMCP tools run entirely client-side against in-memory state. We registered five tools via navigator.modelContext.registerTool:

• Two read-only tools — check_claim_history and check_other_policies — that return structured data plus computed signals like aggregate exposure across policies
• Three propose-only write tools — propose_risk_flag, propose_loading, propose_field_adjustment — that never mutate the policy record directly; they push into a pending-proposals queue that only a human accept/reject action can resolve

We modeled the mock case data around real underwriting fraud patterns rather than generic risk scores: claims frequency thresholds, sum-insured-vs-declared-value mismatches, and same-address aggregate exposure across multiple insurers.

We tested tool discovery and invocation in Chrome with the WebMCP flag enabled, then verified the full flow again through ChatGPT's desktop browser Site Tools before finalizing.

Challenges we ran into

Getting the human-in-the-loop boundary right took more iteration than the tools themselves — it was tempting to let "safe" proposals auto-apply, but any auto-apply path undermines the audit story that makes this credible for a regulated workflow, so we held the line at approval-gated everything.

We also hit the classic stale-closure bug with tool execute callbacks holding onto old state snapshots when the active applicant changed, which we fixed by reading current state through a ref instead of a captured value.

Getting WebMCP tool descriptions specific enough that the agent reliably called the right tool with the right applicant ID — rather than guessing or hallucinating case data — took several rounds of tightening the schema and description wording.

Accomplishments that we're proud of

We're proud that the propose-only architecture isn't just a safety feature bolted on — it's the actual product insight: an LLM in a regulated decision workflow shouldn't want authority, it should want to be legible. Every accepted or rejected proposal, plus the reasoning behind it, is captured automatically, which means the audit trail underwriting teams need for compliance falls out of the design instead of being built as an afterthought.

We also managed to build tools that reflect how underwriters actually think — loading vs. excess vs. exclusion as distinct levers, aggregate exposure as a first-class concept — rather than a generic "risk score" that wouldn't hold up to anyone with real domain knowledge.

What we learned

WebMCP's biggest value isn't letting an agent do more — it's letting an agent act inside a shared object both parties can see and trust, instead of narrating actions in a chat window disconnected from the real record. We also learned how much of "trust" in a human-AI collaboration tool comes from what the system refuses to do automatically, not what it can do.

On the technical side: closures over live app state are the easiest way to introduce subtle bugs when wiring WebMCP tools into a React app, and it's worth designing state access through refs from the start rather than retrofitting it.

What's next for Countersign

Near-term, we'd add a referral tier — when proposed changes cross an underwriter's authority limit (e.g. aggregate exposure above a threshold), Countersign would route them to a senior underwriter instead of a simple accept/reject, matching how real underwriting authority limits work.

We'd also like to make agent reasoning traceable at the data level — clicking a proposal highlights the exact claim or policy row it's citing, so nothing the agent says is a black box.

Longer-term, the same propose-and-approve pattern applies well beyond underwriting — claims adjudication, loan structuring, compliance review — anywhere a human needs to stay the final signature on a decision an AI can help inform but shouldn't make alone.

Built With

• and-makes-proposals-react-19-?-ui-and-state-management-via-usereducer-+-context;-all-state-is-client-side
• enabling-tool-registration-without-a-backend-mcp-b-chrome-extension-?-bridges-the-claude-agent-to-the-live-page's-registered-tools-claude-(anthropic)-?-the-ai-agent-that-calls-tools
• investigates-cases
• react
• router
• tailwind
• webmcp