Lesson 16.1 gave you the map: the agent works through the MCP shelf, the server calls the provider's API, the service returns JSON. This lesson walks one road all the way to the end — "Which deployments failed today, and what changed before they failed?" — watching each handoff and where it can break.

The question

It is late afternoon. Your preview site looks wrong. You turn to your coding agent and say:

That sentence already does three jobs. It states the task (find failed deployments and prior changes), the evidence it expects (names, times, errors), and a stop condition (propose; do not act). Every trace in this lesson starts with a human who asked for something checkable.

The trace, handoff by handoff

Here is the full path — a chain of handoffs, each one a place the system can succeed or fail:

Human → agent → MCP client → MCP server → provider API → service
  → JSON response → MCP server → agent → human (summary + proposal)

1. Human gives task and desired evidence. You asked for failed deployments *today*, the changes before each failure, and cited evidence — not a vague "check deployments." Precise requests produce traceable work; vague ones produce guesses.

2. Agent chooses a deployment tool. The host shows the agent its connected servers and tool lists: a filesystem server, a Git server, a deployment server with list_deployments and get_deployment_logs. The agent reasons: the question is about deployments, so list_deployments with a since: today filter is the right first call. This choice can be wrong — a confused agent picks the wrong tool the way a new hire pulls the wrong report.

3. MCP server validates inputs. The agent requests list_deployments with named fields: project, since, status_filter. The server checks those fields against the tool's schema. A malformed tool call is rejected here, before any service is touched.

4. Server calls the provider API with authentication. The server translates the validated tool call into the provider's real API request: endpoint, method, authorization headers, date-range parameters. The token identifies *which account* is asking; the scopes decide *what it may see*.

5. Provider service returns structured data. The service checks the request and returns JSON: three deployments today, one failed at 14:12 with a build error, plus identifiers for follow-up. The response carries a Class 13 status code: 200 on success, 401/403 on identity and permission problems, 429 when rate-limited, 5xx when the provider is down.

6. Agent follows up with evidence. The agent calls get_deployment_logs for the failed deployment ID, then asks the Git server for commits in the hour before 14:12. Each follow-up repeats the same loop: choose tool, validate, authenticate, receive JSON.

7. Agent summarizes and proposes. "Deployment web-preview-a3f9 failed at 14:12 with Module not found: ./pricing. The commit 20 minutes earlier renamed that file without updating the import. Proposed next step: fix the import and redeploy the preview — say the word and I'll draft the change." It cites names, times, and error text. It proposes rather than redeploys, honoring your stop condition.

Every boundary where it can fail

A trace is only useful if you can say *where* it broke. Seven boundaries — your debugging checklist:

Walk failures in order. Check the cited evidence first (boundary 7), then data completeness (6), service health (5), the request itself (4), permissions (3), tool choice (2), and then the model (1). Beginners do this backwards — blaming the model for an expired token or a wrong date filter.

Two rules apply at full force. From Class 13: an agent should report the response and propose the next step, not silently retry destructive actions. From Class 14: every consequential action needs its approval gate. "Propose, don't execute" is the boundary between a debuggable assistant and an incident.

Why logging makes the agent debuggable

Each handoff can be logged: which tool the agent chose and with what inputs, what the server validated, the API request and status, the JSON, the final summary. That log turns the agent from a black box ("it said the deploy failed") into a system you can inspect ("it called list_deployments with since=today, got 200 with three records, then fetched logs for a3f9").

This is the Class 7 system model with names on every arrow: a model never acts alone — it reasons inside a larger system of inputs, instructions, tools, and outputs. And it points forward to Agents (Part VIII), where this loop — observe, choose a tool, act, read the result — runs continuously. Learn to read one loop now and the multi-step agent later will feel familiar.

Check your understanding

1. Which layer validates the tool-call inputs, and which verifies the caller's identity? 2. Your agent reports "no failed deployments" but you know one failed. Which two boundaries do you check first? 3. Why must a failed write action be reported with a proposal rather than silently retried?

Practical exercise: turn a vague request into a trace

Take this vague request — *"My app is slow — go fix it"* — and rewrite it as a traceable job with six parts:

1. Question restated precisely (what "slow" means, which app and environment, what time window). 2. Likely tool the agent should choose first, and why. 3. Data/service underneath the tool (what the server will actually query). 4. Return format you demand (metrics, timestamps, IDs — the evidence, not a vibe). 5. Verification step (how you will confirm the answer before acting). 6. Stop condition (what the agent must not do without your word).

Finish line: a one-page trace with those six labeled parts, written so another student could execute it. If any step's success is uncheckable, tighten the evidence it demands.

Next, Lesson 16.3 teaches the judgment call behind every trace: which connection — manual, direct API, MCP, custom, or nothing — each job deserves.