Back to all work

02 / Case study

Redline Coach

An AI running coach I built to plan and adjust my training, from Messenger.

Role
System design, AI engineering and product design
Status
Personal system · In daily use
Platform
Messaging / Automation / Data
Year
2026 / Now
Tools
Python / PostgreSQL / Claude / Codex / Strava / Messenger
Redline Coach, An AI running coach I built to plan and adjust my training, from Messenger.
Redline CoachSystem design, AI engineering and product design

Overview

Redline reads my runs from Strava, plans my training weeks and sends everything to Messenger. I built everything around the model: what it reads, what it may change, and how I check that it is right.

Dailyreal use since July 2026
1,500+automated tests
40evaluation scenarios
113sources in its knowledge base

Inside the project

AI where it helps, code where it has to be right

The interface was already in my pocket

I did not want another dashboard to remember to open. The coach writes first: a morning note, a debrief once Strava has synced, a review every Sunday, and I reply in a few words. It stays a training tool: it keeps the logbook and the plan, and replaces neither a coach, nor a doctor, nor the people around me.

Debrief after a quality session

Debrief after a quality session

The morning of a strength session

The morning of a strength session

Monthly review

Monthly review

Cards rendered by Redline from synthetic data.

The model proposes, the code decides

The model writes the reply and proposes changes: a logged run, a revised week. Code applies those changes in a single transaction, or none of them, then refuses to prescribe from a plan that is invalid or out of date. The programme I receive is rendered from the database, never copied from the model’s prose.

  1. 01 · InputA message or a runFrom Messenger or Strava. Saved before anything else, so a crash loses nothing.
  2. 02 · ModelTriageA small model picks one of four levels.
  3. 03 · ModelThe coachReads what its level allows, writes the reply and proposes typed changes.
  4. 04 · CodeAll or nothingThe changes are applied in one transaction, or none are.
  5. 05 · CodeChecksNo valid, up-to-date plan, no prescription. The reply still goes out.
  6. 06 · CodeDeliveryThe programme is rendered from the database, and every message is journaled.

The right model for each message

A thank-you does not need the same model as a question about pain. Each message is sorted into one of four levels, which sets what the coach reads and which model answers. Claude and Codex sit behind the same interface, so switching provider is a single setting.

Level
A judgement
Model
Sonnet, more effort

What the coach reads

  1. A one-page summary of the current state
  2. This week’s plan and the facts of the day
  3. The rules and notes behind the decision
  4. The sources themselves, and the web if they don’t settle it

Triage itself runs on the smallest model. If it fails or takes more than 10 seconds, the message is treated as routine.

Example messages. The routing shown is the Claude configuration in use today.

Facts are not reasoning

What happened and what is planned lives in PostgreSQL: typed, constrained, never overwritten. The why lives in versioned notes I can read and argue with. Each fact has one owner, and anything that can be recalculated is never stored, so two versions of the truth cannot drift apart.

PostgreSQLFacts

What happened, and what is planned. Typed, constrained, immutable once known.

  • Runs, effort and pain scores
  • Weekly plans, as revisions that never overwrite
  • Deadlines and open questions
Versioned notes · GitReasoning

Why it was decided. Readable, versioned, challenged every month.

  • Goals and coaching rules
  • Decisions, each with a dated prediction
  • 37 concepts built from 113 sources

Form, trends and weekly load are recalculated from both, never stored.

A library it has actually read

The coach’s knowledge comes from 73 podcast transcripts and a systematic search of the medical literature, turned into 113 source notes and 37 concepts. A claim keeps its level of evidence wherever it is quoted, and an automatic check flags known claims that lose it on the way.

Measure, correct, replay

When I correct the coach, the mistake is logged with what it should have read, and the fix gets a carrier. An evaluation bench replays 40 scenarios against the real models, with a model acting as judge, kept out of the live conversation. Decisions carry a dated prediction, so a wrong call shows up instead of fading away.

Correction · 2 August 2026

“2224.5 km, clean week, well done.”

22 was the planned volume: an intention quoted as a fact. The run log already said 24.5 km.

What now carries the fix

Rule
A number is calculated, never quoted. Planned and done are labelled when named together.
Code
One single calculation of weekly volume, shared by every tool.
Test
A bench scenario asks the same question on every run.
  1. scenarioweekly-volume-is-computed
  2. questionWhat was my mileage last week?
  3. log30.18 km over 4 runs · plan target ~28 km
  4. expected30.2 km over 4 runs.
  5. checkThe number given is 30.2 km, not 28
  6. checkNo invented memory, calculation or tool
  7. Judged on every bench run, against the real models

All Redline visuals use synthetic data.

Next project

ÖKO Counter