1. What Actually Makes Something an "Agent"
"Agent" is used loosely enough to mean almost anything AI-adjacent, but the useful technical distinction is about who controls the sequence of steps: a workflow is a fixed sequence of LLM calls you wrote in advance; an agent lets the model decide its own next action based on what's happened so far, repeating until it decides the goal is met.
WORKFLOW (you control the sequence):
summarize(doc) -> translate(summary) -> format(translation)
# Fixed steps, fixed order, regardless of what each step returns.
AGENT (the model controls the sequence):
loop:
Claude decides: "what should I do next, given everything so far?"
Claude takes an action (a tool call)
Claude observes the result
Claude decides whether it's done, or needs another step
# This IS Week 7's tool-use loop — just run for longer, with less
# human review of each individual step along the way.
By that definition, most of what marketing calls "agents" is actually a workflow with an LLM step somewhere in it — which isn't a criticism, since a fixed workflow is often the right, simpler choice (more on that in Section 3). The word "agent" should be reserved for when the model is genuinely deciding its own next step.
The read-edit-run-verify loop from Week 10 is an agent by this definition — Claude decides what file to read next, what to edit, and whether the result is good enough, based on what it observes at each step, rather than following a script you wrote in advance.
2. Agent Design Patterns
Three recurring shapes, meant to be combined and adapted rather than chosen from a rigid menu:
# The tool-use loop from Week 7, with explicit reasoning between steps:
1. REASON: "The user wants X. I should check Y first."
2. ACT: call a tool to check Y
3. OBSERVE: read the tool's result
4. Repeat from REASON, now with that new information, until done.
# One "orchestrator" call breaks a big task into independent subtasks,
# dispatches each to a "worker" (a separate call, tool, or sub-agent),
# then synthesizes the results into a final answer.
#
# Example: "research this topic" -> orchestrator splits into 3
# sub-questions -> 3 worker calls research each independently ->
# orchestrator combines the findings into one coherent report.
# One pass produces an output. A second pass (a different prompt, or
# a different persona) evaluates it against explicit criteria. If it
# fails, the first pass retries with that feedback. Repeat until it
# passes, or a max-attempts limit is hit.
#
# Useful when output QUALITY matters more than speed — a piece of
# writing, a generated report, code that needs to satisfy real
# requirements.
Claude Code itself is roughly an orchestrator-worker/ReAct hybrid under the hood — these patterns aren't abstract theory, they're descriptions of what real, working tools already do.
If the same call both produces AND grades its own work with no independent criteria, it tends to grade itself generously. A useful evaluator pass needs explicit, checkable criteria — closer to a rubric than a vibe check.
3. When an Agent Is the Right Shape
Agents cost more than a fixed workflow: more tokens (more steps, more back-and-forth reasoning), more latency, and more failure surface — a wrong turn early on can compound silently across many subsequent steps before anyone notices, unlike a single call that either succeeds or visibly fails once.
USE A FIXED WORKFLOW WHEN:
- The steps and their order are known ahead of time
- You can write the sequence yourself without needing the model to
decide it dynamically
USE A GENUINE AGENT WHEN:
- The right next step genuinely depends on what a previous step
returned, in a way you can't predict and hard-code in advance
- The task needs to react to intermediate results, not just execute
a script
DEFAULT: start with the simplest thing that could work (a single call,
or a fixed workflow) — add agentic autonomy only once you've proven
that's genuinely insufficient.
Building an agent for a task that's really a fixed 3-step pipeline is a common over-engineering trap: it costs more, is harder to debug when something goes wrong, and gains you nothing since the steps never actually needed to be decided dynamically in the first place.
Regardless of pattern: a max-step limit, a timeout, and human-approval checkpoints for risky actions — mirroring Claude Code's permission model from Week 10 — so an agent that goes down a bad path can't spiral indefinitely before someone notices.
4. MCP as a Shared Tool Ecosystem
Week 11 introduced MCP as a way to connect Claude Code to external tools. At the architecture level, MCP's real significance is portability: an agent built in one framework or language can use the exact same MCP server as an agent built somewhere else entirely — the tool layer isn't locked to one specific agent implementation, the same way a website works the same in any standards-compliant browser.
# If you connect an MCP server to your own agent (or to Claude Code)
# for the capstone next week, that same server's tools would work
# unmodified if you later rebuilt the agent in a different framework.
# The tool definitions from Week 7 aren't wasted work tied to one
# specific implementation — they're a reusable asset.
This is why MCP has spread beyond just Claude Code — it solves a real, general problem (every agent needing its own bespoke tool integrations) with one shared protocol, the same practical motivation behind any standard.
The capstone asks you to ship a real agent or app using the Messages API, tool use, and everything from this module — this week's patterns and guardrails are exactly what you'll be applying, not additional new theory.
5. Hands-on Exercise
Classify a task, build a guarded ReAct loop, and design an orchestrator-worker breakdown
Move from concepts to a real classification and a real (small) implementation.
Part 1 — Workflow or agent?
- Pick 3 real tasks (from your own work or ideas) and classify each as "fixed workflow" or "genuine agent," using Section 3's checklist.
- For each, write one sentence justifying the classification.
Part 2 — A guarded ReAct-style loop:
- Extend Week 7's tool-use loop with at least 2 tools and a genuinely multi-step task (needs 2-4 tool calls to resolve).
- Add an explicit max-step guardrail: if the loop hits, say, 6 iterations without finishing, stop and report instead of continuing indefinitely.
A simple counter incremented each pass through your existing while loop from Week 7 is enough — the point is having ANY hard ceiling, not a sophisticated one.
Part 3 — Design an orchestrator-worker breakdown:
- Pick a research-style task (comparing 3 options, gathering info from several angles on one topic).
- Write out, in plain text, how an orchestrator would split it into worker subtasks and what it would need from each worker to synthesize a final answer. You don't need to implement this one — just design it.
6. Knowledge Check
Four quick questions. Expand each to check your answer.
Q1
What's the actual technical distinction between a "workflow" and an "agent" in this course's usage?
What's the actual technical distinction between a "workflow" and an "agent" in this course's usage?
Who controls the sequence of steps. A workflow follows a fixed sequence you wrote in advance. An agent lets the model decide its own next action based on what's happened so far, repeating until it decides the goal is met.
Q2
In the evaluator-optimizer pattern, why does the evaluator step need explicit, checkable criteria rather than just re-asking the same model "is this good?"
In the evaluator-optimizer pattern, why does the evaluator step need explicit, checkable criteria rather than just re-asking the same model "is this good?"
Without explicit criteria, the same process that produced the output tends to grade its own work generously — a vague self-check adds little value. A useful evaluator pass needs a concrete rubric to check the output against.
Q3
What's the recommended default when deciding whether a task needs an agent?
What's the recommended default when deciding whether a task needs an agent?
Start with the simplest thing that could work — a single call or a fixed workflow — and only add agentic autonomy once that's proven genuinely insufficient. Building an agent for a task whose steps are actually fixed and known upfront is a common over-engineering trap.
Q4
Why does MCP's portability matter beyond just Claude Code specifically?
Why does MCP's portability matter beyond just Claude Code specifically?
A tool exposed via MCP can be reused by any agent that speaks the protocol, regardless of framework or language — the tool layer isn't tied to one specific implementation, which turns tool-building work into a reusable asset instead of one-off integration code.