Should It Be an Agent?

The honest rule

Build an agent only when the next step depends on what the system discovers while working. If the order is known ahead of time, the system is probably a workflow. If the model only needs to rewrite, classify, summarize, or answer once, the system is probably a prompt. Calling something an agent does not make it more capable; it often just makes it harder to test.

Anthropic's agent guidance draws a useful line between workflows and agents. Workflows orchestrate LLMs and tools through predefined paths. Agents direct their own process and tool use over several turns. That is the trade: more adaptability, less determinism. The engineering job is to buy only as much adaptability as the user needs.

The decision tree

Run the idea through these questions in order. Can the user get value from a single model call? If yes, stop. Does the process have a fixed sequence? If yes, write normal code and insert model calls only where judgment is needed. Does the task involve branching, retrying, searching, or selecting tools based on observations? Then an agent may be justified.

Signals that an agent is justified

Good agent candidates usually have four traits. They require several steps. They need external tools or data. The right next step is not always knowable before the previous step completes. And the value of a completed task is high enough to pay for evaluation, monitoring, and failure recovery.

• A support triage system that must inspect tickets, search docs, draft a reply, and escalate uncertain cases.
• A research assistant that gathers sources, detects conflicts, asks follow-up questions, and writes a sourced brief.
• A code maintenance agent that can read files, run tests, apply small patches, and stop for human review.
• A back-office operations agent that compares records, drafts updates, and routes exceptions to specialists.

Signals that it should not be an agent

Many AI features need reliability more than autonomy. If a user uploads a receipt and wants fields extracted, build extraction. If a product needs to classify leads and notify sales, build a workflow. If a customer asks a question and the answer lives in a fixed knowledge base, build retrieval plus answer generation. Agents are not a substitute for product clarity.

The risk line

The risk question is not "can the model do it?" The risk question is "what happens if it does the wrong thing with the tools we gave it?" A read-only research assistant has a different risk profile from an agent that sends email, changes billing state, deletes records, deploys code, or spends money. OWASP calls out excessive agency because too much permission turns ordinary model errors into real-world damage.

A sane first version is often read-only. Let the agent inspect, plan, cite, and propose. Require human approval for side effects. Once traces show the same decisions are reliably safe, move one approval boundary at a time.

Decision output

End the decision process with a written verdict. Name the system form, the reason, the tools, the permissions, the approval gates, the evaluation fixtures, and the specific thing you are refusing to automate. This verdict becomes the opening section of the implementation spec and prevents framework enthusiasm from taking over the design.