What is an agent.

An agent is something you give a want to, instead of a list.

Imagine you are thirsty.

A talking machine tells you where the kitchen is. It is very good at telling. Ask again and it tells you again, just as nicely. You are still thirsty.

An agent goes to the kitchen.

That is the whole difference, and everything else is detail. One tells you. The other goes.

Now the interesting part. It gets to the kitchen and the tap is broken. Nobody told it anything about broken taps. So it looks around, spots a bottle in the fridge, and brings you that instead. Nobody gave it that step. It made the step up — because it knew what you actually wanted, which was water, and not what the instructions were about, which was the tap.

That is the thing worth understanding. You gave it a want. It filled in the steps.

And here is the part grown‑ups skip. Someone who makes up steps might also decide to climb on the counter. It got you the water. It also broke a plate. You never said “don’t climb.” You only said you were thirsty.

So your job changes. You stop saying do this, then this, then this. You start saying this is what I want — and these are the things you may never touch.

Saying what you want is easy. Knowing everything it must never touch is the hard part, and it is the whole job.

An agent is software you hand a goal to, which then decides for itself what to do next.

Three things have to be true at once:

1. It receives an objective, not a procedure. “Publish an article about this” rather than “open the file, write 900 words, save, upload.”
2. It can act on the world. It calls things, writes files, sends messages, spends money. A system that only produces text is not an agent, however clever the text.
3. It runs in a loop. The result of one action becomes the input to the next decision. That is what lets it recover from a broken tap.

Take away any one and you have something else. Take away the loop and you have a script with a language model bolted on.

Notice what is not on that list: being clever. The same model, on the same problem, is a chatbot when it must ask you between each step and an agent when it must not. What changed was not its capability. What changed was how many decisions you allowed it to take before you looked.

That framing matters because it tells you where the risk is. The useful question is never “is this an agent.” It is: how many decisions does it take between my instruction and my review? One is safe and slow. Four hundred is fast, and is where the surprises live.

Which brings up the cost nobody prices in. Your job moves from checking output to checking behaviour. You can read one article. You cannot read four hundred decisions. So the system has to report on itself — and that report has to be something it cannot quietly fake. An agent whose only account of its own work is its own summary of its own work is not audited. It is unsupervised.

What agents are genuinely good at: work with many small steps, clear success conditions, and cheap mistakes.
What they are bad at: anything where being wrong is expensive and being wrong is hard to notice.

An agent is a control loop in which a language model chooses the next instruction.

Strip the marketing off and it is about fifteen lines:

history = [goal]

while not done(history):
    step = model(history)          # an answer, or a tool call
    if step.is_answer:
        return step
    result = execute(step.tool, step.args)   # touches reality
    history.append(step)
    history.append(result)

That is it. Everything else is harness — and the harness is where the engineering actually lives.

Five components, and the failure each one owns

The failure modes that actually bite

In roughly the order you will meet them:

1. Context growth is a cost curve, not a detail. Every turn appends. Append‑only agent memory means cost per run rises forever, and old entries crowd out new ones. On this site, one agent’s memory file reached 62 KB — roughly 15k tokens prepended to every call it makes.
2. Tools that swallow their own errors are worse than tools that crash. except Exception: pass returns success, the model believes it, and the agent builds three more steps on a foundation that is not there.
3. Side effects are not transactional. A run that dies at step 7 of 12 leaves seven steps of real consequence and no record of which seven. The rollback story has to be written before the happy path.
4. Self‑reported state is not state. If an agent writes “fixed the footer bug” into its own memory, that is a claim, not a fact. Verify against the artefact, never the narrator.
5. An advisory guardrail is not a guardrail. A validator returning a boolean that nothing branches on is a logging statement wearing a helmet.

The rule that follows from all of it

The model decides what to do. Code decides what is permitted. Never put a constraint only in the prompt: a prompt is a request, a check is a guarantee.

And when you go looking for evidence that one setup beats another, read benchmark scores as evidence about the benchmark first, and about your work second.