Designing Agentic Workflows
An agentic workflow lets Claude choose and perform multiple steps toward an outcome — deciding what to look at next based on what it just found. That flexibility is genuinely powerful and genuinely easy to overuse. The craft of this lesson is knowing when you need it, and how to put walls around it when you do.
Three rungs, one task
Watch the same Northstar support job climb the ladder:
- A prompt. "Classify this ticket and draft a response." One transformation, human runs it, human judges it. If this works, stop here — most workflows in this program live happily on this rung.
- A fixed workflow. Every new ticket automatically flows classify → retrieve the matching KB article → draft → queue for agent review. The steps never vary; software glue runs them in order. More leverage, still fully predictable.
- An agent. The ticket mentions an error code, so Claude decides to check the known-issues list, finds a related outage, pulls the account's plan tier, and then drafts — choosing each step from what the last one revealed. Use this rung only when the path genuinely cannot be fixed in advance.
The rule: use the simplest design that works. Every rung up buys adaptability and costs predictability, and you pay the difference in testing and controls.
Placeholder: replace with a loop showing plan, approved tool, observation, check, and either stop or continue.
Define the operating envelope
An agent is a loop — plan, act through a tool, observe, check, continue or stop. The envelope is what makes the loop safe to run when nobody is watching:
- A precise goal and a named owner
- Approved inputs and tools — and nothing else
- Limits on records touched, time, cost, and number of steps
- A source-of-truth rule for conflicting data
- Stopping conditions, including "goal achieved" and "give up and report"
- Exception and failure behavior
- Human checkpoints before consequential actions
Every rule must be observable. "Stop after 20 steps" is enforceable; "be careful" is a hope. If you cannot write the rule as something a log could verify, the envelope does not contain it — no matter what the prompt says.
Evaluate the whole path
A demo shows one good run; an evaluation shows the distribution. Build a test set with typical cases, incomplete inputs, tool failures, conflicting data, and prohibited requests, then score: task completion, factual and source accuracy, correct tool selection, permission compliance, stop-and-escalation behavior, and the quality of the final handoff.
Re-run it after any change to prompts, tools, models, or source systems — agents are systems, and systems regress. The test set you built in your functional track is the seed; the failures you find here are cheap compared to the ones a customer finds.
Human checkpoints
Place approval immediately before each irreversible or consequential action: sending externally, changing a record, granting access, making a commitment, publishing, or affecting a person's rights or services. Position matters — a checkpoint three steps early approves a plan, not the action, and plans drift. The pattern that scales: the agent prepares everything, then presents one clear approve-or-reject decision with the evidence attached.
Practice
Draw your capstone workflow as a sequence on one page: every tool call, decision point, source, limit, approval, and possible failure. If it does not fit on the page, your first release is too big — shrink the scope, not the font.
Definition of done
The design sits on the lowest rung that works, runs inside an envelope of observable rules, has an evaluation set that probes its failures, and keeps final authority with the named owner.