Mein KI-Laufcoach ist ein Git-Repository und ein Claude-Agent

Ich beende meine Einheit. Meine Uhr synchronisiert sich von allein mit Strava, wie immer. Ich gehe duschen.

Bis ich wieder draußen bin, sind drei Dinge passiert, ohne dass ich irgendetwas angefasst hätte. Die Analyse der Einheit steht in meinem Trainings-Repository. Die Woche ist angepasst worden, mit dem Grund für die Änderung daneben notiert. Und unter der Strava-Aktivität steht ein Kommentar von meinem Coach, der mir sagt, was die Einheit wert war und was sie für Freitag ändert.

Dieser Coach ist keine Anwendung, die ich gebaut habe. Er ist ein Git-Repository voller Markdown-Dateien, ein Claude-Abo und AgentsRoom, das alles zusammenhält. Kein Server geschrieben, keine Abrechnung pro Token, ungefähr ein Wochenende Bastelei.

Das Ganze ist als Vorlage veröffentlicht: github.com/AgentsRoomDev/running-performance-coach. Du kannst es klonen und zu deinem eigenen machen, indem du die Platzhalter ausfüllst. Dieser Artikel erklärt Stück für Stück, wie es funktioniert, und setzt dabei nur voraus, dass du das Wort „API“ schon einmal gehört, aber nie einen Webhook geschrieben hast.

Zur Einordnung: Ich laufe seit langem, 2:47 im Marathon, 1:13:59 im Halbmarathon, 33:45 auf 10 km. Das Ziel des laufenden Zyklus ist, auf 10 km wieder unter 34 Minuten zu kommen. Das ist wichtig für alles Weitere: Ein generischer Coach, der mir noch einmal erklärt, was eine Schwelleneinheit ist, nützt mir nichts, und genau dieses Problem löst dieser Aufbau.

Was zwischen dem Ende meines Laufs und dem Kommentar passiert

Die vollständige Kette besteht aus sechs Schritten:

1. Meine Uhr schickt die Aktivität an Strava. Dieser Teil passiert bei allen ohnehin schon.
2. Alle 15 Minuten fragt ein kleines Python-Skript bei Strava nach, ob es etwas Neues gibt.
3. Wenn es eine neue Einheit findet, baut es daraus ein Einheitsblatt in Markdown in meinem Repository: Runden, Zwischenzeiten, Umfang, Herzfrequenz. Nur Gemessenes.
4. Es schreibt außerdem Titel und Beschreibung der Aktivität auf Strava neu, damit in meinem Feed nicht mehr „Lauf am Nachmittag“ steht.
5. Dann schickt es eine signierte Nachricht an AgentsRoom, das einen Claude-Agenten öffnet, mit der Einheit bereits in der Hand.
6. Dieser Agent macht die Coaching-Arbeit: Er liest, er vergleicht, er schreibt die Analyse, er passt die Woche an, er commitet, er pusht, er kommentiert auf Strava, er schickt mir den langen Bericht per Mail.

Die ersten fünf Schritte sind Installationsarbeit. Um den sechsten geht es in diesem Artikel.

Das Trainingstagebuch ist ein Git-Repository, keine Datenbank

Das ist die Entscheidung, die alles verändert, und es ist auch die, die die meisten Leute überrascht.

Eine Einheit = eine Datei, journal/2026/2026-09-03.md. Eine Woche = eine Datei, plan/weeks/2026-W36.md. Eine Planänderung = ein Commit, mit dem Grund in der Nachricht. Es gibt keine Datenbank, kein Schema, keine Migration, keine Oberfläche.

Drei Folgen, nach Wichtigkeit geordnet:

Der Coach kann seine eigene Geschichte nachlesen. Er weiß, was er vor drei Wochen verordnet hat, und er kann prüfen, ob das funktioniert hat. Ein Chatbot, dem du deine Einheit erzählst, fängt in jedem Gespräch bei null an. Ein Agent mit einem Repository hat ein Gedächtnis, und dieses Gedächtnis ist für einen Menschen lesbar.

Ich lese meinen Plan auf dem Handy, in der GitHub-App. Die README.md des Repositorys ist keine Präsentationsseite: Sie ist mein Dashboard. Der Vertrag in CLAUDE.md ist da eindeutig, keine Planung ist fertig, solange das README sie nicht abbildet. Das Ergebnis: Ich habe keine Oberfläche zu pflegen und trotzdem einen Bildschirm, der mir sagt, was ich heute mache.

Nichts ist unumkehrbar. Alles, was der Agent schreibt, ist ein Commit. Ich kann ihn lesen, ihm widersprechen, ihn zurücknehmen. Das ist etwas ganz anderes als eine Anwendung, die für sich allein entscheidet.

Schritt 1: Strava weckt ein kleines Skript

Strava stellt eine API bereit: eine Möglichkeit für ein Programm, zu fragen „gib mir die letzten Aktivitäten dieses Athleten“. Das Skript strava_sync.py macht genau das und verwandelt die Antwort in ein Einheitsblatt.

Der interessante Teil ist nicht der Netzwerkaufruf, sondern die Rekonstruktion. Eine Uhr zeichnet rohe Runden auf. Das Skript muss herausfinden, welche Einheit das war:

Lap 1  : 4.40 km in 26'07 (5:56/km)   ← Aufwärmen
Lap 2  : 1.00 km in 3'41  (3:41/km)   ← Wiederholung 1
Lap 3  : 0.20 km in 1'59  (9:55/km)   ← Trabpause
...                                     → „5 x 1000m r' 2'“

Es probiert jede Aufteilung der Form „die k schnellsten Runden sind die Wiederholungen“ durch und behält die beste, die standhält. Das klingt trivial und ist es nicht: Eine naive Gruppierung nach Geschwindigkeit tappt in dem Moment in die Falle, in dem ein Aufwärmen schneller ist als eine Trabpause.

Vor allem wird die Form der Einheit aus der Uhr rekonstruiert, nie aus dem Plan. Es ist verlockend, es andersherum zu machen (im Plan steht 5 x 1000m, also schreibt man das hin), und genau das ist der Fehler: Der ganze Sinn ist, die Tage zu erkennen, an denen ich etwas anderes gemacht habe. Wenn die beiden auseinandergehen, ist genau diese Abweichung die Information, und der Coach sieht sie:

Planned 3 x 8' → durchgehend gelaufen

Zwei Warnungen, bevor du loslegst.

Die API von Strava verlangt seit Juni 2026 ein kostenpflichtiges Entwickler-Abo. Ohne das antwortet jeder Aufruf mit 403 Application Status Inactive. Der Rückfallweg existiert und ist in der Vorlage vorgesehen: eine TCX-Datei aus deiner Uhr exportieren und an import_tcx.py übergeben. Alles, was nach dem Import kommt, funktioniert identisch.

Die Kontingente sind großzügig, aber real. Bei meiner Anwendung 300 Anfragen alle 15 Minuten und 3.000 pro Tag für Lesezugriffe. Das Skript verbraucht im Normalbetrieb eine pro Durchlauf, also 96 pro Tag. Das ist weit von der Obergrenze entfernt, aber es ist die Art von Sache, die man vorher prüft, nicht hinterher.

Schritt 2: Das Skript weckt den Agenten, mit einer Signatur

Hier wird es interessant.

Ein Webhook ist das Gegenteil einer Frage. Anstatt alle fünf Minuten zu fragen, ob es etwas Neues gibt, gibst du einem Programm eine Webadresse, und es schickt dir eine Nachricht, wenn das Ereignis eintritt. Du zahlst nichts, solange nichts passiert.

AgentsRoom stellt genau das bereit: einen Webhook-Trigger. Du legst in der App einen Trigger an, sie gibt dir eine URL und ein Secret zurück. Wer eine JSON-Nachricht an diese URL schickt, öffnet einen Agenten, mit dem Prompt, den du geschrieben hast, und dem Inhalt der Nachricht bereits darin eingesetzt.

Die Nachricht, die mein Skript schickt, ist bewusst winzig:

{
  "type": "created",
  "title": "03/09 · 5 x 1000m r' 2'",
  "body": "Einheit vom 03/09/2026, aus Strava importiert.\n\nQualitätseinheit: 5 x 1000m r' 2'\nSplits: 3'41 - 3'40 - 3'38 - 3'40 - 3'35\n\nGesamtumfang: 12.51 km in 1h07'42 (5:25/km), Höhenmeter+ 56 m\nGeplante Einheit: RP10-5x1000\n\nEinheitsblatt: journal/2026/2026-09-03.md\nWochenblatt: plan/weeks/2026-W36.md"
}

Beachte, was nicht darin steht: der Text des Plans. Der Webhook transportiert den Code der geplanten Einheit und den Pfad zu den Blättern, nie deren Inhalt. Ein Agent, der das Repository hat, liest sie selbst nach; ein Agent, der es nicht hat, hat mit meinen internen Vorgaben nichts zu tun. Es ist dieselbe Regel wie für die auf Strava veröffentlichten Beschreibungen.

Die Signatur und die Falle, die dazugehört

Eine öffentliche URL, die einen Agenten öffnet, kann nicht für jeden offen bleiben, der sie findet. Der Trigger ist deshalb signiert: Das Skript berechnet mit dem geteilten Secret einen Fingerabdruck der Nachricht (ein HMAC-SHA256, falls dir der Begriff etwas sagt) und schickt ihn im Header X-AgentsRoom-Signature. Der Server berechnet denselben Fingerabdruck auf seiner Seite; stimmen sie nicht überein, lehnt er ab.

Ohne Signatur fällt die Antwort knapp aus:

{"error":"REJECTED","message":"Signature missing."}

Und hier ist die Falle, die mich einen Abend gekostet hat. Die Signatur deckt genau die Bytes ab, die über die Leitung gehen, nicht das Objekt im Speicher. Wenn du eine Datei so signierst, wie sie auf der Platte liegt, und dann eine andere Schicht das Objekt neu serialisieren lässt (ein Leerzeichen mehr, eine andere Reihenfolge der Schlüssel, ein anders maskierter Umlaut), erhältst du eine vollkommen gültige Signatur für eine Nachricht, die der Server nie bekommen wird. Die Ablehnung lässt sich nicht debuggen: Auf beiden Seiten sieht alles korrekt aus.

Die Korrektur passt in einen Satz: an derselben Stelle serialisieren und signieren. In der Vorlage macht die Funktion post_json beides, und nichts anderes darf den Nachrichtenrumpf anfassen.

Schritt 3: Drei Ebenen sagen dem Coach, wer er ist, wie es hier läuft und was jetzt zu tun ist

Ein Agent, der coacht, ist kein großer Prompt. Er besteht aus drei getrennten Texten, und die Trennung ist wichtig.

Ebene 1, die Persona: wer er ist

Ein System-Prompt, der dem Agenten in AgentsRoom mitgegeben wird. Er trägt die Trainingsphilosophie und ist bewusst sportartübergreifend allgemein: Er würde jeden coachen.

Deine Aufgabe ist nicht einfach, Trainingspläne zu erzeugen. Du coachst den Athleten durchgehend, indem du sein Training analysierst, seine aktuelle Form verstehst und die kommenden Einheiten anpasst. […] Rede wie ein erfahrener Trainer, nicht wie ein Motivations-Chatbot.

Er sagt auch, was er nicht tut: eine Einheit nicht allein danach beurteilen, ob das Zieltempo gehalten wurde, die Unsicherheit einer Wettkampfprognose deutlich benennen und ein Ziel nicht abnicken, bloß weil der Athlet es sich wünscht. Diese letzte Zeile macht den Coach nützlich.

Du musst sie nicht selbst schreiben: Diese Persona ist im Agenten-Katalog von AgentsRoom als Laufleistungscoach veröffentlicht. Ein Klick installiert sie, einsatzbereit.

Ebene 2, CLAUDE.md: wie es hier läuft

Das ist der Vertrag, gelesen zu Beginn jeder Sitzung. Er enthält den Dateiaufbau, die Regeln, die ihn konsistent halten, die Trainingsprinzipien, die jeden Vorschlag einschränken, und vor allem das Ritual: die genaue Abfolge, die abläuft, wenn eine Einheit gemeldet wird.

Ein Auszug, weil er das Maß an Präzision zeigt:

Reihenfolge der Opfer, wenn die Woche entgleist: zuerst die Extraminuten auf den lockeren Läufen, dann das Krafttraining, dann die Länge des langen Laufs, dann eine Qualitätseinheit. Nie die ganze Woche.

Hier hört der Coach auf, ein Chatbot zu sein. Er improvisiert nicht jedes Mal einen Ablauf, er folgt dem, den ich einmal geschrieben habe. Wenn du nur eine Datei des Vorlagen-Repositorys liest, dann diese.

Ebene 3, der Trigger-Prompt: was jetzt zu tun ist

Das ist die Nachricht, die dem Agenten übergeben wird, wenn eine Einheit eintrifft. Er bekommt die Aktivität über Vorlagenvariablen: {{event.title}}, {{event.body}}, {{event.url}}. Der Agent startet also mit der Einheit bereits in der Hand, statt sie erst suchen zu müssen.

So sieht er aus, wie er im Trigger steht:

Neue Einheit aus Strava importiert.

**{{event.title}}** · Aktivität {{event.id}}
{{event.url}}

{{event.body}}

---

Du bist im Repository `training-plan`. Lies zuerst `CLAUDE.md`: Es ist das Gesetz.
Du schreibst in meiner Sprache und sprichst mich durchgehend direkt an (§3).

Das Ritual aus §6 gilt, aber sein **Schritt 1 ist schon erledigt**:
`strava_publish.py` hat das Einheitsblatt erstellt und commitet. Du machst bei
Schritt 2 weiter und gehst bis zum Ende. Drei Ergebnisse, in dieser Reihenfolge:
**die Analyse im Repository**, **der Kommentar unter der Strava-Aktivität**,
**die Mail**.

⚠️ **Du läufst unbeaufsichtigt: Niemand wird eine Frage lesen.** Bitte nie um
eine Entscheidung: Du entscheidest, du handelst, und du sagst in deinem Bericht,
was du festgelegt hast und warum.

## 1 · Den Plan analysieren und anpassen (Ritual §6, Schritte 2 bis 6)

1. Zuerst `git pull --rebase`: Das Blatt kann vom Server kommen.
2. Lies in dieser Reihenfolge: das Blatt von heute, das Wochenblatt,
   `athlete/zones-and-paces.md` und **die letzten 3 Einheitsblätter**:
   Eine Einheit wird nie allein beurteilt.
3. Schreibe den Abschnitt `## Analysis`: **zuerst das Urteil**, dann die
   Signale, die es tragen, dann was sich dadurch ändert.
   ⛔ Wenn `## Analysis` schon gefüllt ist, schreibe ihn nicht neu.
4. Aktualisiere das Wochenblatt und halte **jede** Planänderung unter
   `## Adjustments` fest, mit ihrem Grund.
5. **Erzeuge die `README.md` neu**: Sie ist der Bildschirm, den ich auf dem
   Handy lese.
6. Commit und Push, explizite Pfade, ⛔ nie `git add -A`.

## 2 · Kudos und Kommentar auf Strava
   ⛔ Ein Strava-Kommentar ist ÖFFENTLICH: keine Zielherzfrequenz, kein
   Wehwehchen, keine interne Abwägung, keine vorhergesagte Zielzeit.

## 3 · Der vollständige Bericht per Mail

Die Zeile, die am meisten leistet, ist die in der Mitte: „Niemand wird eine Frage lesen“. Ein Agent, der ohne jemanden vor dem Bildschirm läuft und um eine Entscheidung bittet, macht keinen Fehler, er hält einfach an, und du merkst es am nächsten Tag.

Welches Modell, und warum eine Million Token keine Angeberei ist

Der lange Kontext ist keine Spielerei. Um eine Einheit sauber zu beurteilen, liest der Coach das Blatt von heute, das Wochenblatt, die Tabelle der Referenztempi und die drei vorherigen Einheiten. Eine Einheit wird nie allein beurteilt: die angehäufte Belastung, die Abfolge der Tage und die laufenden Beobachtungspunkte verändern das Urteil vollständig. Drei Wiederholungen in 3'38 einen Tag nach einem zweistündigen langen Lauf erzählen nicht dieselbe Geschichte wie dieselben 3'38 nach einem Ruhetag.

Der autonome Modus ist keine Nachlässigkeit, er ist eine Folge: Ein Lauf ohne jemanden vor dem Bildschirm hat niemanden, der ein git push freigibt. Und der Browserzugriff ist das, was den Agenten auf Strava kommentieren und die Mail verschicken lässt, zwei Dinge, für die es hier keine bequeme API gibt.

Was automatisiert ist und was bewusst nicht

Das ist die Design-Entscheidung, über die ich am glücklichsten bin, und sie ist leicht zu übersehen.

Der Import-Job protokolliert und veröffentlicht, er beurteilt nie.

Ein Skript, das anfinge zu beurteilen, würde Urteile ohne Kontext produzieren, mit einer Logik, die in Code eingefroren ist, den niemand nachliest. Beurteilen heißt, die Wochenbelastung, die aktuelle Form und das, was beim letzten Mal gesagt wurde, zusammenzuhalten: Das ist Coaching-Arbeit, und der Agent macht sie, mit der ganzen Akte vor sich.

Der praktische Vorteil ist sofort spürbar: Wenn der Agent nicht gelaufen ist (Maschine aus, API weg), existiert das Blatt trotzdem. Nichts geht verloren, nur der Kommentar fehlt, und ein erneutes Abspielen genügt.

Eine weitere Entscheidung geht in dieselbe Richtung: Das Skript führt keine Zustandsdatei, um zu wissen, was es schon bearbeitet hat. Maßgeblich ist die Beschreibung auf Strava. Ist sie leer, schreibt es; trägt sie seine Signatur, geht es weiter; ist sie nicht leer und ohne Signatur, hast du sie geschrieben und es fasst sie nicht an. Eine lokale Zustandsdatei hätte nichts darüber sagen können, was eine andere Maschine getan hat; so können zwei Maschinen parallel laufen, ohne sich in die Quere zu kommen.

Zwei weitere Trennungsregeln, im Repository festgeschrieben und nicht zu umgehen:

• die auf Strava veröffentlichte Beschreibung kopiert nie den Text des Plans: Mein Wochenblatt enthält Zielherzfrequenzen und Abwägungen, die auf einer öffentlichen Aktivität nichts zu suchen haben;
• eine von Hand geschriebene Beschreibung wird nie überschrieben.

Der Kommentar, der unter der Aktivität landet

Es geht nicht um Selbstbeweihräucherung. Es geht darum, dass das Urteil des Coachs von meinem Handy aus lesbar ist, unter der Aktivität, ohne das Repository zu öffnen, und dass es dort bleibt, an die Einheit geheftet, für immer.

Der Kommentar ist deshalb bewusst schmal: ein Urteils-Emoji, die Zahl, die es trägt, und was sich dadurch für die nächste Einheit ändert. Rund 250 Zeichen.

✅ Fünf Wiederholungen mit 3'39 im Schnitt bei einem Ziel von 3'38 bis 3'44, und die Herzfrequenz über den ganzen Block flach. Die Tempotabelle hält. Freitag bleibt locker: Du hast die Reserve dieser Woche ausgegeben.

Die lange Fassung, die mit den Herzfrequenzen, dem von mir gemeldeten Beobachtungspunkt und der Abwägung zum Umfang der nächsten Woche, geht ins Repository und in die Mail. Zwei Kanäle, zwei Zielgruppen, und der Prompt hält die Grenze.

Drei Dinge, die erst im Betrieb kaputtgehen

Jede dieser Zeilen existiert, weil ohne sie etwas kaputtgegangen ist. Sie sind lehrreicher als der Rest des Artikels.

1. Den Browser festlegen. Ich habe zwei Claude-Erweiterungen in Chrome verbunden. Nichts garantiert, welche der Agent bekommt, und nur eine hält die Strava-Sitzung. Das Ergebnis: Bei jedem zweiten Lauf landete der Agent im falschen Browser, abgemeldet, unfähig, irgendetwas zu kommentieren. Die Auswahl des Browsers per Geräte-ID wird von einer Sitzung zur nächsten nicht gespeichert: Sie gehört deshalb in den Prompt, mit einem ausdrücklichen Verbot, den Nutzer zu fragen, welcher gewählt werden soll. Unbeaufsichtigt ist eine Frage eine Sackgasse.

2. Das Strava-Kommentarfeld hat kein maxlength. Nichts im Browser hindert dich daran, zu lang zu schreiben: Es ist der Server, der beim Absenden ablehnt. Ein Agent, der einen schönen Absatz mit 600 Zeichen verfasst, tippt das Ganze, klickt auf „Posten“ und kassiert einen Fehlschlag, den er nicht versteht. Der Prompt muss die Kürze also vor dem Schreiben durchsetzen und den Fall einplanen: Wenn das Absenden scheitert, kürzen und erneut posten, nie in zwei Kommentare aufteilen.

3. Ein Coach-Kommentar pro Aktivität. Wenn man ein Ereignis zum Testen erneut abspielt (was man am Anfang viel tut), stapelt der Agent ohne diese Regel Kommentare auf einer bereits bearbeiteten Aktivität. Der Prompt lässt ihn deshalb vor dem Schreiben den Tab „Kommentare“ lesen und aussetzen, wenn er dort schon steht. Dieselbe Logik auf der Repository-Seite: Wenn der Abschnitt ## Analysis schon gefüllt ist, wird er nicht neu geschrieben.

Was das kostet

Es gibt in diesem Aufbau keinen API-Schlüssel, der pro Token abgerechnet wird. Das ist der Punkt, den ich am meisten unterschätzt finde: Dasselbe auf einer nutzungsabhängig abgerechneten API gebaut hätte bei jeder Einheit einen laufenden Zähler, und ich hätte es vermutlich nicht behalten.

Bau es dieses Wochenende

Die Schritte, in der richtigen Reihenfolge. Rechne mit einem Abend, wenn du bereits ein Strava-Konto und ein Claude-Abo hast.

1. Die Vorlage klonen und zu deiner machen.

git clone https://github.com/AgentsRoomDev/running-performance-coach.git my-coach
cd my-coach
rm -rf .git && git init

Mach deine Kopie privat. Ein Trainingstagebuch enthält Gesundheitsdaten: Herzfrequenz, Schlaf, Verletzungen. Die Vorlage ist öffentlich, deine Kopie sollte es nicht sein.

Fülle dann in dieser Reihenfolge aus: athlete/profile.md (wer du als Läufer bist), athlete/records.md (deine Bestzeiten), athlete/constraints.md (die Zeitfenster, die du wirklich hast), athlete/zones-and-paces.md (deine Referenztempi), plan/objective.md (der Wettkampf und das Ziel), dann CLAUDE.md, wo du jeden Platzhalter {{...}} ersetzt.

Öffne zum Schluss das Repository mit deinem Claude-Agenten und sag: „lies CLAUDE.md und athlete/, dann bau mir die erste Woche.“

2. Strava anschließen.

cp .env.example .env && chmod 600 .env
python3 scripts/strava_oauth.py     # ein Klick im Browser, ein einziges Mal
python3 scripts/strava_sync.py --dry-run

Das --dry-run zeigt an, was geschrieben würde, ohne etwas zu schreiben. Das ist der Moment, um zu prüfen, ob dir die Rekonstruktion der Einheiten zusagt.

3. Den Trigger in AgentsRoom anlegen. Unter Triggers, New trigger:

AgentsRoom erzeugt eine URL und ein Signatur-Secret. Trag beides in deine .env ein:

WEBHOOK_URL=https://agentsroom.dev/api/triggers/t_xxxxxxxxxxxx
WEBHOOK_SECRET=whsec_xxxxxxxxxxxxxxxxxxxxxxxx

4. Teste ihn, bevor du ihm vertraust.

python3 scripts/webhook_replay.py scripts/examples/webhook-session.json --dry-run
python3 scripts/webhook_replay.py scripts/examples/webhook-session.json

Das spielt eine Einheit in den Trigger ein, ohne auf deinen nächsten Lauf zu warten und ohne den Zustand des automatischen Jobs anzufassen. Du solltest ✅ HTTP 202 sehen, und in AgentsRoom sollte sich ein Agenten-Tab öffnen.

5. Alle 15 Minuten laufen lassen.

bash scripts/systemd/install.sh          # auf einem Linux-Server

Eine oneshot-Unit plus ein Timer: kein dauerhaft laufender Prozess, und ein Durchlauf, der ausgefallen ist, während die Maschine aus war, wird beim nächsten Start nachgeholt.

Wenn du keine dauerhaft laufende Maschine hast, überspring diesen Schritt: Starte strava_sync.py von Hand, wann immer dir danach ist, oder erzähl deine Einheit dem Agenten einfach in einem Gespräch. Das Ritual in CLAUDE.md funktioniert identisch. Du verlierst die Automatisierung, nicht den Coach.

Was ich daraus mitnehme, über das Laufen hinaus

An diesem Aufbau ist nichts spezifisch für das Laufen. Was er zeigt, ist ein wiederverwendbares Muster für so ziemlich jeden Bereich, in dem du persönliche Daten ansammelst und gern eine kompetente Meinung dazu hättest.

Drei Teile, und das war es. Ein Git-Repository voller Markdown-Dateien als Gedächtnis, lesbar für die Maschine und für dich. Ein Ereignis, das einen Agenten weckt, statt eines Agenten, der in einer Schleife abfragt und für nichts Token verbrennt. Drei Konfigurationsebenen, die sauber trennen, wer der Agent ist, wie er bei dir arbeitet und was er in diesem Moment tun soll.

Ersetze „Laufeinheit“ durch „Kontoauszug“, „Coding-Sitzung“, „Blutzuckerwert“ oder „Lesenotiz“: Der Mechanismus ändert sich nicht.

Häufige Fragen

Muss ich programmieren können, um mir einen KI-Laufcoach zu bauen?

Du musst einen Befehl im Terminal starten und eine Textdatei bearbeiten können. Das Vorlagen-Repository ist fertig zum Klonen, die Python-Skripte nutzen nichts außer der Standardbibliothek (kein pip install), und der Coaching-Teil wird konfiguriert, indem man normalen Fließtext in Markdown-Dateien schreibt. Die eigentliche Arbeit ist nicht technisch: Sie besteht darin, ehrlich zu beschreiben, wer du als Läufer bist und was du anstrebst.

Was kostet das im Monat?

Der Agent läuft auf dem Claude-Abo, das du ohnehin hast (Pro oder Max): Es gibt keinen API-Schlüssel, der pro Token abgerechnet wird. Dazu kommt eventuell eine kleine, dauerhaft laufende Maschine, die Strava alle 15 Minuten abfragt, rund 5 Euro im Monat auf einem VPS oder gar nichts auf einem Raspberry Pi. Das private Git-Repository ist kostenlos. Bleibt die Strava-API, die seit Juni 2026 ein kostenpflichtiges Entwickler-Abo verlangt.

Warum ein Git-Repository statt einer Datenbank?

Weil die Geschichte dadurch lesbar wird, für den Coach und für dich. Jede Einheit ist eine Markdown-Datei, jede Planänderung ein Commit mit seinem Grund. Der Agent kann nachlesen, was er vor drei Wochen verordnet hat, und prüfen, ob es funktioniert hat, und du liest deinen Plan auf dem Handy in der GitHub-App, ohne eine Zeile Oberfläche zu schreiben.

Was ist ein Webhook, einfach erklärt?

Ein Webhook ist ein Dienst, der dich anruft, statt dass du ihn anrufst. Anstatt alle fünf Minuten zu fragen, ob es etwas Neues gibt, gibst du einem Programm eine Webadresse, und es schickt dir eine Nachricht, wenn das Ereignis eintritt. Hier schickt das Skript, das die Einheit importiert, diese Nachricht an AgentsRoom, das binnen einer Sekunde einen Claude-Agenten öffnet. Das macht den Aufbau auch günstig: Ein Agent, der in einer Schleife abfragt, verbrennt in jeder Runde Token, ein Webhook-Trigger kostet nichts, solange nichts passiert.

Funktioniert das auch für eine andere Sportart als Laufen?

Ja. Der Import rekonstruiert Runden aus der Uhr, und Radfahren wie Schwimmen zeichnen ebenfalls Runden auf. Was sich ändert, sind die Strategiedateien und der Einheitenkatalog, und das ist Text, den du umschreibst. Der Mechanismus (Import, Webhook, Agent, Repository) bleibt derselbe.

Kann der Agent sich irren und meinen Plan ruinieren?

Er kann sich irren, aber er kann nicht viel ruinieren: Alles, was er schreibt, ist ein Git-Commit, den du lesen, bestreiten und zurücknehmen kannst. Die Datei CLAUDE.md verbietet ihm ausdrücklich, die Historie umzuschreiben, Daten zu erfinden, die du nicht geliefert hast, den Plan ohne festgehaltenen Grund zu ändern und medizinische Ratschläge zu geben. Bei verdächtigen Schmerzen schickt er dich zu einer Fachperson.

---

Das Vorlagen-Repository liegt hier: AgentsRoomDev/running-performance-coach. Klone es, trag deine Tempi ein, und du hast deinen Coach. Wenn du den Baustein sehen willst, der den Agenten weckt, er ist auf der Seite Webhook-Trigger beschrieben, und AgentsRoom wird hier heruntergeladen.