Name the business state that may change.
Reading a document and updating a customer record are different operations. Write down every external action the workflow can take, its required inputs and the effect it has. Make the boundaries understandable without reading a prompt.
Use a workflow when the path is known.
Anthropic distinguishes predefined workflows from agents that choose their own steps. That distinction is useful during scoping: if the path is stable and rules are known, start with explicit orchestration. Add model-directed decisions only where they solve a concrete problem.
Validate before an action crosses a boundary.
Treat generated arguments as proposals. Check identifiers, required fields and allowed values in code. Approval should show the proposed change and relevant evidence so that a person can review the actual effect.
Design the second attempt.
A timeout does not always mean an operation failed. Before retrying, consider how to detect whether the action already happened. Use the destination system’s supported deduplication or idempotency mechanisms where available, and define a review path where they are not.
Make stopping a successful behavior.
An unknown state, missing permission or ambiguous request should have a defined outcome. Record why the workflow stopped, what has already happened and what a person needs to resolve. A clear handoff is often more useful than another speculative tool call.
Further reading
This note presents our suggested working method. For broader architectural guidance, see Anthropic: Building effective agents ↗.
PUT IT TO WORK
Review production readiness ↗