Day 4 gave the Weekly Check-In Agent hands: it could read FitPath data and act on it, with an approval gate for risky users. But it was still one agent doing everything — reading, judging risk, and acting, all inside a single instruction block.

Today you split that agent into a supervisor and three specialized sub-agents, each restricted to only the tools its job needs. You'll design the delegation logic, wire it in Fleet, configure a human checkpoint, and then prove it behaves differently for a clean user than for a flagged one.

By the end you'll have a working multi-agent system and be able to answer, concretely: where did specialization actually earn its complexity, and where did it just add overhead?

Same FitPath spine, same two users:

• sam_w — clean profile, no injuries, no clearance issues.
• jordan_e — knee pain reported, no medical clearance on file.

Same MCP server as Day 4, exposing the same 8 tools:

The task this system handles: a weekly check-in for a given user — look at what happened this week, decide whether it's safe to log/notify/adjust automatically, and act (or escalate) accordingly.

The difference from Day 4: instead of one agent doing all of that, you're building three specialists plus a supervisor that coordinates them. This is the Supervisor pattern (Day 5, Slide 18) — not a router, because the orchestrator isn't just classifying and forwarding a request to one path; it's combining input from multiple agents before deciding what to do next.

Don't open Fleet yet. Answer these on paper or in a scratch doc — you'll need these decisions when you write instructions in Step 2.

If you get stuck on the sub-agent split, here's the shape (fill in the reasoning yourself — don't just copy this):

• Progress Analyst — reads what actually happened this week. Read-only.
• Safety Reviewer — reads the user's risk profile and decides if this user is safe to act on autonomously. Read-only.
• Action Coordinator — the only sub-agent with write access. Executes only what the supervisor tells it to, and only after any required approval clears.

In Fleet, create three sub-agents under one orchestrator (Add subagent, same as the panel you've already seen). For each one, write instructions that specify:

1. Scope — what this agent does and does not do (be explicit about the "does not" — that's what keeps it from overreaching).
2. Tools — connect only the tools that agent's job requires. This isn't a formality — an agent that can technically call log_workout will sometimes call it even if its job is "just" to analyze history. Restricting access is the guardrail, not the instructions.
3. Output — what it should hand back to the supervisor (a short structured summary, not a wall of prose — the supervisor has to read this).

Starter skeleton for the Safety Reviewer

The other two follow the same shape, write them yourself:

This is the part with no UI to lean on — it's all in the orchestrator's Instructions field, in prose. Get this wrong and nothing downstream saves you.

Your orchestrator's instructions need to cover:

• When it calls the Progress Analyst and Safety Reviewer (should this always run both, every time? Why?)
• How it reconciles their outputs if they disagree or one is inconclusive — don't skip this; write down what "disagree" would even look like for these two agents
• What it tells the Action Coordinator to do, and under what condition it does not authorize the Action Coordinator to run at all

Starter skeleton

Fleet's approval gate is per-tool, not conditional on what a sub-agent found — same mechanism as Day 4's "Set the Dial." That's a real constraint, not a bug in the exercise: it means the content of the approval request has to do work the trigger itself can't.

1. Require approval on the Action Coordinator's write tools (same as Day 4, Exercise 3).
2. Go back into the Action Coordinator's instructions and make sure the action request it generates actually carries the Safety Reviewer's findings — not just "requesting to log workout for jordan_e," but enough context that whoever's reviewing can make the right call without opening a second tab.

Run the full check-in flow for both:

1. sam_w — should complete end-to-end. Confirm via get_action_log that the Action Coordinator actually did something, not just claimed to.
2. jordan_e — should stop at the approval gate. Open the pending request and check: could you, as the reviewer, make the right call from what's shown — without already knowing Jordan's history?

If either run doesn't produce the expected result, don't just re-run it — look at the trace and figure out which sub-agent's instructions (or tool scope) caused it.

• Three sub-agents exist, each with only the tools its role needs — no sub-agent can act outside its stated job, even if it "could."
• The orchestrator's instructions explicitly state when it delegates, and how it aggregates the two analysis outputs — not just "ask the sub-agents and act."
• sam_w completes autonomously with a verifiable action in get_action_log.
• jordan_e produces a pending approval request that contains enough context (from the Safety Reviewer) for a human to decide correctly without pulling more data.
• You can say in one sentence why this is a Supervisor pattern and not a Router.

Push the Progress Analyst and Safety Reviewer toward an actual disagreement — construct a case where the workout history looks fine but there's an ambiguous note buried in it that only a careful read would catch. Watch what your orchestrator's aggregation logic actually does with that (does it notice, or does it just average the two into a vague middle ground?). Fix the instructions so it doesn't silently pick a side.

Full failure-injection version of this is available after-hours if you want to go further — ask for it.