Anthropic: Building effective agents
Primary guidance on simple workflows, tool use, orchestration, and adding autonomy only when it creates measured value.
← Back to Compute College
Compute College
When not to build an agent
Choose a deterministic workflow when autonomy adds cost, uncertainty, or risk without enough benefit.
Plain-English definition
Do not build an agent when the task has a known sequence, stable rules, predictable inputs, and no need for the system to choose among actions dynamically. A workflow, validator, search system, or ordinary program may be easier to test, cheaper to run, and safer to operate.
Memory trick: Use autonomy for uncertainty, not decoration.
Why it matters
Autonomy is valuable only when it solves uncertainty that simpler designs cannot handle. Every extra decision loop adds latency, tokens, tool failures, authorization questions, and debugging work.
Simple example
A monthly invoice process always extracts fields, checks totals, compares them with a contract, and routes exceptions. A fixed pipeline with deterministic arithmetic and human review for exceptions is more transparent than an agent deciding the next step for every invoice.
Example figures are illustrative calculations, not current quoted market prices.
Current example
Source material
Common mistake
Autonomy is not automatically an upgrade. If the workflow is known and rules are clear, an agent can make reliability and cost worse.
Practical takeaway
What you can do with this
Write the fixed workflow first. Add an agent only at the step where uncertainty is real, then compare the complete design on quality, cost, latency, and failure handling.
Decision check: what decision is genuinely uncertain, and why can a workflow or rule not handle it?
Compute College learning path
AI Engineering
Step 28 of 48: When not to build an agent