A concept I've been carrying for two decades — that AI finally made possible to build.

I've worked on some version of this idea for twenty years — at Nike, at Adidas building miCoach, at startups. Every attempt hit the same wall: real runner data is messy. Skipped days, self-reported paces, missing weeks, inconsistent devices, a marathon PR from ten years ago with no context. The old architectures couldn't use any of that. They needed clean inputs. Runners don't have clean inputs.

Modern language models change the math. They accept messy, partial, natural-language input and produce useful output. They're also finally good enough at holding context and following training principles that a serious runner would take them seriously.

That's the unlock. A prototype that would have taken a team of five and a research budget a decade ago is now something one product person can build in evenings.

The core data structure isn't a training plan. It's a runner context — a structured record of who you are as a runner right now. Past races. Current mileage. Recent workouts. Injuries. What you're training for. How you're feeling. Where you broke last time.

The AI companion reads this context on every message and writes back to it after every conversation. Every plan generation, every adjustment, every readiness score derives from the same context. It's the single source of truth for the runner-app relationship.

Two properties of the context matter most:

• •Editable by both sides. The AI updates it as it learns about you. You can also edit it directly in the dashboard — the plan reflows the moment you do.
• •Structured but forgiving. It has a schema, so tools can act on it deterministically. But it accepts partial and messy input, so onboarding doesn't feel like filling out a tax form.

The first prototype had the AI do everything — hold the conversation, update the context, generate a 56-week training plan, all in one streaming response. It worked for a two-week starter plan. It fell apart at scale.

A full training plan is mostly deterministic: phases follow a structure, mileage progresses according to rules, workouts slot into days based on constraints. Asking a language model to regenerate that as JSON is like asking someone to recite a phone book while having a conversation. Slow, error-prone, and the wrong use of intelligence.

The current architecture splits the work:

• •The AI handles conversation, context-building, coaching decisions, communication. This is where intelligence matters.
• •A plan engine — a plain TypeScript function — handles plan generation. Fourteen phases, workout constraints, mileage progression, all encoded as data. Milliseconds to run.
• •Claude's tool use is the bridge. Mid-conversation, the AI can call generate_training_plan with its coaching decisions, get a full plan back instantly, and continue the conversation knowing what was built.

That separation is what makes the living plan possible. Change one thing — a moved long run, a missed week — and the engine rebuilds the whole 56-week map with the ripple effect visible everywhere: sub-three probability updates, injury risk adjusts, phase transitions shift. If the AI had to regenerate the plan from scratch every time, the experience would be unusable.

The context-plus-tools shape is deliberately extensible. Every new capability becomes another tool the AI can call without complicating the core conversation:

• •Data ingestion. Sync with Strava, Garmin, Apple Health so the context updates from actual miles run rather than self-report.
• •Multi-model orchestration. Different tasks call for different models. A cheap fast model handles casual chat and status updates. A larger model handles plan reasoning and race-day analysis. The router lives above the tools — the conversation doesn't change.
• •Specialist skills. A nutrition tool. A shoe-rotation tool. A race-day pacing strategy tool. Each is its own scoped intelligence with the context to be useful.

Next.js 16 app deployed on Vercel. React 19 on the front end, server routes for the API layer. Claude Sonnet 4.6 handles the reasoning and tool orchestration. Supabase for auth and persistence — the runner context and training plans live in Postgres with per-user row-level security. All in one codebase, one deploy, no separate backend service.

Zoom out and this is what we're building toward: an architecture that uses the right AI model for the right moment, the right skill for each action, and keeps one source of truth about the runner underneath it all. Today, one general-purpose model handles every job. Tomorrow, specialists — because the fastest, sharpest experience comes from picking the right brain for the task, not asking one brain to do everything.