Last week you built a workout-plan agent for FitPath. It could plan sessions and call tools — your custom MCP server — to read and write data. That's an agent using tools.

Today you're building something different: a second, independent agent that your workout agent can discover and delegate to, as a peer — not absorb as another tool. That's the distinction between MCP and A2A that we just covered on slides, and by the end of this hour it won't be a slide anymore. It'll be two workflows in your own n8n workspace, actually talking to each other over the A2A protocol.

FitPath wants to add nutrition guidance without rebuilding the workout agent from scratch. The product team's instinct is: "just give the workout agent a nutrition skill." Your job today is to build the alternative — a standalone Nutrition Agent, with its own identity, its own skill, and its own Agent Card — and prove that the workout agent can find it and hand it a task, the same way it could hand a task to a human specialist on the FitPath team.

You'll build both sides yourself, in the same n8n workspace:

• The Nutrition Agent — the server side. It advertises what it can do via an Agent Card, and receives tasks over A2A.
• The Workout Agent (stand-in) — the client side. It sends a real task to the Nutrition Agent and waits for the result.

You're working with Sam Whitaker today — clean profile, no complications. The point of this exercise is the mechanics of the handshake, not edge cases.

• Your n8n login (provided by your facilitator) — this is a private workspace; your workflows aren't visible to other participants.
• The A2A node set is already installed on the instance: A2A Remote Agent Server, A2A Client Agent, A2A Agent Registry.
• Sam Whitaker's profile (carried forward from Day 2 onward).
• Your Day 4 workout agent, open in another tab, for reference only — you're not editing it today.

Part 1 — Build the Nutrition Agent (15 min)

1. Create a new workflow. Name it FitPath — Nutrition Agent.
2. Define one skill: something like "suggest a meal plan adjustment based on a logged workout's intensity." Keep the logic simple — a templated response is fine (e.g., if intensity is "high," suggest an extra 20g protein and a electrolyte reminder). The point is not nutrition science; it's a working skill with a real input and a real output.
3. Add the A2A Remote Agent Server node and configure it to expose that skill.
4. Fill out the Agent Card: name, description, the skill you just defined, and the endpoint. This is the part participants skip when they're rushing — don't. A vague or incomplete Agent Card is a realistic failure mode, and you'll feel why once Part 2 can't find your agent.
5. Save and activate the workflow.

Part 2 — Build the Workout Agent stand-in (15 min)

6. Create a second workflow. Name it FitPath — Workout Agent (A2A client).
7. Add an A2A Client Agent node.
8. Point it at your Nutrition Agent's endpoint from Part 1.
9. Construct a task: "Sam Whitaker just logged a high-intensity leg day — request a meal plan adjustment."
10. Send it.

Part 3 — Run it and watch the round trip (10 min)

11. Trace the task through its lifecycle — submitted → working → completed — in the execution log.
12. Confirm the artifact that comes back is the actual meal suggestion from your Nutrition Agent, not a generic response.
13. If it fails: before you touch anything, look at where it failed. A rejected connection, a missing skill match, and a malformed Agent Card all fail differently — that difference is the diagnostic information.

Part 4 — Save your artifact (10 min)

14. In a new note (or at the bottom of your workflow's sticky note in n8n), record:

Your final Agent Card JSON

The task you sent and the artifact you got back

One sentence: what's actually different about this, compared to adding "nutrition" as a tool on your Day 4 MCP server?

If you finish early, see the Extension section below before asking your facilitator what to do next.

You're done when:

• Your Nutrition Agent has a valid, complete Agent Card declaring one real skill.
• Your Workout Agent stand-in successfully sends a task via the A2A Client node and receives a completed task with a real artifact — not an error, not a timeout.
• You can say, in one sentence, why this is architecturally different from what you built in Day 4.

A failed first attempt that you can diagnose (bad Agent Card, wrong endpoint, skill mismatch) is a legitimate outcome of this exercise — you'll be asked about it in the debrief either way.

Add a second skill to your Nutrition Agent — but make it one it probably shouldn't have, like "medical advice for injury-related nutrition." Don't build the logic behind it; just declare it on the Agent Card. Then answer for yourself: if your Workout Agent could see that skill was available, should it be allowed to call it automatically? What would you need to add — to either agent — before the answer is yes? Hang onto your answer; it'll matter again in Day 8.