Why most "agents" are just prompts in a loop

The word "agent" stopped meaning anything useful around the time every demo started using it. A chatbot that calls one function is an agent. A script that retries a prompt is an agent. If everything is an agent, the word tells you nothing about what you are looking at.

Here is the line I draw.

The test I use

An agent decides what to do next based on what it just learned. A prompt in a loop runs the same plan every time and hopes the inputs change.

That sounds small. It is not. It changes how you build, how you debug, and how it fails in production.

What a loop actually looks like

Most "agents" I review are a fixed sequence dressed up as autonomy:

1. Take the user input.
2. Stuff it into a template.
3. Call the model.
4. Parse the result.
5. Maybe call one tool.
6. Return.

There is no branching that the model controls. The developer wrote the plan. The model fills in blanks. This is fine. A lot of useful software works this way. The problem is calling it an agent, because that word makes people expect it to handle situations the developer never planned for, and it cannot.

What changes when it is a real agent

A real agent owns the control flow. It looks at the current state, picks a tool, reads the result, and decides whether it is done or needs another step. The number of steps is not fixed. The order is not fixed. You wrote the tools and the goal, not the path.

That power is also the cost. Now you have to handle:

• Loops that never terminate
• Tool calls that contradict each other
• A model that confidently picks the wrong next step
• State that grows until it blows the context window

None of those problems exist in a prompt loop, because a prompt loop cannot surprise you. That is the trade. Autonomy buys you flexibility and hands you a much harder debugging job.

Why the distinction matters

If you ship a prompt loop and call it an agent, you will set expectations you cannot meet. Someone will throw a case at it that needs a decision the loop cannot make, and it will fail in a way that looks dumb, because it is doing exactly what you told it to do.

Decide which one you are building before you build it. If the task has a fixed shape, write the loop and keep the control in your code. If the task genuinely needs the model to choose its own path, build the agent and budget for the hard parts. Picking the wrong one is how you end up with a system that is both more complex than a loop and less reliable than one.