"Agent" has become the default word for any AI project, which is expensive, because agents are the most costly shape to build and most problems do not need one. Here is how to tell which shape you actually have.
Three shapes, three costs
A feature calls a model once and returns text: summarise this, classify that, draft a reply. It is a function call with a probabilistic implementation, and it can be built and evaluated in days.
An assistant holds a conversation and answers from your data. It needs retrieval, grounding, citations, and a refusal path, but it does not change anything — the worst case is a wrong answer a person can check.
An agent takes actions. It calls tools, queries systems, and completes multi-step tasks with side effects. The worst case is no longer a wrong answer; it is a wrong action against a real record, which is why agents need permissioning, audit trails, approval steps, and rollback. That is most of the extra cost, and none of it is optional.
The question that sorts them
Ask what the system does that a person would otherwise have done, and then ask whether that thing changes state anywhere.
If nothing changes — the output is read by a human who then acts — you have a feature or an assistant, and you should build that. If something changes, and especially if that change is hard to reverse, you have an agent and you should budget for the machinery agents require.
The expensive error is building agent infrastructure for a system that only ever produces text, because someone described the project with the word agent in the first meeting and nobody revisited it.
Multi-step is not the same as agentic
A pipeline that extracts fields from a document, validates them, and writes a row is multi-step, and it is not an agent — the steps are fixed and you wrote them. Determinism is a feature here: you can test each stage, and it fails in the same place every time.
It becomes an agent when the model decides which step comes next. That flexibility is genuinely valuable when the path cannot be enumerated in advance, and it is a liability when it can, because you have traded a testable pipeline for a system that takes a different route each run. If you can write the flowchart, write the flowchart.
Start one shape down
The pattern that works is to build the simplest shape that could plausibly be enough, put it in front of users, and let the failures tell you what to add. A summarisation feature that people use daily teaches you more about the domain than an agent design document, and it ships in a fraction of the time.
It is also the cheaper direction of travel. Growing a feature into an assistant, and an assistant into an agent, is ordinary incremental work. Discovering three months into an agent build that the useful part was a single well-placed feature is a write-off.
If it really is an agent
Then the non-negotiables are: every tool call logged with its arguments and result, permissions scoped so the agent can only reach what the task needs, human approval on anything irreversible, and a defined fallback when a tool is unavailable.
Build those first, before the capability. Retrofitting an audit trail onto a working agent is difficult and it never gets prioritised over the next feature, which is how agents end up in production with no record of what they did.