You have a prompt and context, and your LLM answers accurately. Then a user asks, “cancel my last order.” The system hits a wall. To do this, the software must look up a database row, evaluate a date against a refund policy, and issue a state-changing request to a billing API. That is more than retrieving text — it requires taking a sequence of steps. This is the boundary where you cross from text generation into agent territory.

An agent does not just output a response; it runs a process. It is an LLM wrapped in a control loop, given a goal and a set of tools. Crucially, it decides which tool to call, when to call it, and what to do with the result. If a lookup returns an error, the agent reads the exception, corrects its request, and tries again. It drives itself.

But autonomy introduces entropy. The moment an LLM decides what to do next, you add a failure mode. Hallucinated function arguments and runaway loops become real production risks.

You reach for an agent only when the system genuinely must direct itself. If a process is linear and predictable, write a plain code workflow. If a task requires real-time decisions, start with a single, well-scoped agent bound to a strict domain. The progression from deterministic code to a single agent to a coordinated set of agents is a ladder of fit, not of better — you move up only when the rigidity of the previous stage breaks under your requirements.