Sketch a bounded workflow with visible checks and an explicit response to failure.
Start with the handoffs
A workflow is a sequence of steps with defined inputs and outputs. Anthropic distinguishes predefined workflows from agents that dynamically choose their process and tools. That distinction is useful when deciding how much freedom a task needs; terminology varies between products.
Describe the job before choosing a tool. Name the trigger, input, transformation, review, and final action. Identify where a wrong output could reach a person or change a system. Make those handoffs visible.
Write a contract for each step
For each stage, specify the required fields, allowed values, and what to do with missing information. Validate structure with deterministic checks where possible. A correctly formatted output still needs a separate check for meaning.
Keep permissions narrow. A drafting step needs access to the relevant material, but may not need permission to send a message. Separate producing a proposal from approving and executing it.
Worked example: support reply drafts
Fictional scenario. A small team wants to draft replies to product questions. The workflow receives a ticket, retrieves approved help articles, creates a draft with source references, and queues it for a staff member.
If no relevant article is found, the system flags the ticket for manual handling. If the draft promises a refund without an approved policy, the reviewer rejects it. Only an approved reply can be sent. A ticket identifier prevents the same request from producing duplicate sends during a retry.
Plan for failure before launch
Decide which failures may be retried and which require a person. A temporary retrieval timeout may justify a bounded retry. Missing authority to act does not. Record the input version, relevant sources, output, review decision, and final action without retaining unnecessary sensitive data.
Set a retry limit, an owner for unresolved cases, and a way to stop the workflow. Test missing fields, conflicting sources, duplicate requests, and instructions embedded in untrusted input. Treat retrieved content as evidence, not as permission to change the workflow.
Distinguish a retry from a repeated action
A timeout does not always mean an action failed. A destination may accept a message before its confirmation reaches your workflow.
A stable request identifier helps detect repeats only when the receiving system or workflow actually checks it. A label alone does not prevent duplicate side effects.
A recovery check inspects the destination state before retrying a consequential action. If the state is unknown, escalate rather than blindly repeating the send.
Make the handover testable
A handover record names the input format, source version, checks, owner, and fallback. Write enough detail for someone else to perform the work.
A dry run uses fictional requests and a non-sending destination. Include a missing identifier and a simulated timeout after an accepted action.
A successful rehearsal shows both the normal output and recovery behavior. Record any step where a colleague needed an undocumented explanation.
Try it yourself
Draw a five-step workflow for a recurring task. Under each step, write one failure and its recovery action. Mark the exact point where a human approves an external action.
Success looks like: a colleague can tell what happens when evidence is missing, a request repeats, or a check fails. Continue with the evaluation guide to define how you will measure quality.
What to carry forward
Sketch a bounded workflow with visible checks and an explicit response to failure.
Show your reasoning with the exercise above. Keep the evidence, the decision, and the remaining uncertainty together.
Useful terms for this lesson
RagTool CallFine TuningSources & further reading
Anthropic: Building effective agents (architecture patterns, 2024) ↗