Inspiration
Dental plans are written in insurance language: deductibles, coinsurance, annual maximums, networks. Most people can't turn that into a dollar figure for a crown or braces. So they overpay, skip care, or let their benefits expire when the plan year resets on January 1. For codeLinc 11 (Lincoln Financial, Path 1), we wanted to answer the question people actually have, "what will this cost me, and when should I do it?", in the place they already spend their day: their messages.
What it does
Floss is a dental benefits assistant for employees, on WhatsApp and in a web app. The employee's plan is already on file, so they just ask:
- What a procedure costs them: in-network vs out-of-network, with the hospitals near them
- What their plan covers: annual and orthodontic maximums, family coverage, member numbers
- When to get care: warnings when a treatment would hit the annual maximum, and reminders before unused benefits reset on January 1
Answers come only from that member's own records. Follow-ups like "and for my son?" keep their context, and every chat is saved. On WhatsApp, Floss introduces itself and answers registered members from their plan data. For anyone else, it falls back to general dental information without inventing personal prices.
How we built it
- Web app: React 19, Vite, TypeScript and Tailwind, hosted on S3 and CloudFront, with Amazon Cognito sign-in (phone number and password).
- API: a versioned
/v1REST API on API Gateway, with a JWT authorizer and request and response shapes defined as zod schemas shared with the frontend. - RAG engine: Postgres on RDS with pgvector holds treatment estimates, hospitals, dental costs, users and chat history. Questions are embedded with Amazon Titan Text Embeddings v2 and matched only against the caller's own rows.
- Two-step answers on Amazon Bedrock: Claude Haiku first picks the person, the treatment and what they want. Code then does all the math: plan share, the orthodontic lifetime limit, annual maximum warnings. Finally a second call writes a warm, plain-English reply from those facts.
- Guardrails: every dollar figure, email, phone number and link in a reply must match the data, or the reply is rewritten.
- WhatsApp: Twilio sends messages to an AWS Lambda function with a permanent URL. It checks Twilio's signature, replies instantly, then answers in the background so Twilio's 15-second limit never matters. Members are answered by the RAG engine; everyone else by Amazon Nova Lite on Bedrock. History is stored in DynamoDB, and Bedrock access uses IAM roles rather than stored keys.
Challenges we ran into
- Messaging rules are strict. Twilio's trial blocks custom messages. US carriers block unregistered numbers, which requires A2P 10DLC or toll-free verification. Meta locks WhatsApp business numbers until the business is verified. We demo on the Twilio WhatsApp Sandbox while SMS verification is pending.
- Hackathon Wi-Fi blocked ports, including Postgres's 5432 and Cloudflare Tunnel. We moved the database to port 8443 and used SSH-over-443 tunnels until we deployed to AWS.
- Account limits. Bedrock was blocked in our first AWS account, and the workshop account denied S3 Vectors, so we rebuilt in a new account and used pgvector instead.
- Lambda freezes as soon as it responds, which ended our background-thread approach. The bot now hands each answer to a second, asynchronous run of the same Lambda.
- Keeping AI honest about money. Models love to do arithmetic. We moved every calculation into code and made the model only phrase the results.
Accomplishments that we're proud of
- An end-to-end live system: web app, API, database, RAG and WhatsApp, all on AWS.
- Personal answers from each member's own data. One member can never see another member's rows.
- A guardrail that won't let Floss state a price that isn't in the data.
- No app to install: an employee can get their plan explained in a WhatsApp chat.
- Handling a real plan's quirks, such as the separate lifetime orthodontic maximum for children, and nudging people before January 1 so benefits aren't lost.
What we learned
- Getting the right data into the model matters more than clever prompting. Retrieval plus math done in code beats asking the model to reason about money.
- For phone channels, compliance (carrier registration, WhatsApp templates, Meta verification) is as much work as the code. Start it on day one.
- Serverless needs serverless patterns: async invocation, IAM roles instead of keys, and permanent URLs instead of tunnels.
- Clear docs and pull requests let four people build different parts in parallel without breaking
main.
What's next for Floss AI
- Plain SMS once toll-free verification is approved, so Floss works on any phone, even without mobile data.
- Claims data to show exactly how much of the annual maximum each family member has used and has left.
- Scheduled reminders in October through December, using approved WhatsApp templates.
- One WhatsApp path through the signed Twilio route on the main API, so WhatsApp chats show up under WhatsApp in the web app's history.
- More plans and languages: all five carriers' plans, multilingual questions, emailed transcripts, and network re-verification when a dentist leaves the network.
Built With
- amazon-api-gateway
- amazon-bedrock
- amazon-cloudfront
- amazon-cognito
- amazon-dynamodb
- amazon-rds-relational-database-service
- aws-lambda
- pgvector
- postgresql
- python
- react
- tailwind-css
- twilio
- typescript
Log in or sign up for Devpost to join the conversation.