AI Agents, Explained: What They Actually Do and Where They Break

A chatbot answers. An agent acts. The mechanical difference is smaller than the marketing suggests: you give a language model a set of tools it can call, put it in a loop, and let it decide what to do next based on what happened last. That is the whole architecture. Everything interesting, good and bad, follows from it.

What the loop buys you is work that does not fit in one answer. Reading a repository, changing three files, running the tests, reading the failures, and trying again is not a question with a reply; it is a sequence where each step depends on the result of the last. Agents are genuinely good at that shape of task, which is why the first places they landed commercially were coding, customer support triage, and data gathering.

What the loop costs you is error compounding. If a model is right 95% of the time on a single step, a twenty-step chain is close to a coin flip, because a wrong turn at step three is not corrected at step four, it is the premise of step four. This is the single most useful thing to understand about agents: their reliability is not the model's accuracy, it is the model's accuracy raised to the length of the chain. Shorter chains with checkpoints beat longer autonomous runs, and that is a design decision, not a model limitation.

The second cost is that an agent's blast radius is whatever you connected it to. A model that can only write text can only be wrong. A model with shell access, a cloud credential and a payment method can be wrong expensively. Most agent incidents are not the model turning hostile; they are an agent doing something reasonable-looking with permissions nobody thought carefully about, like deleting files to free space or retrying a paid API call several thousand times.

That is also why prompt injection matters more for agents than for chatbots. If an agent reads a web page, an email or a code comment, whatever is written there enters the same context as your instructions. The model has no reliable way to tell your intent from text it merely read. An attacker who can get words in front of an agent can try to redirect it, and the only robust defences are structural: limit what the agent can reach, require confirmation for actions that cost money or destroy data, and treat anything it read as untrusted input rather than as orders.

If you are evaluating agent products, the questions worth asking are unglamorous. What tools does it have, exactly? What can it do without asking? Does it keep a log you can audit after the fact? Can you cap its spending? How long are its chains before a human sees anything? Those answers predict real-world behaviour far better than any benchmark score.

None of this is an argument against agents. The loop is a real capability increase, and supervising an agent that drafts work for you is a genuinely different job from doing the work yourself. But the thing to supervise is not the model's intelligence. It is the list of things it is allowed to touch.