Agentic coaching with human gates

Problem

I built a coaching system, and I am its client. It plans my strength sessions, reads back what the machine says I actually did, and proposes what to change next. That arrangement is useful and slightly dangerous: an agent that can write to the device I train on can also quietly change my week, and a system that reports “applied” without checking will happily build a plan on top of something that never happened.

I built a coaching system, and I am the person it coaches. It plans my gym sessions, reads back what the machine says I actually lifted, and suggests what to change next. That is useful and slightly dangerous at the same time: anything allowed to write to the equipment I train on can also quietly rewrite my week, and a system that says “done” without checking will cheerfully build next week’s plan on top of something that never happened.

The interesting problem was not making the agents capable. It was deciding which of them gets to hold an opinion, and where a human has to say yes.

The interesting problem was never making the AI capable enough. It was deciding which part of it is allowed to have an opinion at all, and exactly where I have to say yes before anything happens.

Constraints

In plain terms first: only one part of the system is allowed to decide anything, nothing is sent to my gym equipment until I have accepted it, nothing counts as done until it has been read back, and the record is only ever added to. The precise ground rules:

Judgment is not delegated to cheap models. Coaching decisions sit with one agent; execution is spread across narrow specialists that hold no discretion.
Nothing reaches the training device before I accept it.
A write is not done until it has been read back. “Sent” is not “applied”.
Decisions are append-only. History is added to, never rewritten.
The narrative on this page contains no health values, session content, or personal notes — the mechanics only. The screenshot below is the one deliberate exception: a review card from a real session of mine, captured from the shareable copy with internal identifiers removed.

Architecture

The team is deliberately lopsided — one agent holds judgment, five hold none:

The team is deliberately unbalanced — one member is allowed to judge, five are not:

Orchestrator — holds the coaching decision and the publish signal. It is the only role permitted an opinion about training.
Five executor subagents — pinned to cheaper models, each with a narrow toolset: editing device-side plans, editing platform records, writing reports, updating the tracker, maintaining documentation.
The split was once collapsed and then deliberately restored, and that reversal is recorded in the tracker rather than quietly tidied away.

A separate adapter service owns the connection to the training device:

A separate small service, and nothing else, is allowed to talk to the gym equipment:

The health platform holds no vendor credentials at all — it calls the adapter, which holds them.
The adapter shipped read-only, with a small set of gated write tools added later as a separate, separately validated phase.
Credentials are redacted in its logs by construction.

AI and agent workflow

The lifecycle is fixed, and each stage has one job:

The cycle never varies, and each stage does exactly one thing:

Plan — the orchestrator proposes the session and seeds a notes page for it.
Capture — my own text is stored verbatim, kept separate from any interpretation of it. What I said and what the system concluded never merge into one field.
Ingest — the device’s record of what actually happened is pulled in, against the plan it was supposed to follow.
Review — an evidence-linked review is produced, with each observation tied to the record behind it.
Decide — proposed changes land on a decision board. I press accept or reject; the presses drain back through receipted, idempotent operations.

Verdict card from a session review with three columns — what went well, worth watching, and even better if — each holding specific coaching observations in plain language — The verdict card of a real session review, 1 August 2026 — the orchestrator's judgment in plain language, each observation tied to the record behind it. Captured from the shareable copy with internal identifiers removed.

See 'How It Works' in Guest Mode

Two properties make the loop trustworthy rather than merely convenient:

Two things are what make this trustworthy rather than just convenient:

Accept-before-write ordering. Acceptance is not a notification that something happened — it is the precondition for it happening.
Fetch-back verification. After writing, the adapter re-reads the provider’s own record and reports the result as verified or unverified. It does not report success it has not confirmed.

Coaching advice cites its sources, and those citations are governed:

Any coaching advice has to say where it came from, and those references are themselves controlled:

A versioned bibliography is the executable source of truth; the published reference page is generated from it with a pinned content hash and tracks supersession.
A routing audit found most reference keys unreachable from the paths meant to use them — 27 of 41. That was recorded as a finding and fixed, not quietly dropped.

Human governance

The gate is real and it is mine. No proposed change reaches the training device without an explicit accept.
Illegal state transitions refuse the entire batch and acknowledge nothing, rather than applying half of it and reporting partial success.
An unproven claim blocks progress. A sweep looks for actions marked applied that lack the verification proving it, and refuses to move forward — the unproven action stops the next plan instead of freezing into history as fact.
Corrections void rather than delete. In the nutrition journal an entry is voided, the day is recomputed from what survives, and if the recomputation drifts from expectation the system refuses instead of silently accepting the new total.
The reversal is on the record. Collapsing judgment and execution into fewer agents was tried, found wrong, and undone — in the tracker, where anyone reading the history can see it.

Evidence

Everything above is artifact-verified against the system’s own record: the agent definitions with their model pins and tool scopes, the migrations that create the ledgers and their transition triggers, the modules implementing the drain and the stranded-action sweep, the adapter’s own repository and its phased write enablement, and an issue history recording each of these as delivered work.

Everything above was checked against the system’s own records rather than recalled: the written definitions of each agent, including which model it uses and what it is allowed to touch; the database changes that create the running logs; the code that carries accepted decisions through and sweeps up anything left stranded; the separate service that talks to the equipment, including how its ability to write was switched on in stages; and a history of tracked issues recording each of these as work actually delivered.

What is not finished, stated plainly:

Two open read-model defects as of 10 August 2026 mean the review currently misreports two tiles — a quality summary and a personal-record detection. The gates and the ledger are unaffected; the display is not.
Report templates have no automated JavaScript check. A duplicated declaration once blanked every chart on a live page — caught by eye, which is not a control.
Retrieval-augmented coaching evidence and longer-cycle periodization are designed, not built.
The approval-policy mechanism is nearly unused — in practice the human gate is manual by absence as much as by design, which is safe but not the same as deliberate.

Outcome

A coaching loop where one agent holds judgment and five hold none, at a fraction of the cost of routing everything through the expensive model.
A human gate that cannot be bypassed by an agent in a hurry: acceptance precedes the write, structurally.
Device writes that are verified by re-reading, and honestly labelled when they cannot be.
A system that refuses to build on unproven history — the stranded action stops the next plan.
A decision history that is append-only, so what was decided last month is still what it says it was.

Lessons

What I would carry into the next system of this kind:

Put judgment in one place. The moment two agents can both decide, you have no idea which one did.
Cheap models are excellent at doing exactly what they are told — the savings come from narrowing scope, not from lowering ambition.
“Applied” is a claim, not a fact. Verify by re-reading the other system’s record, and label the cases where you could not.
Let unproven work block progress. A pipeline that skips over its own unverified steps eventually builds on fiction.
Record the reversals. A tracker that shows what was undone is worth more than one that shows only what worked.