From workflow to agent

"Agent" is the most abused word in AI, so let's define it by what changes in your code. In a workflow, you orchestrate: your program decides the steps and calls Claude inside them. In an agent, Claude orchestrates: it decides which tools to use, in what order, reacting to what it finds, until the task is done — and your program becomes the loop and the guardrails around it. You already built the mechanical core in the tools lesson; this lesson is about when to build one, the workflow patterns to exhaust first, and the design decisions that separate agents that ship from agents that flail.

Most tasks don't need an agent

The agent tax is real — higher cost, higher latency, wider variance — so it must be paid for by the task. Four questions, and "no" to any of them means stay with a workflow:

• Complexity: is the task genuinely open-ended, impossible to fully specify as steps in advance? "Extract these five fields" is a workflow. "Find why checkout latency doubled last Tuesday" is agent-shaped.
• Value: does the outcome justify tens of times the tokens of a single call?
• Viability: is the model actually good at this class of task? Prototype the hardest instance first.
• Cost of error: can mistakes be caught — tests, review, rollback — before they matter? An agent whose errors are invisible or irreversible is a liability regardless of its skill.

The five workflow patterns to exhaust first

Before the loop, learn the shapes your own code can orchestrate — they cover most production systems, compose freely, and stay debuggable because you own the control flow:

• Prompt chaining — decompose into sequential calls, each consuming the last one's output: draft, then check, then polish. Wins whenever one mega-prompt is doing three jobs badly.
• Routing — a small, cheap model classifies the request and dispatches to the right specialist prompt and model. This is the pattern behind the models lesson's "Haiku at the front door".
• Parallelization — independent calls fan out concurrently and merge: evaluate ten documents at once, or ask three differently-prompted graders and vote.
• Orchestrator–workers — a capable model decomposes the task and delegates sub-tasks; unlike plain parallelization, the model decides the split. The bridge to true agents and to the multi-agent lesson later.
• Evaluator–optimizer — one call generates, another grades against explicit criteria, and the loop repeats until pass. Your first taste of evaluation-as-steering, which the testing lesson industrialises.

The rule: use the simplest pattern that fits, compose before you escalate, and reach for the agentic loop only when steps genuinely cannot be scripted in advance.

Design the tool surface like an API you must live with

An agent is only as good as what it can see and do, and the highest-leverage design decision is which tools to expose at what granularity. The trade is between breadth and control. A general tool like bash or run_query gives the agent enormous reach, but hands your harness an opaque string — hard to gate, hard to audit. A dedicated tool — send_refund(order_id, amount) — gives the harness typed, action-specific hooks: you can require human approval on exactly this call, log it, or cap the amount, none of which is possible when the same action hides inside a shell command.

The working rule: start broad for capability, then promote to dedicated tools every action that needs gating, auditing, or guaranteed structure — and gate anything irreversible behind confirmation. This is also where strict: true schemas and when-to-use descriptions from the earlier lessons compound: in an agent loop, a mis-triggered or mis-argued tool call doesn't just fail once, it sends the whole trajectory sideways.

Guardrails are the actual engineering

The loop is ten lines; the production engineering is the envelope around it. Cap iterations, tokens, and wall-clock so no run is unbounded. Route irreversible actions through confirmation. Log every tool call with its arguments — that trace is your only debugging tool when run #400 goes strange. And require the agent's claims to be backed by tool evidence: an instruction as simple as "before reporting done, verify by running the tests, and report the actual output" collapses the failure mode where an agent narrates success it didn't check. Trust comes from the harness, not from hope.

What to take into the next lesson

Four questions decide whether to build an agent; five patterns cover what your own code should orchestrate first; tool-surface design and guardrails are where the real engineering lives. One accelerant to remember: the Agent SDK packages a production-hardened harness — loop, built-in tools, permissioning, context management — and gets a full treatment in the automation lesson. First, though, the resource every long-running agent exhausts, and the discipline that has become its own field: context.