A plain request to a model is a single turn: you ask, you get an answer. An agent is the next level: the model works not in one turn but in a loop, deciding for itself what to do next, until it reaches the goal. If tool calling gives the model hands, an agent is a model that works with those hands on its own, step by step.
What an agent is
An agent is a model placed in a loop with a goal and a set of tools. Simplified, each step looks like this:
- Plan / reasoning — the model looks at the goal and the current state and decides what to do next.
- Action — it calls a tool: reads a file, runs a test, searches the code, edits a line.
- Observation — it gets the result of the action into context.
- It repeats the loop, taking the result into account — and so on, until the goal is reached or a limit is hit.
Example: "fix the failing test". The agent runs the test (action) → sees the error (observation) → finds the guilty code (action) → fixes it (action) → runs the test again (action) → sees it pass (observation) → stops. All of this without your involvement at each step.
How an agent differs from a request
The difference is autonomy. A plain request does exactly what you said, in one turn. An agent breaks the task into steps itself, chooses tools itself, reacts to intermediate results itself, and decides when to finish itself.
This is powerful: an agent handles tasks that can't be solved in one answer — they require a series of actions and reaction to their outcomes. But it's also risky: the more steps the system takes on its own, the less you control each one, and the more expensive accumulated error becomes.
Where agents are strong, and where they break
Strong when the task:
- breaks into steps with a verifiable result (test passed / failed, code compiled);
- requires reacting to intermediate outcomes (you can't guess the whole path in advance);
- tolerates several attempts and has a clear "done" criterion.
Break when:
- there's no clear "done" criterion — the agent spins, not knowing whether it reached the goal;
- errors accumulate — a wrong step leads the next ones further astray, and the agent confidently heads the wrong way;
- the cost of a step is high and irreversible — each independent call can do harm;
- the goal is vague — the vaguer the task, the more the agent "fantasizes" the route.
Control is mandatory
Autonomy requires boundaries — otherwise a hallucination on one step quietly leaks into the result:
- Limit tools and permissions — the agent should be able to do exactly what's necessary; the irreversible goes through human confirmation.
- Set limits — on the number of steps and on cost: a loop can easily generate hundreds of expensive calls.
- Make the result verifiable — give the agent an objective criterion (tests, compilation) by which both it and you know the goal is reached; then verify the outcome like any AI result.
- Keep a human in the loop on important decisions — the agent proposes, the human approves what's costly to undo.
What this means in practice
Agents are a way to hand AI not a single answer but a whole multi-step task. For a product engineer this is a huge lever and, at the same time, the zone of greatest risk: the more the system does on its own, the more important a clear goal, a verifiable "done" criterion, limited permissions, and hard limits. A good agent isn't the "smartest" — it's the one with a clear goal, reliable verification, and reasonable boundaries.
What's next
You've covered how AI works: models, hallucinations, tokens, context, tools, and agents. Next — how the work is built on this foundation: the contract and tooling for AI, skills, and memory.