What an agent is made of

An agent is a loop, not a model

It is tempting to think of an AI agent as a smarter chatbot. It is more useful to think of it as a small system. A language model sits at the centre, but the model alone only produces text. What turns it into an agent is everything wrapped around it: instructions that give it a job, tools that let it read and change things, memory that carries context forward, and a loop that lets it take one step, look at the result, and decide the next one.

A chat assistant answers once. A fixed workflow follows the same steps every time. An agent chooses its own steps toward a goal, inside limits someone has set. That freedom is the point, and it is also why you need to be able to see each step.

The six parts

Every agent you will meet, from a weekend prototype to a production system, is built from these parts. The names vary between products; the jobs do not.

• Model. The reasoning engine. It reads everything in front of it and decides what to do next: answer, ask a question, or call a tool. Different models trade speed, cost and depth of reasoning.
• Instructions. The job description: the agent's role, how it should work, what good output looks like, and what it must never do. Clear instructions do more for quality than a bigger model.
• Tools. The agent's hands and eyes. A search tool lets it perceive; a "create record" tool lets it act. Without tools it can only talk about the work. Lesson 2 covers them in depth.
• Memory. What it knows beyond this moment: the conversation so far (short-term) and stored preferences, facts and past work (long-term). Lesson 4.
• Planning. How it breaks a goal into steps and puts them in order, either up front or one step at a time. Lesson 3.
• Guardrails. The limits it works inside: which tools and systems it may touch, which actions must wait for a person, and budgets on time and cost. Lesson 5.

Research on agent architectures often lists the same thing as capabilities: perception (taking in the request and the world), reasoning, memory, planning, action, communication (with people and other agents) and learning (improving from feedback). Parts and capabilities are two views of one design.

How one run moves

When you give an agent a task, it goes round a loop until the task is done or it hits a limit:

1. Perceive. Read the request, the instructions, any memory that applies, and the results of earlier steps.
2. Reason. Decide what is needed next. Is there enough information to answer? If not, which tool would get it?
3. Act. Call a tool with specific inputs: search this, read that, create this draft.
4. Observe. Read what came back, including errors, and add it to what it knows.

Then round again. The loop ends when the agent decides the goal is met, when it needs a person (a question, or an approval), or when a guardrail stops it: too many steps, too much time, too much cost. A well-built agent always has a stop condition. An agent without one can loop for a long time, spending money while looking busy.

Reading a run is a skill

When an agent's answer surprises you, do not just rephrase and try again. Trace it. Which tools did it call, with what inputs? What came back? Where did its reasoning depart from what you would have done? Most problems turn out to be one of four things:

• Missing context: it never had the fact it needed. Fix the instructions, memory or tool access.
• Wrong tool or wrong input: it had the right tools but used them badly. Fix the tool choice or its description (lesson 2).
• Poor plan: it did steps in a bad order or stopped too early (lesson 3).
• A guardrail doing its job: it stopped because an action needed approval or it ran out of budget. That is not a bug.

This is why a record of every step matters. You cannot improve an agent whose working you cannot see.