LifeCast

Life insurance, explained in a conversation the AI talks you through it, an authoritative calculator does the math, and you can always ask why.

Comment

LifeCast Life Insurance, Explained in a Conversation

The story

Most people don't avoid life insurance because they don't care. They avoid it because the moment they start, they hit a wall of jargon, forms, and a single intimidating number with no explanation behind it. "You need $925,000." Why? Based on what? What happens if we have another kid, or pay off the house, or I switch jobs and lose my work coverage? The tools that are supposed to help end up making people feel more anxious and less in control.

We kept coming back to one image: a young family at the kitchen table, trying to figure out if they're protected, and quietly giving up because the process feels like it was built for insurance professionals, not for them.

That's the gap we set out to close with LifeCast.

The problem we chose codeLinc 11, Path 2

We chose Path 2: the Life Insurance Needs Analyzer. Lincoln Financial's challenge asked us to:

  1. Build a conversational AI tool that walks a user through their situation dependents, income, debts, and existing coverage.
  2. Produce a personalized needs assessment with a clear explanation of the reasoning behind it.
  3. Communicate the math clearly, without triggering anxiety or confusion.

The stretch goal: explain the difference between term and whole life insurance and surface the specific tradeoffs that apply to the user's own scenario.

The hard part of Path 2 isn't the arithmetic it's trust. An AI that confidently makes up a dollar figure is worse than no tool at all. So we treated the real challenge as: how do you make a needs assessment that a brand-new user can understand, interrogate, and believe?

How LifeCast solves it

LifeCast turns the whole experience into a conversation, backed by an authoritative calculation.

You talk; it listens. A new user can open LifeCast and ask anything "What is life insurance?", "What's the difference between term and whole life?", "How does this even work?" before sharing a single number. They can type, or use continuous voice mode: press start once, speak naturally, and LifeCast replies out loud and keeps the conversation going until they press stop. No forms. The conversation is the questionnaire.

It gathers what matters, naturally. Through the conversation, LifeCast collects the Path 2 inputs dependents, income, debts, and existing coverage without a rigid wizard. When it has enough, it runs the needs assessment.

The AI never does the math. This is the heart of what makes LifeCast trustworthy. The actual coverage calculation is run by CalcXML's Ins01 engine the same calculator methodology behind Lincoln's own public calculator experience. The AI's job is only to explain the result the calculator returns. It cannot invent or alter a number.

Every number is explainable. Instead of one opaque figure, the modeled need is shown as layers immediate cash needs, long-term income replacement, and the resources you already have each traceable to the calculator's own output. The result is presented as a plain equation: what your family would need − what you already have = your coverage gap.

You can fork your future. LifeCast's "Future Fork" lets you drop life events onto a timeline another child, a paid-off mortgage, lost employer coverage and it recalculates the scenario through the same authoritative calculator, then explains exactly what changed and why. Future A and Future B sit side by side.

It respects the user. LifeCast never recommends a product. For the stretch goal, it explains term vs. permanent as tradeoffs tied to the user's situation not a sales pitch. And when the calculator is unavailable, it says so, rather than substituting a fake estimate.

Vision and mission

Our mission: make life insurance understandable to the person who needs it most the one who has never thought about it before without ever misleading them.

Our vision: financial clarity that behaves responsibly. A tool where the AI makes hard concepts approachable, an authoritative engine owns every dollar figure, and the user can always ask "why?" and get a real answer. Technology that earns trust by being transparent about what it knows, what it assumes, and what it cannot promise.

Technical architecture

LifeCast is built on one guiding principle:

The calculator calculates. The AI explains. These never cross.

The system is organized as "three brains":

  1. Knowledge (Amazon Bedrock) A conversational guide, grounded in Lincoln's plain-language framing plus broad life-insurance knowledge, that answers any question a newcomer might have at any point in the flow.
  2. The Calculator (CalcXML Ins01) The authoritative needs-assessment engine. Bedrock calls it as a tool via function-calling and reports only what it returns. It is never asked to do the arithmetic itself.
  3. Memory (the user profile) The structured household the agent builds and carries forward, so follow-ups like "we just had another baby" update only what changed and recalculate.

The data flow:

User (type or voice)
      │
      ▼
Amazon Bedrock  -- conversational intake, Q&A, scenario extraction
      │  (tool call: calculate_life_insurance_need)
      ▼
CalcXML Ins01 REST API  -- authoritative coverage calculation
      │  (returns immediate needs, long-term needs, resources, gap)
      ▼
Amazon Bedrock  -- explains the returned numbers in plain language
      │
      ▼
LifeCast UI  -- layered result, Future Fork, term-vs-permanent, report
      │
      ▼
Amazon Polly -- reads explanations aloud for the voice conversation

The frontend is a React single-page app with a landing page and a five-tab planning workspace (Introduction, Financial Planning, Life Events, Review & Plan, Report). A same-origin Node backend is the only place that talks to the cloud services; AWS credentials and licensed calculator credentials stay server-side and are never exposed to the browser. Scenario timelines are clearly labeled as a separate illustrative projection, distinct from the authoritative current-household assessment.

Everything is backed by tests unit tests for the calculator mapping and finance formulas, integration tests against the live services, and browser end-to-end tests for the full conversation-to-result flow, Future Fork recalculation, and the continuous voice lifecycle (start, two spoken turns, auto-resume after each reply, and an explicit stop).

AWS services used

Amazon Bedrock (amazon.nova-lite-v1:0, Converse API with tool use) the conversational brain: intake, open-ended Q&A, scenario extraction, and plain-language explanation of the calculator's results. It orchestrates the calculator tool but never computes insurance figures itself. Amazon Polly (neural voice, with viseme/speech-mark timing) reads explanations and intake questions aloud, powering the hands-free continuous voice conversation. AWS Lambda + API Gateway the hosted backend. The HTTP API routes /api/* to the Lambda handler, with request throttling and bounded handling for the public demo. AWS Amplify hosts the production web build and rewrites same-origin requests to the API. AWS SDK credential chain + IAM execution role Bedrock and Polly authenticate via the execution role in production and the standard credential chain locally; no access keys live in the frontend.

Alongside AWS, the needs calculation is powered by the CalcXML Ins01 REST API, the calculator engine behind Lincoln's public calculator experience, integrated directly so our results align with a trusted, established methodology rather than one we invented.

What we learned

Trust is the product. The most important engineering decision wasn't a feature it was the rule that the AI never does the math. Separating calculation from explanation is what lets us say "ask why" and always have a defensible answer. "Train the AI on the calculator" usually means give it tools, not fine-tune it. We learned to let Bedrock call a deterministic calculator through function-calling and ground its language in retrieved knowledge, rather than hoping a model would produce correct figures. Don't reinvent a methodology you can borrow authoritatively. Our early homegrown formula didn't match what a user could verify. Connecting directly to CalcXML's Ins01 engine the same methodology behind Lincoln's own tools made the numbers both accurate and verifiable. Fail loudly, never fabricate. When a provider is unavailable, surfacing the error is more responsible than quietly substituting a different estimate. We removed every silent fallback from the calculation path. Voice is a state machine, not a button. A natural, continuous conversation meant handling the browser's recognition lifecycle carefully restarting after each pause, pausing while the assistant speaks so it doesn't hear itself, and stopping only when the user asks. Testing an AI app means testing the seams. The valuable tests were the ones that exercised the real services and the real browser flows, not just the pure functions.

Built With

Share this project:

Updates

Submission history