Mijn AI-hardloopcoach is een Git-repository en een Claude-agent

Ik loop mijn training uit, mijn horloge synchroniseert, en drie minuten later staat de analyse in mijn repository, is de week bijgesteld en heeft mijn coach een reactie onder de Strava-activiteit geplaatst. Geen app gebouwd, geen server geschreven, geen rekening per token: een Claude-abonnement, AgentsRoom en Markdown-bestanden. Hier is de hele bouw, na te maken.

Ik loop mijn training uit. Mijn horloge synchroniseert vanzelf met Strava, zoals altijd. Ik ga douchen.

Tegen de tijd dat ik eruit stap, zijn er drie dingen gebeurd zonder dat ik iets heb aangeraakt. De analyse van de sessie staat in mijn trainingsrepository. De week is bijgesteld, met de reden voor de wijziging ernaast genoteerd. En onder de Strava-activiteit staat een reactie van mijn coach, die me vertelt wat de sessie waard was en wat ze verandert voor vrijdag.

Die coach is geen applicatie die ik heb gebouwd. Het is een Git-repository met Markdown-bestanden, een Claude-abonnement, en AgentsRoom dat het geheel bij elkaar houdt. Geen server geschreven, geen rekening per token, ongeveer een weekend sleutelen.

Het geheel is als sjabloon gepubliceerd: github.com/AgentsRoomDev/running-performance-coach. Je kunt het klonen en tot het jouwe maken door de plaatshouders in te vullen. Dit artikel legt stuk voor stuk uit hoe het werkt, en gaat er alleen van uit dat je het woord “API” weleens hebt gehoord maar nog nooit een webhook hebt geschreven.

Even ter plaatsing: ik loop al lang, 2:47 op de marathon, 1:13:59 op de halve, 33:45 op 10 km. Het doel van de huidige cyclus is weer onder de 34 minuten duiken op 10 km. Dat is belangrijk voor wat volgt: een generieke coach die me nog eens uitlegt wat een drempeltraining is, heb ik niets aan, en dat is precies het probleem dat deze bouw oplost.

Wat er gebeurt tussen het einde van mijn training en de reactie

De volledige keten telt zes stappen:

  1. Mijn horloge stuurt de activiteit naar Strava. Dat deel gebeurt bij iedereen al.
  2. Elk kwartier vraagt een klein Python-script aan Strava of er iets nieuws is.
  3. Zodra het een nieuwe sessie vindt, bouwt het daar een sessiebestand in Markdown van in mijn repository: rondes, tussentijden, volume, hartslag. Alleen gemeten gegevens.
  4. Het herschrijft ook de titel en de omschrijving van de activiteit op Strava, zodat er in mijn feed niet langer “Middagrun” staat.
  5. Daarna stuurt het een ondertekend bericht naar AgentsRoom, dat een Claude-agent opent met de sessie al in handen.
  6. Die agent doet het coachwerk: hij leest, hij vergelijkt, hij schrijft de analyse, hij stelt de week bij, hij commit, hij pusht, hij reageert op Strava, hij mailt me het lange rapport.

De eerste vijf stappen zijn leidingwerk. Over de zesde gaat dit artikel.

Het trainingslogboek is een Git-repository, geen database

Dit is de beslissing die alles verandert, en het is ook degene die mensen het meest verrast.

Eén sessie = één bestand, journal/2026/2026-09-03.md. Eén week = één bestand, plan/weeks/2026-W36.md. Eén wijziging in het schema = één commit, met de reden in het bericht. Er is geen database, geen schema, geen migratie, geen interface.

Drie gevolgen, op volgorde van belang:

De coach kan zijn eigen geschiedenis teruglezen. Hij weet wat hij drie weken geleden voorschreef, en hij kan nagaan of dat gewerkt heeft. Een chatbot aan wie je je training vertelt, begint bij elk gesprek weer bij nul. Een agent met een repository heeft een geheugen, en dat geheugen is leesbaar voor een mens.

Ik lees mijn schema op mijn telefoon, in de GitHub-app. De README.md van het repository is geen presentatiepagina: het is mijn dashboard. Het contract in CLAUDE.md is daar expliciet over, geen planning is af zolang de README ze niet weergeeft. Het resultaat: ik hoef geen enkele interface te onderhouden, en toch heb ik een scherm dat me vertelt wat ik vandaag doe.

Niets is onomkeerbaar. Alles wat de agent schrijft is een commit. Ik kan die lezen, betwisten, terugdraaien. Dat is heel wat anders dan een applicatie die in haar eentje beslist.

Stap 1: Strava wekt een klein script

Strava biedt een API aan: een manier voor een programma om te vragen “geef me de recente activiteiten van deze atleet”. Het script strava_sync.py doet precies dat, en zet het antwoord om in een sessiebestand.

Het interessante deel is niet de netwerkaanroep, het is de reconstructie. Een horloge legt ruwe rondes vast. Het script moet uitzoeken welke sessie dat was:

Lap 1  : 4.40 km in 26'07 (5:56/km)   ← inlopen
Lap 2  : 1.00 km in 3'41  (3:41/km)   ← herhaling 1
Lap 3  : 0.20 km in 1'59  (9:55/km)   ← herstel
...                                     → “5 x 1000m r' 2'”

Het probeert elke opdeling van de vorm “de k snelste rondes zijn de herhalingen” en houdt de beste over die overeind blijft. Dat klinkt triviaal en dat is het niet: een naïeve groepering op snelheid loopt tegen de lamp zodra een inlooprondje sneller is dan een herstelrondje.

Vooral: de vorm van de sessie wordt gereconstrueerd vanuit het horloge, nooit vanuit het schema. Het is verleidelijk om het omgekeerd te doen (het schema zegt 5 x 1000m, dus schrijf dat op) en dat is precies de fout: het hele punt is de dagen opsporen waarop ik iets anders heb gedaan. Als de twee uiteenlopen, is juist dat verschil de informatie, en de coach ziet het:

Planned 3 x 8' → aaneengesloten gelopen

Twee waarschuwingen voordat je begint.

De API van Strava vereist sinds juni 2026 een betaald ontwikkelaarsabonnement. Zonder dat antwoordt elke aanroep met 403 Application Status Inactive. De terugvaloptie bestaat en zit in het sjabloon: een TCX-bestand uit je horloge exporteren en aan import_tcx.py geven. Alles wat na de import komt, werkt identiek.

De quota zijn ruim, maar echt. Op mijn applicatie 300 verzoeken per kwartier en 3.000 per dag voor leesacties. Het script gebruikt er in normaal bedrijf één per doorloop, dus 96 per dag. Dat zit lang niet aan het plafond, maar het is het soort ding dat je vooraf nakijkt, niet achteraf.

Instellingenpagina van een Strava-API-applicatie: standaard ontwikkelaarsniveau, client-ID, gemaskeerd client secret, access token en refresh token met leesrechten, en de weergegeven limieten, 600 verzoeken per kwartier en 6.000 per dag in totaal, 300 per kwartier en 3.000 per dag voor leesacties.

Stap 2: het script wekt de agent, met een handtekening

Hier wordt het interessant.

Een webhook is het tegenovergestelde van een vraag. In plaats van elke vijf minuten te vragen of er iets nieuws is, geef je een webadres aan een programma, en dat stuurt jou een bericht zodra de gebeurtenis plaatsvindt. Je betaalt niets zolang er niets gebeurt.

AgentsRoom biedt precies dat: een webhooktrigger. Je maakt een trigger aan in de app, en die geeft je een URL en een secret terug. Wie een JSON-bericht naar die URL stuurt, opent een agent, met de prompt die jij hebt geschreven en de inhoud van het bericht daar al in gezet.

De gereedschapskiezer van AgentsRoom, met een tooltip op het Triggers-pictogram waarin “Agent runs on a schedule or a webhook” staat.

Het bericht dat mijn script verstuurt is bewust piepklein:

{
  "type": "created",
  "title": "03/09 · 5 x 1000m r' 2'",
  "body": "Sessie van 03/09/2026, geïmporteerd uit Strava.\n\nKwaliteitssessie: 5 x 1000m r' 2'\nSplits: 3'41 - 3'40 - 3'38 - 3'40 - 3'35\n\nTotaal volume: 12.51 km in 1h07'42 (5:25/km), hoogtemeters+ 56 m\nGeplande sessie: RP10-5x1000\n\nSessiebestand: journal/2026/2026-09-03.md\nWeekbestand: plan/weeks/2026-W36.md"
}

Let op wat er niet in staat: de tekst van het schema. De webhook vervoert de code van de geplande sessie en het pad naar de bestanden, nooit hun inhoud. Een agent die het repository heeft, gaat ze zelf lezen; een agent die het niet heeft, heeft niets te maken met mijn interne instructies. Het is dezelfde regel als voor de omschrijvingen die op Strava verschijnen.

De handtekening, en de valkuil die erbij hoort

Een publieke URL die een agent opent, kan niet openstaan voor iedereen die hem vindt. De trigger is dus ondertekend: het script berekent met het gedeelde secret een vingerafdruk van het bericht (een HMAC-SHA256, als die term je iets zegt) en stuurt die mee in de header X-AgentsRoom-Signature. De server berekent dezelfde vingerafdruk aan zijn kant; komen ze niet overeen, dan weigert hij.

Zonder handtekening is het antwoord kort:

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

En hier is de valkuil, die me een avond heeft gekost. De handtekening dekt precies de bytes die over de lijn gaan, niet het object in het geheugen. Als je een bestand ondertekent zoals het op de schijf staat, en daarna een andere laag het object opnieuw laat serialiseren (één spatie extra, een andere volgorde van sleutels, een letter met accent die anders wordt gecodeerd), dan krijg je een volkomen geldige handtekening voor een bericht dat de server nooit zal ontvangen. De weigering is niet te debuggen: aan beide kanten ziet alles er correct uit.

De oplossing past in één zin: serialiseer en onderteken op dezelfde plek. In het sjabloon doet de functie post_json allebei, en niets anders mag aan de body van het bericht komen.

Stap 3: drie lagen vertellen de coach wie hij is, hoe het hier werkt en wat er nu moet gebeuren

Een agent die coacht is niet één grote prompt. Het zijn drie losse teksten, en die scheiding doet ertoe.

Laag 1, de persona: wie hij is

Een systeemprompt die in AgentsRoom aan de agent hangt. Hij draagt de trainingsfilosofie, en is bewust algemeen over sporten heen: hij zou iedereen coachen.

Jouw taak is niet simpelweg trainingsschema's genereren. Je coacht de atleet doorlopend door zijn training te analyseren, zijn huidige vorm te begrijpen en de komende sessies aan te passen. […] Praat als een ervaren trainer, niet als een motivatiechatbot.

Hij zegt ook wat hij niet doet: een sessie niet alleen beoordelen op de vraag of het beoogde tempo is volgehouden, expliciet zijn over de onzekerheid van een tijdvoorspelling, en een doel niet goedkeuren alleen omdat de atleet het graag wil. Die laatste regel maakt de coach nuttig.

Je hoeft hem niet zelf te schrijven: deze persona is gepubliceerd in de agentencatalogus van AgentsRoom onder de naam Prestatietrainer Hardlopen. Eén klik installeert hem, klaar voor gebruik.

Laag 2, CLAUDE.md: hoe het hier werkt

Dit is het contract, gelezen aan het begin van elke sessie. Het bevat de bestandsindeling, de regels die haar consistent houden, de trainingsprincipes die elk voorstel begrenzen, en vooral het ritueel: de exacte volgorde die moet worden afgewerkt zodra een sessie wordt gemeld.

Eén fragment, omdat het het niveau van precisie laat zien:

Volgorde van opofferen als de week ontspoort: eerst de extra minuten op de duurlopen, dan de krachttraining, dan de lengte van de lange duurloop, dan één kwaliteitssessie. Nooit de hele week.

Hier houdt de coach op een chatbot te zijn. Hij improviseert niet elke keer een werkwijze, hij volgt degene die ik één keer heb opgeschreven. Als je maar één bestand van het sjabloon-repository leest, lees dan dat.

Laag 3, de triggerprompt: wat er nu moet gebeuren

Dit is het bericht dat aan de agent wordt overhandigd zodra een sessie binnenkomt. Hij ontvangt de activiteit via sjabloonvariabelen: {{event.title}}, {{event.body}}, {{event.url}}. De agent begint dus met de sessie al in handen, in plaats van ze te moeten gaan zoeken.

De triggereditor van AgentsRoom, met de naam “Coach · {{event.title}}” en de coachprompt, die begint met “Nieuwe sessie geïmporteerd uit Strava” gevolgd door de event-variabelen, de instructie om eerst CLAUDE.md te lezen, de waarschuwing dat hij onbewaakt draait, en de eerste stap van het ritueel.

Dit is de vorm ervan, zoals ze in de trigger staat:

Nieuwe sessie geïmporteerd uit Strava.

**{{event.title}}** · activiteit {{event.id}}
{{event.url}}

{{event.body}}

---

Je zit in het repository `training-plan`. Lees eerst `CLAUDE.md`: dat is de wet.
Je schrijft in mijn taal en je spreekt me overal rechtstreeks aan (§3).

Het ritueel van §6 geldt, maar **stap 1 ervan is al gedaan**:
`strava_publish.py` heeft het sessiebestand aangemaakt en gecommit. Je pakt op
bij stap 2 en gaat helemaal door. Drie opleveringen, in deze volgorde:
**de analyse in het repository**, **de reactie onder de Strava-activiteit**,
**de mail**.

⚠️ **Je draait onbewaakt: niemand zal een vraag lezen.** Vraag nooit om een
knoop door te hakken: jij beslist, jij handelt, en je zegt in je verslag wat je
hebt beslist en waarom.

## 1 · Het schema analyseren en bijstellen (ritueel §6, stappen 2 tot 6)

1. Eerst `git pull --rebase`: het bestand kan van de server komen.
2. Lees, in deze volgorde: het bestand van vandaag, het weekbestand,
   `athlete/zones-and-paces.md`, en **de laatste 3 sessiebestanden**:
   een sessie wordt nooit alleen beoordeeld.
3. Schrijf de sectie `## Analysis`: **eerst het oordeel**, dan de signalen die
   het dragen, dan wat het verandert.
   ⛔ Als `## Analysis` al is ingevuld, herschrijf ze niet.
4. Werk het weekbestand bij en leg **elke** wijziging in het schema vast onder
   `## Adjustments`, met de reden erbij.
5. **Genereer de `README.md` opnieuw**: dat is het scherm dat ik op mijn
   telefoon lees.
6. Commit en push, expliciete paden, ⛔ nooit `git add -A`.

## 2 · Kudos en reactie op Strava
   ⛔ Een reactie op Strava is OPENBAAR: geen streefhartslag, geen kwaaltje,
   geen interne afweging, geen voorspelde eindtijd.

## 3 · Het volledige rapport per mail

De regel die het meeste werk verzet, is die in het midden: “niemand zal een vraag lezen”. Een agent die draait zonder iemand voor het scherm en om een beslissing vraagt, maakt geen fout, hij stopt gewoon, en jij komt er de volgende dag achter.

Welk model, en waarom een miljoen tokens geen ijdelheid is

InstellingWaarde
ModelClaude Opus, context van 1M
RedeneerinspanningHoog
RechtenmodusAutonoom
BrowsertoegangAan

De triggerlijst van AgentsRoom, met de regel “Coach · {{event.title}}”, het webhooklabel, de bron “Any service (JSON)”, het project Running Performance Coach, en de instellingen van de agent: model Opus, hoge inspanning, autonome modus, browser aan.

De lange context is geen opsmuk. Om één sessie goed te beoordelen leest de coach het bestand van vandaag, het weekbestand, de tabel met referentietempo's en de drie voorgaande sessies. Een sessie wordt nooit alleen beoordeeld: de opgebouwde belasting, de opeenvolging van de dagen en de lopende aandachtspunten veranderen het oordeel volledig. Drie herhalingen op 3'38 de dag na een duurloop van twee uur vertellen niet hetzelfde verhaal als diezelfde 3'38 na een rustdag.

De autonome modus is geen slordigheid, hij is een gevolg: een run zonder iemand voor het scherm heeft niemand om een git push goed te keuren. En de browsertoegang is wat de agent in staat stelt op Strava te reageren en de mail te versturen, twee dingen waarvoor hier geen handige API bestaat.

Wat er geautomatiseerd is, en wat bewust niet

Dit is de ontwerpbeslissing waar ik het blijst mee ben, en ze is makkelijk over het hoofd te zien.

De importtaak legt vast en publiceert, ze oordeelt nooit.

Wat het script doetWat het niet doet
Nieuwe activiteiten ophalenDe sectie Analysis invullen
Het sessiebestand aanmakenAan het weekbestand komen
Titel en omschrijving op Strava schrijvenAan de referentietempo's komen
De aangemaakte bestanden commitenOok maar enige mening geven

Een script dat zou gaan oordelen, zou oordelen zonder context produceren, met logica die is bevroren in code die niemand herleest. Oordelen betekent de belasting van de week, de vorm van het moment en wat de vorige keer is gezegd samen vasthouden: dat is coachwerk, en de agent doet het, met het hele dossier voor zich.

Het praktische voordeel merk je meteen: als de agent niet gedraaid heeft (machine uit, API plat), bestaat het bestand toch. Er gaat niets verloren, alleen de reactie ontbreekt, en één keer opnieuw afspelen volstaat.

Nog een keuze die dezelfde kant op wijst: het script houdt geen statusbestand bij om te weten wat het al heeft verwerkt. De omschrijving op Strava is de bron van waarheid. Leeg, dan schrijft het; met zijn handtekening erin, dan gaat het door; niet leeg en zonder handtekening, dan heb jij ze geschreven en blijft het eraf. Een lokaal statusbestand had niets kunnen zeggen over wat een andere machine heeft gedaan; zo kunnen twee machines parallel draaien zonder elkaar voor de voeten te lopen.

Nog twee scheidingsregels, in het repository vastgelegd en niet te omzeilen:

  • de omschrijving die op Strava verschijnt kopieert nooit de tekst van het schema: mijn weekbestand bevat streefhartslagen en afwegingen die niets te zoeken hebben op een openbare activiteit;
  • een met de hand geschreven omschrijving wordt nooit overschreven.

De reactie die onder de activiteit belandt

Het gaat niet om zelffelicitatie. Het gaat erom dat het oordeel van de coach leesbaar is vanaf mijn telefoon, onder de activiteit, zonder het repository te openen, en dat het daar blijft staan, vastgeplakt aan de sessie, voor altijd.

De reactie is daarom bewust smal: een emoji met het oordeel, het cijfer dat het draagt, en wat het verandert voor de volgende sessie. Ongeveer 250 tekens.

✅ Vijf herhalingen op gemiddeld 3'39 bij een streefwaarde van 3'38 tot 3'44, en de hartslag vlak over het hele blok. De tempotabel klopt. Vrijdag blijft rustig: je hebt de marge van deze week opgebruikt.

De lange versie, die met de hartslagen, het aandachtspunt dat ik heb gemeld en de afweging over het volume van volgende week, gaat naar het repository en naar de mail. Twee kanalen, twee doelgroepen, en het is de prompt die de grens bewaakt.

Drie dingen die alleen in productie stukgaan

Elk van deze regels bestaat omdat er zonder die regel iets stukging. Ze zijn leerzamer dan de rest van het artikel.

1. Zet de browser vast. Ik heb twee Claude-extensies verbonden in Chrome. Niets garandeert welke de agent krijgt, en maar één ervan draagt de Strava-sessie. Het resultaat: om de andere run belandde de agent in de verkeerde browser, uitgelogd, niet in staat ergens op te reageren. De keuze van de browser op apparaat-id wordt niet bewaard van de ene sessie naar de volgende: ze hoort dus in de prompt, met een uitdrukkelijk verbod om de gebruiker te vragen welke hij moet kiezen. Onbewaakt draaien maakt van een vraag een impasse.

2. Het reactieveld van Strava heeft geen maxlength. Niets in de browser houdt je tegen om te lang te schrijven: het is de server die bij het versturen weigert. Een agent die een mooie alinea van 600 tekens opstelt, tikt het hele ding in, klikt op “Plaatsen”, en krijgt een mislukking die hij niet begrijpt. De prompt moet de beknoptheid dus vóór het schrijven opleggen, en het geval voorzien: als het versturen mislukt, inkorten en opnieuw plaatsen, nooit in twee reacties knippen.

3. Eén coachreactie per activiteit. Als je een gebeurtenis opnieuw afspeelt om te testen (wat je in het begin veel doet), stapelt de agent zonder deze regel reacties op een activiteit die al is afgehandeld. De prompt laat hem daarom vóór het schrijven het tabblad “Reacties” lezen, en zijn beurt overslaan als hij er al staat. Dezelfde logica aan de repositorykant: als de sectie ## Analysis al is ingevuld, wordt ze niet herschreven.

Wat dit kost

OnderdeelWaarKosten
De coachagentMijn machine, via AgentsRoommijn Claude-abonnement
De bevraging per kwartierEen klein Linux-machientje dat altijd aan staat~5 €/maand, of niets op een Raspberry Pi
Het logboekEen privaat Git-repositorygratis
De Strava-APIStrava Developer Programzie de tarieven van Strava

Er zit in deze bouw geen API-sleutel die per token wordt afgerekend. Dat is het punt dat ik het meest onderschat vind: hetzelfde gebouwd op een API met verbruiksfacturatie zou bij elke sessie een teller laten lopen, en dan had ik het waarschijnlijk niet volgehouden.

Bouw het dit weekend

De stappen, op volgorde. Reken op een avond als je al een Strava-account en een Claude-abonnement hebt.

1. Kloon het sjabloon en maak het van jou.

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

Maak je kopie privé. Een trainingslogboek bevat gezondheidsgegevens: hartslag, slaap, blessures. Het sjabloon is openbaar, jouw kopie hoort dat niet te zijn.

Vul daarna in, in deze volgorde: athlete/profile.md (wie je bent als loper), athlete/records.md (je persoonlijke records), athlete/constraints.md (de momenten die je echt hebt), athlete/zones-and-paces.md (je referentietempo's), plan/objective.md (de wedstrijd en het doel), daarna CLAUDE.md, waar je elke plaatshouder {{...}} vervangt.

Open ten slotte het repository met je Claude-agent en zeg: “lees CLAUDE.md en athlete/, en bouw daarna de eerste week voor me.”

2. Sluit Strava aan.

cp .env.example .env && chmod 600 .env
python3 scripts/strava_oauth.py     # één klik in de browser, eenmalig
python3 scripts/strava_sync.py --dry-run

De --dry-run toont wat er geschreven zou worden zonder iets te schrijven. Dat is het moment om na te gaan of de reconstructie van de sessies je bevalt.

3. Maak de trigger aan in AgentsRoom. Onder Triggers, New trigger:

VeldWaarde
SoortWebhook, bron generic
Promptde inhoud van docs/trigger-prompt.md
Rol / personadocs/coach-persona.md
RechtenmodusAutonoom
BrowsertoegangAan

AgentsRoom maakt een URL en een ondertekeningssecret aan. Zet ze allebei in je .env:

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

4. Test hem voordat je hem vertrouwt.

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

Dit speelt een sessie in de trigger af zonder op je volgende training te wachten en zonder aan de staat van de geautomatiseerde taak te komen. Je hoort ✅ HTTP 202 te zien, en er hoort een agenttabblad te openen in AgentsRoom.

5. Laat het elk kwartier draaien.

bash scripts/systemd/install.sh          # op een Linux-server

Een oneshot-unit plus een timer: geen residente processen, en een doorloop die is gemist terwijl de machine uit stond, wordt bij de volgende start ingehaald.

Heb je geen machine die altijd aan staat, sla deze stap dan over: start strava_sync.py met de hand wanneer het je uitkomt, of vertel je sessie gewoon aan de agent in een gesprek. Het ritueel in CLAUDE.md werkt identiek. Je verliest de automatisering, niet de coach.

Wat ik hieruit meeneem, verder dan het hardlopen

Aan deze bouw is niets specifiek voor hardlopen. Wat hij laat zien is een herbruikbaar patroon voor ongeveer elk domein waarin je persoonlijke gegevens opstapelt en er graag een deskundige mening over zou hebben.

Drie onderdelen, en dat is het. Een Git-repository met Markdown-bestanden als geheugen dat leesbaar is voor de machine en voor jou. Een gebeurtenis die een agent wekt in plaats van een agent die in een lus staat te bevragen en voor niets tokens verbrandt. Drie configuratielagen die netjes scheiden wie de agent is, hoe hij bij jou werkt, en wat hij op dit moment moet doen.

Vervang “hardloopsessie” door “bankafschrift”, “codeersessie”, “bloedsuikermeting” of “leesnotitie”: het mechanisme verandert niet.

Veelgestelde vragen

Moet ik kunnen programmeren om een AI-hardloopcoach te bouwen?

Je moet een commando in een terminal kunnen starten en een tekstbestand kunnen bewerken. Het sjabloon-repository staat klaar om te klonen, de Python-scripts gebruiken niets buiten de standaardbibliotheek (geen pip install), en het coachgedeelte stel je in door gewone lopende tekst in Markdown-bestanden te schrijven. Het echte werk is niet technisch: het is eerlijk beschrijven wie je bent als loper en waar je naartoe wilt.

Wat kost dit per maand?

De agent draait op het Claude-abonnement dat je al hebt (Pro of Max): er is geen API-sleutel die per token wordt afgerekend. Daarbovenop wil je misschien een klein machientje dat altijd aan staat om Strava elk kwartier te bevragen, ongeveer 5 euro per maand op een VPS, of helemaal niets op een Raspberry Pi. Het private Git-repository is gratis. Blijft over de Strava-API, die sinds juni 2026 een betaald ontwikkelaarsabonnement vereist.

Waarom een Git-repository in plaats van een database?

Omdat de geschiedenis daardoor leesbaar wordt, voor de coach en voor jou. Elke sessie is een Markdown-bestand, elke wijziging in het schema is een commit met de reden erbij. De agent kan teruglezen wat hij drie weken geleden voorschreef en nagaan of dat werkte, en jij leest je schema op je telefoon in de GitHub-app, zonder één regel interface te schrijven.

Wat is een webhook, in gewone taal?

Een webhook is een dienst die jou belt in plaats van andersom. In plaats van elke vijf minuten te vragen of er iets nieuws is, geef je een webadres aan een programma, en dat stuurt jou een bericht zodra de gebeurtenis plaatsvindt. Hier stuurt het script dat de sessie importeert dat bericht naar AgentsRoom, dat binnen de seconde een Claude-agent opent. Dat is ook wat de bouw goedkoop maakt: een agent die in een lus staat te bevragen verbrandt bij elke beurt tokens, een webhooktrigger kost niets zolang er niets gebeurt.

Werkt dit ook voor een andere sport dan hardlopen?

Ja. De import reconstrueert de rondes van het horloge, en fietsen en zwemmen leggen ook rondes vast. Wat verandert zijn de strategiebestanden en de sessiecatalogus, en dat is tekst die je herschrijft. Het mechanisme (import, webhook, agent, repository) blijft hetzelfde.

Kan de agent zich vergissen en mijn schema slopen?

Hij kan zich vergissen, maar veel slopen kan hij niet: alles wat hij schrijft is een Git-commit die je kunt lezen, betwisten en terugdraaien. Het bestand CLAUDE.md verbiedt hem uitdrukkelijk de geschiedenis te herschrijven, gegevens te verzinnen die jij niet hebt aangeleverd, het schema te wijzigen zonder de reden vast te leggen, en medisch advies te geven. Bij verdachte pijn stuurt hij je naar een professional.


Het sjabloon-repository staat hier: AgentsRoomDev/running-performance-coach. Kloon het, vul je tempo's in, en je hebt je coach. Wil je het onderdeel zien dat de agent wekt, dan staat dat beschreven op de pagina webhooktriggers, en AgentsRoom download je hier.

Download AgentsRoom

Draai al je AI-agenten, op al je projecten, vanuit één enkel venster.

GratisDownload AgentsRoom

Companion-app: houd je agents onderweg in de gaten

Breng je eigen: Claude, Codex, Antigravity CLI of andere AI-provider.

Download de extensie
Chrome Web Store

Stuur bugs en verzoeken direct naar je openbare backlog.

Een glimp van AgentsRoom in actie.

Meerdere projecten
Multi-provider
Meerdere agenten
Live status
Bestandsverschil & commit
Mobiele metgezel
Live voorbeeld
Agententeams
Browserautomatisering
Backlog-gedreven ontwikkeling
Promptbibliotheek
Vaardighedenbibliotheek
Bekijk alle functies

Verder lezen