Integrated LLMs vs. Algorithmic Coaching: Utility, Guardrails, and Safety

I’m a data-driven hybrid athlete looking into free MCP integrations to connect an LLM with Intervals.icu for assist with self-coaching, but I’m cautious about safety based on past experience.

When I previously used standalone LLMs for powerlifting and strength training, I found their recommendations to be erratic, excessively high in volume, and potentially dangerous over long-term planning horizons - especially when compared to structured, algorithmic platforms like JuggernautAI.

As I incorporate more endurance training alongside heavy strength work, I’m curious about the experiences of other coaches and athletes here:

  • Endurance Safety & Utility: Have you encountered similar risks (overreaching, erratic TSS/volume spikes, unmanaged fatigue) when using LLMs or tools like IntervalCoach for endurance self-coaching?

  • LLM vs. Algorithmic Guardrails: How do prompt-driven/LLM tools compare to deterministic, guardrailed platforms like TrainerRoad, Xert, or Join Cycling in real-world application?

  • Best Practices: If you integrate LLMs with Intervals.icu via MCP or custom APIs, how do you enforce safety guardrails so the model acts as a reliable analytical partner rather than making dangerous prescribing decisions?

Use basic principles and common sense? I still believe LLMs are better at quickly running analytics than prescribing training.

4 Likes

I’ve been heavily integrating LLMs into my engineering and exphys workflows for the past year using Claude Code, ChatGPT Codex, and dozens of local LLMs (Qwen, Gemma, Muse, etc) with good success, but there’s a lot of work to do.

I don’t trust any model to have the "intelligence " I need baked inside, so I provide the workflows for the models. I write playbooks and “cookbooks” for the LLMs to follow deterministic routines based on my personal opinions, professional standards, academic papers, textbooks, etc. All sources are provided to the model thru a RAG MCP server/vector database of my personally curated sources.

I have exphys models coded in Python (Bannister IR, PMC, critical power, training modalities, forecasting, race planning, metabolic testing analysis, etc.) and available to the LLM thru custom API. The LLM uses the code to generate the response.

My athletes data is stored locally and exposed the LLMs via custom API interface with dozens of tools that perform specific analyses. I have Golden Cheetah process FIT files and combine all lab and external data into the GC json file for easy processing.

Providing the LLM with all the external data is the easy part. Ensuring that the LLM response is accurate and true is the challenge. I had to make a custom agent that is solely responsible for citing the source for all values and other info used in response generation. It provides an evidence gate and annotates unverified claims and other anomalies. And even when I tell the LLM exactly what to do, they can’t do it 100% accurately.

But the huge boon to me is the LLMs ability to handle data. I don’t spend time moving and sorting data like I used to. I can process and reprocess an entire athlete history in minutes. I can run sensitivity analyses on parameters so easily, or perform a wide variety of what-if scenarios in minutes.

I agree with the common sense part, but I’d push back a little on LLMs being better at analytics than prescribing training. :slightly_smiling_face:

I’ve been using ChatGPT together with Intervals.icu as my personal endurance coach for most of this year, and my experience has actually been surprisingly good.

A great example was my preparation for the Wings for Life World Run in May. We only had around 4–6 weeks to prepare. I’m primarily a mountaineer & cyclist, definitely not a runner, and my running-specific fitness was pretty limited at that point. I had a decent aerobic base from cycling, but that’s obviously not the same as being prepared for running longer distances.

Despite that short timeframe, the AI helped build and continuously adapt my training, balancing threshold sessions, endurance runs, recovery and workload progression. I ended up covering 21.96 km in 1:57:54 – a result I was really happy with, especially considering where we started.

Of course, one successful race doesn’t prove anything scientifically, but it certainly changed my perspective on AI coaching.

The important difference, in my opinion, is how you use it.

I’m not simply asking an LLM to generate a 12-week plan and blindly following it. It has access to my Intervals.icu data through MCP, including training history, CTL/ATL, HRV, resting HR, sleep, Body Battery, completed workouts and subjective feedback.

We review recovery, adapt sessions when needed, create structured workouts and analyse the actual execution afterwards. Over time, the AI also builds up a lot of context about my individual responses, preferences, strengths and weaknesses.

And yes, it occasionally makes mistakes. I’ve had to question recommendations, correct assumptions and challenge its interpretation of certain metrics. That’s exactly why I wouldn’t trust it without proper data access, guardrails and some understanding of training principles myself.

I actually ended up extending an open-source Intervals.icu MCP server and building a Garmin data bridge to make more of the original training and wellness data available for these analyses.

For me, the biggest advantage over a rigid algorithmic system is the flexibility: I can discuss why something is recommended, provide context that isn’t captured by the numbers, and adjust the plan when real life gets in the way.

So I don’t really see it as LLM vs. algorithmic coaching. The ideal setup is probably a combination of reliable data, deterministic calculations and safety limits, with an LLM providing the interpretation, individualisation and interaction.

At least in my experience, that combination has already worked extremely well. Still very much a tool that needs a thinking human on the other end, though. :slightly_smiling_face:

3 Likes

My point exactly. Effective training is deceptively simple and its easy to overthink it.

2 Likes

One thing I can’t understand is how these non-human agents deal with bad data.

A good part of my work with athletes is dedicated to things like identifying and correcting activities with faulty HR data (extremely common, for various reasons), power data issues (still reasonably common, whether it’s a power meter running out of battery halfway through a ride or becoming miscalibrated while the athlete is waiting in the start pen before a race), duplicate or triplicate files (the same activity comes from the bike computer, the watch, and Whoop. Believe me, this happens quite often), and activities that need to be entered manually because the athlete forgot their GPS at home or the battery died, etc.

I know these things might seem outlandish to you, but always keep in mind that you, here on the forum, represent a strong bias toward users who are comfortable with technology and data. Out there, we still have elite athletes, some competing at an international level, who are unable to calibrate a power meter!

And quite often, this kind of data curation requires investigation and meticulous corrections.

So, what happens then? How does this work?

One additional comment: unfortunately, I think many of these AI solutions are not expanding the possibilities of training, but rather reducing the effort required to do a good job.

The other day, I saw a coach saying that he uses AI to generate workouts for his athletes, and that this is good because it increases productivity. Well, that’s good for him, because it increases his profit margin. But how is that good for the athletes?

4 Likes

The amount of complexity some amateur athletes can cram into a workout is honestly impressive. I hear people at races brag about sessions that are basically simple intervals wearing a tuxedo, with enough fancy adjectives attached to make them sound revolutionary.

The best model I’ve ever used is still K.I.S.S. No flashy interface, no big sponsorship, no clever branding. Just simple work, done consistently, with a clear purpose. Quality effort without the noise.

4 Likes

With OpenRowingMonitor we go the same route. The MCP allows for augmenting a sessions data (during rowing we collect rowing and HR/HRV data directly, but data like RPE, breathingrate and environmental conditions are quite telling, so they can be added later). Postprocessing adds Banister etc. Our MCP also provides statistical functions (rms and regression analysis at stroke, interval and session level), as well as predefined dashboards (both in json and html). This way we reduce the need to toss around large volumes of data, but also standardise certain elements. So the AI tool is used to formulate queries to identify trends, as well as analyse data, but the real data crunching happens MCP side, making it obey certain sanity checks and ground rules. The MCP also provides a memory for free format data, which is typically used to store trends and training schedule. The use of deterministic gaurdrails and structures makes use of this type of tooling much more responsible imho.

Coach here, with a disclosure: Nick and I build a deterministic (non-LLM) planner on top of Intervals.icu, so I’m not neutral. But on @Gabriel_Vargas’s bad-data question, what we learned is that the model matters less than what happens when data is missing or wrong:

  • Show where every number comes from. A threshold measured in a lab, one calculated from a field test and one estimated from eFTP should not look the same on screen.

  • Don’t fill gaps silently. If a weight or a test is missing, say so instead of plugging in a default.

  • Keep a person between the plan and the calendar. The coach or the athlete reviews before anything is published.

  • Same inputs, same output. Then you can trace a strange week back to the input that caused it.

Bad files (heart-rate spikes, power dropouts, duplicates) are still the hard part. We flag activities that arrive without detail, but bad data in still hurts. I agree with WindWarrior: the principles are simple, and tools should make them easier to follow, not replace judgement.

If you want to see how we handle it: our beta thread.

Grts, Vince & Nick

2 Likes

Is it possible to get a beta access code ? :innocent:

1 Like

@Jonas_Juul_Nowack sure! The code and how to sign up are here:

For TymeWear users: you can switch on TymeWear under Settings and record your VT1/VT2 test results (bike and run) next to your other tests. For now they’re stored for reference; they don’t set your zones yet.

Places are limited.

1 Like

Grab a book or good web site, learn how this stuff works (it’s pretty simple actually). Leave it to the LLM that sits between your ears.