The plan that knew who it was for.

A generic plan and a specific one start from the same question.

A generic training plan and a specific one start from the same question. The difference is everything that comes before it.

Ask an AI to build a half marathon plan and it will build one. It will be structured, reasonable, and completely unaware of who it is for. It will not know that you just raced Hyrox twice in one day. It will not know that a one-year-old is disrupting your sleep or that a new baby is due mid-year. It will not know that staying injury-free matters more than hitting any single session, or that your training philosophy treats easy sessions as non-negotiable and recovery as part of the structure.

This case study shows what changes when the AI does know. Not because you told it in the prompt. Because it was already in the compilation.

Eight weeks out, mid-recovery.

Eight weeks before a half marathon, a 40-year-old hybrid athlete had just come off a Hyrox event where he had raced twice in a single day. His HRV sat in the low 30s for most of the week following the race, against a baseline closer to 45ms. Soreness check-ins were running at 7 and 8 out of 10. Energy was flat. The body was doing what bodies do after two hard race efforts in one day.

He had a half marathon on the calendar. He did not have a fixed time target yet. What he had was a recovery state that needed managing, a life load that was not easing up, and a clear priority: get to the start line healthy, run well, and see what the training had built.

His profile in Me. was already complete. Conditions, supplements, diet, lifestyle. A training philosophy built over time into a detailed doctrine layer: how he thinks about easy days, how he governs threshold work, what he does when life load rises, how he wants recommendations framed. The doctrine was not aspirational writing. It was operational. It described exactly how this athlete makes decisions under pressure, and it named injury prevention and recovery governance as non-negotiables.

Then he wrote the prompt.

He opened Me., selected 90 days of data, and turned on the relevant toggles: biometrics, sleep, workouts, check-ins, notes, training context, and health profile. The compilation included everything: the Hyrox race data, the two weeks of flat recovery metrics that followed, the gradual return of HRV and energy across the weeks after, and the training sessions that had started to come back to life.

Then he wrote the prompt.

Not this:

Generic"Write me an 8-week half marathon training plan."

This:

Specific"I have 90 days of training data attached, including a post-Hyrox recovery period. I'm targeting a half marathon in approximately 8 weeks. Based on my current recovery state, training philosophy, fitness indicators in this data, and the life constraints in my profile, build a structured training block. Staying injury-free is the primary constraint. My doctrine describes how I want sessions categorised and how I want recommendations framed. Use it."

The difference is not the length of the prompt. It is what the AI had to work with before it responded.

A plan that reflected the doctrine.

The plan the AI produced was not a generic 8-week half marathon template. It reflected the doctrine directly.

Easy sessions were prescribed as genuinely easy, with specific HR caps and notes about what drift to watch for. Threshold work appeared once per week, controlled and repeatable, not as racing. Strength was included at maintenance dose only. The first two weeks acknowledged the post-Hyrox recovery state explicitly: lower intensity, reduced volume, a gradual re-entry rather than an immediate return to quality work.

But the first response was not the final plan.

The athlete went back and forth with the AI before committing to anything. Training days that did not fit the week were moved. Session lengths were adjusted against realistic morning windows. The impact of a newborn at home, irregular sleep, and a desk job that did not always end on time were all fed back into the conversation. The AI adjusted each time, not by generating a new plan from scratch, but by working with what already existed and refining it against what was actually possible.

The plan that went into Me. was the result of that conversation. It was not handed down. It was built collaboratively, with the profile as the foundation and the athlete's real availability as the constraint. There was no time target in this first version. That came later.

He exported the plan as a CSV and imported it into Me. The training tab now showed the week ahead. The Days tab now showed the prescribed session alongside every actual workout, his RPE rating, and his note for that day. Plan versus reality, in one view, every day.

Where it becomes more than a transaction.

This is where the workflow becomes something more than a one-time transaction.

Most mornings, before training, he would check his key metrics in the Days tab: how sleep had tracked, where his recovery indicators sat, how the previous session had logged. If something looked off, he would add a note. Sometimes he would take a short compile, 14 days of data, and ask the AI a direct question: "Recovery looks poor this morning. I have a threshold session planned. Should I adjust?"

The AI would read the data, read the recent notes, and give a direct answer. Sometimes the session stayed as planned. Sometimes it shifted to zone 2. Sometimes it was shortened or swapped entirely. The responses were specific because the data was specific. The athlete's own notes, a sentence or two after each session, were often what made the difference between a useful answer and a generic one.

This near-daily check-in was also how the time target evolved. After three weeks of consistent sessions and improving recovery data, he compiled again and asked a direct question about what the data suggested was realistic. The AI read his threshold paces, his long run HR data, his recovery trends, and came back with a clear read: sub-1:30 was well within reach, and based on the trajectory, 1:28 was worth targeting.

That became the goal. Not because the AI told him to chase it. Because the data he had built over weeks made the conversation credible.

Race-day pacing strategy came from the same process. A short compile in the final week, a specific question about how to distribute effort across 21 kilometres given his training data and his doctrine's guidance on controlled early pacing. The AI gave him splits. He adjusted them slightly based on how he felt in the taper. He went in with a plan he had talked through rather than one he had guessed at.

Race day.

The training block had built from a 12km long run in late April to a 22km peak run three weeks out. The dress rehearsal session, 18km with the final 10km at target pace, had gone well. The taper had felt right. He had not missed a session to injury. The recovery-first approach had held.

The data had told that story before race day. The notes had told the rest.

Context kept. Calls made by the athlete.

Me. did not write the plan. It did not interpret the data. It did not tell him when to push and when to hold back.

What it did was carry three months of context into every conversation: the training load, the recovery patterns, the subjective check-ins, the notes from sessions that only made sense weeks later, and a doctrine that described exactly how this athlete thinks about his training and his life.

The AI had everything it needed to give a useful answer, every time. Most AI conversations about training start from nothing. These ones started from weeks of honest data and a profile built to describe one specific person.

The gap between a generic training plan and a useful one is context. Me. keeps the context. The AI does the analysis. The athlete makes the calls.

That is the whole workflow.