Smart Insurance Planner

Inspiration

When you get insurance through work, you get a plan and... that's it. Nobody tells you which doctor to go to when you're sick. Should you go to urgent care? Your regular doctor? Just do a video call? When the time for renewal your plan, you're not sure which plan would be good for your situation.

What it does

Smart Insurance Planner is a agent that helps you use your health insurance the smart way:

1. "I feel sick, what do I do?" — Tell it your symptom, and it looks at your actual insurance plan and recommends where to go (PCP, urgent care, telehealth, or ER), plus how much it'll roughly cost — based on your real deductible and copay numbers, not generic advice.
2. "Does my plan cover X?" — Ask it a direct question about your coverage, and it searches your real plan document to answer.
3. "Should I switch plans next year?" — At renewal time, it looks back at everywhere you went and what it cost, and tells you if a different plan would save you money. ## How we built it

• The "brain" is Claude (Anthropic's AI), which reads your question, decides what info it needs, and calls tools to get it — that's the agentic part.
• All your data — your plan details, your visit history — lives in CockroachDB, and the agent talks to it through CockroachDB's Managed MCP Server instead of connecting directly. This keeps things safe and standardized.
• Your insurance plan's benefits document (the long legal-sounding PDF) gets broken into small chunks and turned into "embeddings" — basically numbers that represent meaning — and stored in CockroachDB's vector search feature. So when you ask "does this cover physical therapy," the agent searches the actual document text instead of us hardcoding rules.
• Embeddings are made using Amazon Bedrock (Titan model).

• The whole thing runs on AWS Lambda — no server sitting around, it just wakes up when someone uses it.

  Challenges we ran into

• Figuring out MCP. The MCP server's tools aren't really documented for code that isn't an IDE like Claude Code or Cursor — we had to connect to it live and poke around just to figure out what arguments each tool actually needed.

• No parameter binding. Normally with a database, you can safely plug in values without typing them directly into your SQL. This MCP server doesn't support that — every value had to be written straight into the query text. That got tricky with our vector data (a list of 1024 numbers!) since it made our queries too long and hit a size limit — we had to shrink the numbers first.

• Collisions between tools. Since the agent can call multiple tools (database lookups, vector search, etc.) in one conversation, we had to be careful about ordering and making sure one tool call's result didn't clash with another mid-flow.

• Lambda timeouts. Our normal setup (API Gateway) cuts off requests after 30 seconds, but our renewal feature sometimes needs longer to think through everything. We switched to a Lambda Function URL instead, which doesn't have that limit.

  Accomplishments that we're proud of

• Built a working RAG (retrieval-augmented generation) pipeline — meaning the agent's answers are actually grounded in your real plan document, not made up — all inside CockroachDB, without needing a separate vector database.

• Got structured data (your plan, your visits) and unstructured data (document text) working together smoothly through one system.

• Made an agent that genuinely needs memory to work — without remembering your plan and your visit history, it literally couldn't do its job.

  What we learned

• How to connect an AI agent to a database safely through MCP, and the real-world quirks that come with it (missing docs, no parameter binding, query size limits).

• How to avoid "collisions" when an agent calls several tools back to back — making sure the right data gets used at the right step, and one tool call doesn't overwrite or conflict with another.

• CockroachDB's vector search uses syntax similar to pgvector, so if you've used pgvector before, it's a pretty quick jump.

  What's next for Smart Insurance Planner

• Real-time facility search. Right now we don't look up actual nearby clinics — next step is adding web search so the agent can find real urgent care or clinic locations near you, not just tell you the type of place to go.

• Direct insurance website connection. Right now we use uploaded plan documents — next step is connecting directly to insurance providers' websites so plan data stays live and up to date, instead of needing manual updates.

Built With

• amazon-web-services
• bedrock
• cockroachdb
• lambda
• mcp