An agent is a model running a tool-use loop toward a goal. This module covers that loop, the MCP standard that connects agents to your systems, how to read a trace when one misbehaves, the four autonomy levels, and the failure modes to expect.
Everything in this track so far has treated AI as a very capable conversation partner: you ask, it answers, you verify. Agents change the contract. An agent doesn't just answer — it acts: it queries your ticket system, edits files, runs tests, and decides for itself what to do next based on what it observed. That shift from chat to action is why "agents" and "MCP" now appear by name in job postings across all twelve role families we researched — from cloud architects designing "multi-agent orchestrations" to QA engineers running "AI-agent-driven workflows" to support teams operating agentic service desks.
It's also why the skills in this module matter more than any framework: understanding the loop that makes an agent an agent, reading the trace when it misbehaves, choosing how much autonomy a task deserves, and knowing the failure modes before they find you in production.
An agent is a model running a tool-use loop toward a goal. Everything else — frameworks, protocols, orchestration patterns — is packaging around that loop. Learn the loop, the trace, and the autonomy decision, and every vendor's agent product becomes legible.
Strip away the branding and every agent — coding agent, research agent, support agent — is the same machine:
GOAL: given by a user or a triggering system
loop:
PLAN the model decides the next step toward the goal
ACT the model emits a tool call (search, read file, query API)
OBSERVE the tool result is appended to the context
ITERATE the model re-plans with the new evidence
until: goal met, budget exhausted, or a human intervenes
Three properties make this loop more than a chatbot with functions attached:
This yields the distinction the industry settled on around 2025: in a workflow, your code orchestrates LLM calls along predefined paths — the model fills in steps, you own the graph. In an agent, the model directs its own process and tool usage — you own the boundaries, it owns the path. Neither is superior; workflows are predictable and testable, agents handle open-ended problems workflows can't enumerate. If you can draw the flowchart in advance, you want a workflow.
"Agent" is not a prestige label. A fixed chain that summarizes, then classifies, then routes is often the better design — cheaper, testable, debuggable. Reach for an agent only when the step count and order genuinely can't be known in advance.
Module 4 covered function calling from the API side; here is the sixty-second version that agents build on. A tool is a capability you describe to the model with a name, a natural-language description, and a typed parameter schema:
{
"name": "search_tickets",
"description": "Search support tickets by status and date range. Returns at most 20 results, newest first.",
"input_schema": {
"type": "object",
"properties": {
"status": { "type": "string", "enum": ["open", "pending", "resolved"] },
"since": { "type": "string", "description": "ISO date, e.g. 2026-07-01" }
},
"required": ["status"]
}
}
The model never executes anything. It emits a structured request to call the tool; the harness validates it, runs the real code, and returns the result as an observation. That separation is the security boundary — and the reason the description field matters so much. The model chooses tools by reading descriptions the way a new hire reads documentation: vague descriptions produce "dumb" agent behavior far more often than weak models do.
Chat with function calling stops there — one question, maybe one tool call, one answer. An agent puts the same mechanism in a loop, chaining as many calls as the goal requires.
Before 2025, connecting AI applications to tools was an M×N problem: every app (M) hand-wired every integration (N). Your Jira connector for one assistant didn't work in your IDE; the IDE's database plugin didn't work in your chat app. Integration effort multiplied instead of accumulating.
The Model Context Protocol (MCP), open-sourced by Anthropic in late 2024, collapsed M×N to M+N. It's an open client-server standard: a server wraps a system once and exposes three kinds of things —
— and any MCP-compatible client can consume them with no bespoke glue. Write one MCP server for your internal order system and every agent surface in the company can use it.
The reason we teach MCP by name rather than as "a protocol": it won. The official project describes it as "like a USB-C port for AI applications," and by 2026 the support list spans the industry — Claude and ChatGPT among assistants; VS Code, Cursor, and other development tools; plus the major agent frameworks and cloud agent platforms. Employer postings reflect the same convergence: MCP appears verbatim in cloud architecture, QA, and platform engineering listings. For your career, that means MCP knowledge transfers across employers and vendors in a way framework knowledge doesn't.
Two working-professional implications:
MCP servers run with the permissions of the credentials they're given. Connecting a server to an agent is granting access, not installing a feature — apply the same scrutiny you'd apply to granting a new hire those credentials, and prefer read-only scopes until trust is earned.
When an agent misbehaves, the answer is almost never in the final output — it's in the trace: the step-by-step record of plans, tool calls, and observations. Reading traces is to agent work what reading stack traces is to programming, and it's the skill interviewers probe when they ask "how would you debug this agent?"
Here's a compact trace from a ticket-triage agent asked to "summarize today's urgent open tickets and draft a status note":
[1] PLAN: Search open tickets marked urgent from today.
[1] TOOL: search_tickets(status="open", since="2026-07-24")
[1] OBS: 20 results (truncated). None have priority field in output.
[2] PLAN: Priority not visible; search again filtering by "urgent".
[2] TOOL: search_tickets(status="open", since="2026-07-24")
[2] OBS: Same 20 results.
[3] PLAN: Try keyword search for "urgent" in ticket body.
[3] TOOL: search_tickets(status="open", since="2026-07-24")
[3] OBS: Same 20 results.
[4] PLAN: I'll infer urgency from ticket titles and draft the note.
[4] OUTPUT: "7 urgent tickets today: ..." (list inferred from titles)
A trained eye extracts four findings in thirty seconds: the tool result omits the priority field the task needs (a tool design problem); the agent retried an identical call twice hoping for a different answer (an incipient loop); it never had a tool that filters by priority (a capability gap); and rather than reporting the gap, it silently downgraded to guessing (an honesty problem — the output looks confident and is partly fabricated). The fix is in the tools and instructions, not the model: return the priority field, add "if you cannot determine urgency, say so" to the system prompt.
That's the general method: read the trace before blaming the model. Ask, in order — did it have the right tools? Did the tool results contain what it needed? Did it use results correctly? Did it stop, loop, or drift? Most "the agent is dumb" complaints dissolve into a fixable tool description, a missing field, or an instruction gap.
When evaluating agents (Module 6 methods apply directly), grade the trajectory, not just the outcome: right tools chosen, no flailing, no forbidden calls, reasonable step count. Two agents can produce the same answer where one took 4 sensible steps and the other took 19 lucky ones — only the trace tells you which you can trust in production.
The most consequential design decision in any agent deployment is not the model or the framework — it's how much the agent may do without you. Four levels cover practice:
| Level | The agent may... | A human... | Fits |
|---|---|---|---|
| 1. Draft-only | Read and propose; never execute writes | Executes everything | New workflows, high-stakes domains, building trust |
| 2. Approve-each-action | Execute, but each side-effecting call pauses for approval | Approves every write | Actions with real but recoverable consequences |
| 3. Bounded autonomy | Act freely inside hard limits (allowed tools, spend caps, step budget, reversible actions only) | Reviews outcomes; gates the irreversible | Mature workflows with a verified track record |
| 4. Full autonomy | Act end-to-end, including irreversible actions | Audits after the fact | Rare; only where errors are cheap and reversible |
Two rules make the choice principled rather than vibes-based:
send_email and delete_record tools sit permanently at level 2. Classify every tool by blast radius: reversible-and-cheap runs free; irreversible-or-expensive proposes and waits.One implementation principle from hard-won industry experience: the gate lives in code, not in the prompt. An agent instructed "always ask before sending email" will eventually not ask. An agent whose send_email tool returns PENDING_APPROVAL until a human clicks cannot skip the gate. Prompts shape behavior; harnesses guarantee it.
Agents inherit every LLM failure mode from earlier modules and add four of their own. Honest practitioners know this catalog cold — defensively, because you'll be the one operating these systems.
Never give one unattended agent the combination of (a) access to untrusted external content, (b) access to sensitive data, and (c) the ability to communicate externally. That triad is the standing precondition for injection-driven data exfiltration, and every serious deployment review checks for it.
Separating deployment reality from demo reel is itself a professional skill, so here is the honest map.
Working in production today — the pattern behind all of these is checkable outcomes plus bounded scope:
Where the hype outruns the evidence: open-ended "autonomous employee" agents, unbounded multi-agent swarms, and anything requiring long-horizon judgment with irreversible actions and no human gate. The macro data backs the caution: McKinsey's research on gen AI at work finds that most organizations remain stuck at pilot stage, and that the strongest predictor of profit-and-loss impact is redesigning the workflow around the capability — not the raw deployment of agents. An MIT-affiliated 2025 analysis that circulated widely put the share of enterprise gen AI pilots showing no measurable P&L return around 95%. Read both claims the way Module 6 taught you to read any number — methodology matters — but the direction is consistent with what practitioners see: agents pay off where teams re-engineer the process, instrument it with evals, and keep humans on the irreversible actions; they stall where teams bolt an agent onto an unchanged process and hope.
The professional takeaway: when someone proposes an agent, ask the four questions from this module. Is the outcome checkable? Is the scope bounded? Where are the human gates? What does the eval say?
You can experience the full loop — including the failure modes — this week without spending anything. Three vendor-neutral paths; any one suffices:
search over a local folder, save_file gated behind a typed "yes"), a 10-step cap, and a printed trajectory log. Nothing demystifies agents faster than implementing the harness once.Whichever path you take, do the module's signature exercise on the result: read the trace and name what you see.