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.
- The design makes a hidden tradeoff measurable before it reaches users.
- A clear boundary reduces retries, unsafe actions, or unnecessary capacity.
- The operating choice should be tested against the workload rather than assumed from a demo.
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.
- The example names the input, decision, and expected boundary.
- A deterministic or human checkpoint owns the part a model should not guess.
- The result can be measured with quality, latency, safety, and cost metrics.
Example figures are illustrative calculations, not current quoted market prices.
Current example
Primary reference
This source explains the method or risk boundary. It does not replace testing the actual model, data, provider, and workload conditions in production.
Source discipline: examples on this page are illustrative; measure the real workload before making a release or capacity decision.
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.
- Start with a narrow workflow and explicit failure boundary.
- Instrument the path before optimizing it.
- Review the design whenever model, tool, traffic, or policy changes.
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