AI Assistant (Concept)

Where it came from

This started right after the Dependent Invite flow. Members had quick, low-stakes health questions — what does this term mean?, is this normal?, what should I do next? — but no lightweight place to ask them inside Loop. Doctor on Demand and support were the right paths for high-intent care. They were the wrong default for curiosity and clarification.

The idea was an AI assistant for exactly those moments. Loop didn't have AI-driven consults on the roadmap, so there was no mandate to build it. I decided to build it anyway — end to end — to find out if it could actually work.

What I set out to prove

I usually design and prototype in SwiftUI. This time I wanted to own the whole thing, including the part I'd never touched: the backend.

So this became my first backend + AI project. I wrote the service and integrated xAI (Grok) for the model. I started with a local backend folder to get the conversation loop working on my machine, then deployed it to Vercel and pointed the Loop app at it — a real assistant answering real questions inside the app, not a mocked prototype.

Grounding it in real care

An assistant that makes things up is worse than no assistant — in health, a bad AI moment isn't a quirky typo, it's a trust failure. Two things kept it honest:

• The questions come from Loop's real doctor list — the actual things members ask care teams, not invented prompts.
• I borrowed a protocol doc from the backend engineering team, who were building a separate AI, so responses followed a structure that matched how Loop thinks about clinical answers.

The design work

Progressive depth

A short, useful answer first. Detail on demand. A clear next step when the query needs a person — not one chat template for everything.

Conversation states

Loading, partial results, cited answers, empty or low-confidence responses, and error recovery each get distinct treatment. Members should never wonder if the app froze or if the AI is guessing. When we can show sources, we do. When we can't answer safely, the UI says so plainly.

Escalation as a first-class outcome

Booking a doctor, opening support, or continuing with a human care path are designed as clearly as the answer itself — not buried behind a generic contact link. The assistant is a front door, not a product island.

SwiftUI on device

I prototyped the conversation UI in SwiftUI to test what static frames couldn't: keyboard overlap, scroll with long answers, transition into Doctor on Demand, and how fast the UI had to respond so it felt like Loop — not a web view stapled onto the app.

Why it's not live

AI consults still aren't on Loop's roadmap, so I shelved it. It was never going to ship, and that was clear going in.

I'm posting it anyway because it's the project where I stopped waiting for a mandate. I took an idea from design through a backend I'd never written before, integrated an LLM for the first time, and got a working assistant running inside a real app. The outcome I care about here isn't a launch metric — it's that I can now build the thing, not just design it.

What I learned

Build the thing to know if it's real

A working backend answering real questions told me more in a few evenings than any spec review could. The demo was the argument.

States are trust in healthcare AI

Low-confidence, loading, and partial answers need explicit design — ambiguity reads as guessing with your health data.

Design through to the backend

Owning the service, the model integration, and the deploy — not just the screens — changed what I could propose. I don't have to hand off the risky part anymore.

Tools

• 

  SwiftUI — conversation UI, states, and on-device prototyping

• xAI (Grok) — the LLM powering the assistant's answers

• Vercel — hosting for the backend service I wrote

• 

  Figma — flow mapping and conversation UI specs