Introducing AI Session Generation: Just Tell MotionLab What You Need

The Problem We Were Solving

Every session builder has the same fundamental tension: flexibility vs. friction. Give people too few options and the sessions feel generic. Give them too many and the cognitive load kills the habit.

MotionLab's standard mode — pick a duration, pick a type, go — is fast and works well when you already know what kind of session you want. But there's a large class of situations where you don't think in those terms. You don't think 'I need a 15-minute post-workout daily maintenance session.' You think: 'My hips are absolutely wrecked from that long drive, and I have about ten minutes.' The gap between how people think about their body and how session builders ask them to interact is where most habit loops break.

AI session generation was built to close that gap entirely.

How It Works

When you type a prompt, it's sent to a server-side API route that calls Gemini 2.5 Flash. The model receives a compact exercise catalogue — just the exercise ID, target areas, and stretch type for each entry. No full descriptions, no instructions, no unnecessary context. This keeps the prompt lean and the response fast.

The model is asked to return a single JSON object: a session name, a session type (daily maintenance, pre-workout, or post-workout), and an ordered list of exercise IDs. That's it. The prompt instructs the model to prioritize the areas mentioned by the user, avoid redundant overlaps, and select between 4 and 8 exercises.

Thinking is explicitly disabled for this task. Gemini 2.5 Flash is a reasoning model that by default allocates tokens to an internal chain-of-thought before producing output. For a classification task this straightforward — map natural language to a list of exercise IDs — that reasoning overhead is pure cost with no benefit. Disabling it halves response time and reduces token usage significantly.

Once the model returns its selection, the server looks up each exercise by ID, fills or trims the list to match your chosen session duration, and sends a complete Routine object back to the client. The session is immediately ready to play.

What You Can Ask For

The model handles a wide range of inputs with reasonable accuracy. Area-specific complaints work well: 'tight hamstrings and calves', 'my lower back is in knots', 'shoulder mobility is terrible'. Intent-based prompts work equally well: 'recovery day after deadlifts', 'pre-game warm-up for football', 'desk worker who needs a full reset'.

Because the model infers session type from context, you don't need to specify it explicitly. 'Recovery after a long run' maps to post-workout. 'Get loose before a swim session' maps to pre-workout. 'Just need to move more' maps to daily maintenance. The model makes sensible inferences and errs toward the most common interpretation.

Vague prompts also work. If you just type 'I feel stiff', the model defaults to high-impact full-body exercises — deep squat hold, pigeon pose, cat-cow, child's pose — the kind of movements that address the most common restrictions across the most people. It won't refuse; it'll make a sensible call.

The Design Philosophy

A few decisions shaped how this was built.

First: the AI doesn't have access to your mobility scores or session history — not yet. This was a deliberate choice for the first version. Feeding the model personalisation data alongside the prompt would increase input token count, slow the response, and require careful prompt engineering to ensure the model weights that data appropriately. The straightforward version — map text to exercises — ships faster, works reliably, and covers the vast majority of use cases. Personalised AI sessions are on the roadmap.

Second: the model only picks IDs. It doesn't write descriptions, generate instructions, or invent exercises. The exercise library is the authoritative source of all content. This means the AI output is always grounded in real, validated exercise data — there's no risk of the model hallucinating a stretch that doesn't exist or inventing instructions that are unsafe.

Third: the duration is controlled client-side, not by the AI. You pick 7, 15, or 25 minutes. The server then fills the session to match that duration — first with the AI's selection, then supplementing from the same target areas if more time needs to be filled. The AI shapes the character of the session; you control its length.

What's Next

The current version is deliberately simple, and that's intentional. A narrow, well-defined feature that works reliably is more valuable than a broad one that sometimes gets it wrong. But there's a clear path forward.

The most obvious next step is feeding the model your mobility test scores alongside the prompt — so a user who types 'hip stuff' gets a session that's calibrated to whether their hips are tight, moderate, or flexible, rather than a generic hip routine. This requires some prompt design work to ensure the model interprets the scores correctly, but it's a straightforward extension.

Longer term, session history opens up interesting possibilities. A model that knows you've done three hip-focused sessions in the last week might deliberately introduce more variety, or flag that you might be overworking one area. The data is already there. Routing it through the AI is the next step.

For now: open MotionLab, hit the AI tab, and tell it what your body needs today.