What Is an AI Agent? And When You Actually Need One

The one-sentence definition

An AI agent is a language model placed in a loop where it chooses its own next action. Give it a goal and a set of tools — search the web, query a database, send a request, read a file — and it decides which tool to use, sees the result, and decides again, continuing until it judges the goal met or a limit stops it. The difference from ordinary AI usage is not intelligence but control flow: in a normal feature you decide the steps, and in an agent the model does.

What the loop actually looks like

Mechanically it is unglamorous. Your code sends the model the goal, the conversation so far, and a description of the available tools. The model replies either with a final answer or with a request to call a tool and some arguments. Your code executes that call, appends the result to the conversation, and sends it back. Repeat. Everything people call agentic — planning, reflection, self-correction, multi-agent delegation — is a variation on what you put in that loop and what you let the model call.

Why the loop is the whole problem

Handing control to the model buys flexibility and costs predictability. A scripted pipeline with five steps runs five steps. An agent with the same tools might take three steps or forty, cost ten cents or nine dollars, and take two seconds or four minutes — on the same input, on two different days. It can also loop: two agents politely deferring to each other, or one retrying a failing call indefinitely because retrying seemed reasonable. This is why every serious agent implementation has hard caps on steps, tokens, time, and spend, and why those caps are not optional polish.

Where agents genuinely earn their keep

Agents pay off when the number and order of steps cannot be known in advance. Investigating a support ticket where the next question depends on the last answer. Researching a topic where you cannot say beforehand which sources will matter. Working through a codebase where the fix location is unknown. In each case a script would need a branch for every eventuality, and enumerating them is harder than letting the model decide.

Where they are the wrong tool

If you can write the steps down, write them down. A pipeline that extracts fields from an invoice, validates them, and writes a row is cheaper, faster, testable, debuggable, and identical on every run. Wrapping that in an agent adds cost and variance and removes your ability to reason about what happened. The most common expensive mistake in this space is an agent doing a job a deterministic pipeline with one model call in the middle would have done better.

The things that go wrong in production

Three failures recur. Context growth: every tool result is appended, so a long run gets slower and more expensive with each step, and important early instructions drift toward the middle of the window where models attend to them least. Compounding error: a wrong step is not corrected, it is built upon. And silent tool failure: an API returns an empty result, the model treats absence as an answer, and reports something confident and wrong. All three are why observability — logging every step, every tool call, every result — is the first thing to build, not the last.

Deciding whether you need one

Two questions settle it. Can you enumerate the steps? If yes, build a pipeline. If no, can you tolerate a variable number of model calls, a variable bill, and a variable answer? If also no, then the honest conclusion is that the problem is not ready for an agent, and narrowing the scope until the steps are enumerable is the cheaper path.

A reasonable starting point

Begin with the smallest agent that could work: one model, three or four tools, a hard step limit, full logging, and a human reviewing the output before it acts on anything. Add autonomy only where the logs show it is warranted. Almost every team that starts at the other end — many agents, many tools, no limits — spends its first month removing capability rather than adding it.