AI agents for coaches: what changes when the AI can actually see your clients

Every coach has been sold AI twice already.

The first time it was a chatbot that wrote workout plans. It didn't know your client's knee flagged up on Tuesday, so you rewrote it. The second time it was a feature buried in a dashboard — "generate plan" — that produced something confident and generic, and you rewrote that too.

The problem was never the model. It was that the AI had never seen your clients. You were the integration layer: reading the check-in, holding the context in your head, typing it into a box, then translating the output back into your software.

That's the part we've now removed.

What changed: your assistant can open your account

Trainzilla exposes your coaching account over MCP — the Model Context Protocol, an open standard for connecting AI assistants to real systems. In practice: you connect Trainzilla to Claude once, and from then on your assistant can read your clients, their habits, their check-ins, their plans and their billing, run coaching maths, and — with your approval — write changes back.

Not a copy of your data. Not an export. Your live account, through the same API and the same permission rules the app itself uses.

The difference in daily use is not subtle. Instead of opening the dashboard, finding the client, reading the last check-in, opening the plan, recalculating macros, editing the plan and writing a message to explain it — you type:

"Priya's weight has stalled two weeks and she flagged poor sleep. What would you change?"

and the assistant pulls her profile, her habit compliance, her recent check-ins and her current plan, does the arithmetic, and proposes a change with the numbers behind it.

It has 42 tools, and the boring ones matter most

The connector currently exposes 42 tools. The headline ones are obvious — create a workout plan, create a diet plan, schedule a session. The ones that actually make the output trustworthy are less glamorous:

• search_exercises returns exercises from the real Trainzilla catalog with a match-confidence score, so a plan gets built from movements that genuinely exist in your library — not a plausible-sounding name the model invented.
• get_recovery_signals reads the client's synced Apple Health or Google Fit sleep and resting-heart-rate trend, where they've connected it. Load decisions stop being guesses about how someone seems.
• get_habit_compliance returns a straight percentage over a date range. "She's been inconsistent" becomes "61% over the last 14 days, and it's the 7:30 habit she's missing."
• get_ingredient_nutrition prices out real ingredients, so a diet plan's macros are computed rather than asserted.
• record_plan_rationale stores the coach-voice explanation of what was looked at, what changed, and why — attached to the client. Three weeks later, when they ask why their squat volume dropped, the answer is on file instead of in your memory.

There's also get_platform_rejection_trends, which is a slightly unusual one. When coaches across Trainzilla reject an AI suggestion, that gets counted by category. Your assistant can check those patterns before proposing something — a quiet feedback loop from thousands of coaching decisions. It returns category counts only, never any client's raw rejection text.

The safety design is the product

Handing an AI write access to real client accounts sounds reckless until you see the constraints. Three decisions do most of the work.

Every write is confirm-gated. Call create_workout_plan and you get a preview back — the plan it would create, in full. Nothing is written unless the call is repeated with confirm: true. There is no path where a stray sentence in a conversation silently rewrites a client's programme. You read the preview, then you approve.

It runs through the API, not the database. The connector wraps the same GraphQL API the Trainzilla apps use. Every permission check, validation rule and business constraint that protects your account in the app protects it here. The AI is a client of your account, not a backdoor into it.

Some things simply aren't exposed. Deleting clients, executing payments or refunds, changing permissions — these have no tool. Not gated, not confirm-protected. Absent. An assistant cannot do what it has no way to call.

Access is OAuth 2.1 with PKCE, scoped to your own coach account. You approve it once, and you can revoke it from Claude at any time — the same way you'd revoke any connected app.

Where it earns its keep

Three patterns keep coming up in real use.

The Sunday review. Instead of opening twelve client records one at a time, you ask for a sweep: who's dropped below 70% habit compliance, who hasn't checked in, whose subscription lapses this week. Ten minutes of reading instead of an hour of clicking.

The judgement call, with the numbers attached. "Her weight stalled for a week — deload or hold?" The assistant pulls compliance, sleep trend and the last three check-ins, and tells you what the data supports. You still decide. It just stops you deciding blind.

The explanation you don't have to write. After you approve a change, the reasoning gets written into the client's record in your voice. The client sees why, not just a changed number — which is most of the difference between a client who trusts the plan and one who quietly stops following it.

What this doesn't do

It doesn't coach for you. It has no opinion about whether a client is about to quit, whether the tightness in their knee is worth a referral, or whether they need a harder week or a kinder one. It reads what's recorded, does arithmetic faster than you can, drafts the obvious thing, and waits.

That's the honest pitch. Not "AI replaces the coach." The far less exciting, far more useful version: the admin layer between you and your clients gets thinner, and the judgement stays where it belongs.

The Trainzilla connector is live and works with your existing coach login. [Here's how to connect it in about two minutes](/blog/connect-trainzilla-to-claude).