Kai, the AI coach inside Livio

The problem

Livio is a subscription app for people losing weight in the United States. The founders wanted the coach to be the product: not a chatbot bolted onto a tracker, but the thing you open, talk to, and trust with your numbers. A coach that forgets you, invents your calorie count or changes your plan without asking is worse than no coach.

The first version proved the idea and showed its limits: pages of vanilla JavaScript inside a Flutter app, a backend that had grown by accretion, and an AI layer that could not be measured. I was brought in to lead the rebuild.

What I built

Version 2, from the ground up: the Python backend, the agent, the web app that renders inside the Flutter shell, and the native health integrations. It went live on both stores.

• The agent loop: a streaming Claude agent that decides which of 30+ tools to call to read and update food, weight, sleep and workout data, with every proposed change confirmed by the member in one tap.
• Numbers are computed in code, never by the model. Calories, macros and trends come from functions; Kai explains them.
• Memory: facts extracted from past conversations, a coaching profile that updates daily, and retrieval over a health-document library, so the coach sounds like it knows you because it does.
• Evals that decide what ships: golden datasets plus a blind LLM-as-judge test of coaching quality. They stopped a switch to a cheaper model that scored worse.
• Cost controls: simple requests routed to a small model, prompt caching, and failover between AWS Bedrock and the Anthropic API.
• The Flutter shell around a web app, so the team ships features any day without waiting on store review.
• Native work in Swift and Kotlin: Apple Health and Health Connect sync, a camera-based vital-signs scan, and food logging by photo, voice and barcode.
• The revenue path: subscriptions and free trials on StoreKit and Play Billing, store submissions, over-the-air patches.

Decisions that mattered

• Human confirmation on every write. It costs one tap and removes the whole category of "the AI changed my plan" complaints.
• Measure before switching models. The eval harness exists because a cheaper model looked fine in a demo and was worse in a blind test.
• Shell plus web app over pure native screens. The product changes weekly; store review does not.
• Two providers from day one. An outage on one is a slow afternoon, not a dead product.

How the team works

I run sprint planning and code reviews for four engineers and work directly with the US founders on the roadmap. AI coding agents are part of the team's daily workflow, with the same review bar as any other change.