Adaptive Triathlon Training That Responds to Real Life

Adaptive does not mean moving everything to tomorrow.

I've missed a Thursday threshold ride more times than I'd like to admit, usually because a work call ran long. Simply moving it to Friday does not solve anything. Friday may already have a quality run, Saturday is the long ride, and suddenly the clever adaptive plan has built three hard days in a row.

That's the problem adaptive training is supposed to solve.

Sometimes the missed session moves. Sometimes it gets shorter. Sometimes the correct answer is to drop it and move on. "Catch up at all costs" is not a coaching philosophy.

You need a direction before you can adapt intelligently.

A static plan without adjustment eventually becomes fiction. An adaptive plan without long-term direction becomes random. The useful middle ground is boring in the best possible way: keep the big goal stable, then make sensible decisions when the week stops behaving.

What should actually feed the next training week?

• Your race and where you are in the build. A week six months from race day should not look like a week two weeks from race day.
• Your real availability. Not the fantasy version of your schedule where every evening is free and the pool is always open.
• Your own thresholds. FTP, run threshold pace, heart-rate guidance and CSS are useful when the data is actually known.
• What you really did. Planned 60 minutes and completed 45 minutes are not the same fact. Both matter.
• Recent training load. Fitness, fatigue and form can support the decision, but they are evidence, not a magic readiness traffic light.
• What we do not know. If the evidence is missing, the honest answer is still "we do not know". Inventing a number just makes the screen look more confident.

This loop is no longer just a diagram on my whiteboard.

The private-beta version already connects the main pieces of the loop. Kestivo loads the athlete's Roadmap, availability, zones, completed training and physiology context, then drafts the next training week. The draft is validated and reviewed before it becomes active training.

1. Load the current context.
   Race direction, availability, zones, actual training and physiology.
2. Draft the next week.
   A structured seven-day proposal, not a wall of chat text.
3. Check the boring things.
   Dates, availability, workload boundaries and other hard constraints. Boring is good here.
4. Review it.
   The athlete sees the proposal before it becomes training.
5. Use reality next time.
   Completed sessions become part of the next planning context.

The best adaptation test so far was one I did not plan.

During my own testing I completed a middle-distance triathlon that Kestivo did not know about beforehand. That gave the system a much bigger training load than the planned week expected, which was exactly the kind of messy real-life event I wanted to see it handle.

The next generated week came back as a genuine recovery week. It did not try to "make up" the old plan. It treated the race as the major training stimulus and backed off accordingly.

That was a useful moment because it showed the distinction clearly. Kestivo did not magically rewrite the past. It used what actually happened as evidence for what should come next.

I am deliberately not calling it an autonomous coach yet.

Those would be easy claims to put on a landing page and much harder claims to deserve. For now the focus is narrower: use real athlete evidence to make the next planning decision better, validate it, and keep the athlete in control. Kestivo uses AI to help generate plans and explanations, but generated output is never treated as final just because a model produced it.

Adaptive triathlon training FAQ.

Related Kestivo guides.