Designing Agent Workflows

The concept

The previous lesson defined an agent as an LLM plus tools plus a loop. This lesson is about designing that loop on paper before you build anything — because the single biggest cause of a bad agent isn't a weak model, it's a workflow that was never actually designed, just assembled step by step until it technically ran.

A workflow design has five parts, and skipping any one of them is where things go wrong later. Trigger — what starts the agent: a new form submission, a scheduled time, an incoming email, a human typing "go." Goal — a specific, checkable definition of "done," not a vague aspiration ("reply to the customer" is vague; "draft a reply that answers their question and flags the order number for human review" is checkable). Steps — the ordered sequence of observe/decide/act loops from the previous lesson, written out as a numbered list, not left implicit. Tools — exactly which tool each step calls, and nothing more; an agent with access to tools it doesn't need for this task is a wider attack surface and a wider blast radius if it misfires. Approval gates — the points where a human must review before anything irreversible happens.

The design discipline that matters most: start with the riskiest step, not step one. Before writing out the happy path, ask "which single step in this workflow, if it goes wrong, causes real damage?" — sending an email to the wrong person, deleting a file, charging a card, posting publicly. Design the approval gate around that step first, then build the rest of the workflow around the gate you've already placed. Workflows designed in step order (1, 2, 3...) tend to bolt the safety check on at the end, almost as an afterthought; workflows designed risk-first build the whole structure around the one place it actually matters.

A workflow with no approval gate isn't automatically unsafe — a read-only research agent that only ever produces a summary for you to read has nothing irreversible to gate. But the moment a workflow can send, post, pay, delete, or publish, the gate is not optional, no matter how reliable the agent has seemed so far. Reliability in testing is not the same as safety by design; a gate costs a human a few seconds of review and prevents the one bad run that testing didn't happen to surface.

Worked example

A learner sketches a workflow for "new customer inquiry → agent drafts a reply → human approves → agent sends." Walking through the five parts: trigger is a new email landing in a specific inbox folder. Goal is "a reply drafted that answers the customer's actual question, in the company's tone, with any order or account details correctly pulled from the CRM." Steps are: (1) read the incoming email, (2) look up the sender in the CRM if an account number is mentioned, (3) draft a reply using the company's tone guide, (4) present the draft to a human. Tools are email-read, CRM-read (not write), and a drafting step using the LLM itself — notably, no email-send tool is given to the agent at all for this version. Approval gate: a human reads the drafted reply and either sends it, edits it, or discards it — the agent never has the ability to send on its own.

The learner originally sketched the workflow with the send step included as something the agent does automatically "for simple inquiries" and only the "complex" ones routed to a human. Reviewing it against the risk-first principle, they realize "simple" is a judgment call the agent itself would be making about its own output — exactly the kind of self-graded shortcut that erodes a safety design. They remove automatic sending entirely: every drafted reply goes through the same human gate, regardless of how simple the agent judges the inquiry to be.

Exercise

Pick a repetitive task from your own job — the same kind of candidate task used in the previous lesson's exercise (checking an inbox for invoices, monitoring competitor pages, drafting routine replies, compiling a weekly report). Sketch a full workflow design covering all five parts: trigger, goal (written as a specific, checkable sentence, not a vague aspiration), steps in order, the exact tool needed at each step, and at least one explicit human-approval gate.

Before finalizing it, apply the risk-first check: identify the single step in your sketch that would cause the most damage if the agent got it wrong, and confirm your approval gate sits directly in front of that step — not somewhere earlier or later in the sequence where it would miss the actual risk. If your gate is in the wrong place, move it.

Recap

• A workflow design has five parts — trigger, goal, steps, tools, approval gates — and skipping any one is where agents go wrong later.
• Design risk-first: find the most damaging possible step before sketching the happy path, and build the approval gate around that step first.
• Reliability in testing doesn't replace a gate — the moment a workflow can send, post, pay, delete, or publish, a human checkpoint is not optional.

Resources

• Anthropic: "Building effective agents" — https://www.anthropic.com/research/building-effective-agents
• Zapier: "What is workflow automation?" — https://zapier.com/blog/workflow-automation/
• Make: "Scenario design best practices" — https://www.make.com/en/help/scenarios