What is an AI agent?

The short answer

An AI agent is a language model that works in a loop, uses tools, and is held together by program code. That code is called the harness. It calls the model, keeps a record of the conversation, gives the model a role, actually executes the tool calls the model proposes, and draws the lines the model has to stay inside.

The model itself is remarkably passive. It cannot do anything. It can only propose text, and the fact that a file gets written, an email goes out or a record changes is every single time the work of the harness. Anyone who says "agent" while thinking of the model is looking for the intelligence in the wrong place. What makes an agent useful is decided almost entirely in the code around it.

That is why we treat "What is an AI agent?" as a build sheet on this platform and not as a definitional question. There is a manageable number of parts. Each has one job, each has a handful of typical failure modes, and each has its own page here.

What an agent is not

Not a chatbot. A chatbot takes a question and returns an answer, and that is a single LLM call, there and back, after which the transaction is over. An agent does not stop there. It may propose an intermediate action, see the result of that action, and carry on with the new knowledge. An exchange becomes a process.

Not automation in the familiar sense. You build ordinary automation for processes you know: step one, then step two, on error take branch three, and because the sequence is fixed up front, any deviation from it is a bug rather than a feature.

You build an agent for scenarios you don't know, with a tool that is just as hard to plan for. You don't define the order. You define the frame: which tools exist, what they may do, when it ends. Which path the agent takes inside that frame is decided while it runs. That costs you something, and it costs you in a place that is easy to miss. Every loop has to work in all circumstances, not just the one you built it for.

An uncomfortable rule of thumb follows. If a process is fully known, an agent is the worse solution. More expensive. Slower. Harder to verify. It pays off where the cases diverge and you would otherwise add one special case after another.

Not an assistant that "understands". The model has no memory between two calls. On the second call it does not know there was a first. Everything that looks like recall is text the harness sent along again. Once that has sunk in, you stop attributing intentions to the model and start building the context.

Block I: the harness and its five parts

The harness is the core. It consists of five parts that build on each other. Each is small on its own, and only together do they make an agent.

1. The LLM call. It starts with a single call. One message out, one answer back. Here you learn what actually goes over the wire, meaning roles, tokens, temperature and stop words, and why this one call stays stateless no matter how often you repeat it. This is not an agent yet. It is just text.

2. The message history. Because the model keeps nothing, the harness keeps the books: it appends every question and every answer to a list and sends that entire list along again next time, so that single calls turn into a conversation. And from this simple mechanic follows the first hard limit, because the list grows and the context window does not.

3. The system prompt. Before the user's first word arrives, it states who the agent is. Role, tone, rules, scope. I consider it the cheapest and most effective lever in the whole build, and the one with the most superstition attached.

4. Tools & loop. This is where a language model becomes an agent. You describe tools to the model, it proposes a call, the harness executes it and puts the result back into the history, then the model decides again, and this continues until the goal is reached or a stop condition fires. Perceive, decide, act, check. Everything else leads up to this.

5. Guardrails. An agent that is allowed to act can do damage. Guardrails check the inputs, filter the outputs, cap loop iterations and cost, and reliably stop what must never happen under any circumstances. They are not an add-on for later. Without them, the loop from step four is a promise with nothing behind it.

These five are enough for a working agent. Everything beyond makes it better, but not possible in the first place. The concepts overview shows them in context.

One run, step by step

The difference becomes clearest on a concrete assignment. Say an agent is asked: "How many open invoices are more than 30 days old, and what do they add up to?" It has two tools. A database query and a calculator.

Round one. The harness sends the system prompt, the tool descriptions and the question to the model. The model does not answer with a number. It proposes something: database_query(status="open", due_before="2026-07-10"). Nothing more happened inside the model. It produced text that happens to have the shape of a tool call.

The harness acts. It checks whether that tool is allowed at all and whether the parameters look plausible, runs the query, and appends the result to the history as a new message: 14 records, with amounts. Had the query thrown an error, the error message would go back in exactly the same form. An agent that never gets to see failures cannot work around them either.

Round two. The same call again, only the history is longer now. The model sees the 14 records and proposes the next step, calculator(operation="sum", values=[…]). Again the harness executes, again the result goes into the history.

Round three. Now the model has everything and answers in plain text. 14 invoices, 23,480 euros. No tool call this time. For the harness, that is the stop condition.

Three things about this run strike me as worth noting. The model was called three times and not once, so every round costs time and money. None of it was fixed in advance, because a different question would take two rounds or seven, in a different order. And at every point where the harness executes, it could also have refused. That is where guardrails sit, and it is the only place where they actually bite.

Block II: what stands beside it

A harness is at first just a shell. Technically finished. Professionally empty. It knows nothing about your systems, your data or your rules. Block II is everything placed beside it to turn the tool into your agent.

Memory is the first service of its own beside the harness. The craft is not the storing. It is the selection. Out of everything stored, what travels along on this one request? Send everything and it blows the context, send too little and the agent looks stupid even though it stored all it needed.

Sidecars are separate, stateless services for everything the agent should not have to guess. A calculation, a conversion, a check. A sidecar answers the question of what is actually hanging off the far end of a tool.

Tool calling in production explains why a single tool call almost always succeeds and twenty in a row almost never do. Success rates multiply. 95 percent per step is 36 percent after twenty steps. This part is about everything you build around the chain so that it holds anyway.

Tiny Agents and the compression boundary sits one floor up. Out of two hundred available capabilities the model only ever sees the ones you show it, and the outputs of all the others flood its context the moment you get generous. Selection is not a detail here. It is the actual engineering work.

Guardrails in production is the control plane outside the harness. It still checks when the harness is someone else's or has been hijacked itself. Gateway, detectors, airlocks, policy.

Block III: what it all runs on

Underneath every agent lies a model, and underneath the model lies technology worth knowing before you have to explain a bill or a response time.

How an LLM works is the beginning of everything. A machine guessing the next token, in a loop. Why that guessing is enough to translate and to program, and why hallucination is not a malfunction but the task.

The model landscape shows which models exist, open and closed, at which sizes, and how you spot the one that fits your task.

What's inside a model download: weights, tokenizer, chat template. Three things that belong together, and confusing them explains half of all strange outputs.

Inference engines turn a file full of weights into an API that answers requests.

Hardware is the hard memory limit. VRAM decides what runs at all, and quantisation decides at what price.

Benchmarks explain how to compare models without taking published leaderboards on faith.

How to build an agent

The order above is my recommendation and not a table of contents. It starts at the single call and ends at the control plane, and each step only gets interesting once the one before it is in place.

In practice: build the smallest agent that does anything at all first. One model, one tool, one loop with a hard stop after five rounds. Only when that build runs in a way you can follow does the second tool get added. The most common beginner's mistake is to start with a framework that already hides all five parts, because it runs immediately, and at the first odd behaviour you have no idea where to even look.

That does not make frameworks wrong. A framework is just the second decision and not the first. Once you have built the five parts yourself, you read every framework afterwards for what it is: a collection of defaults for these five questions.

You can build this hands-on in the tutorials. The path from the first call to an agent with tools runs there along real code.

Where agents fail

Three patterns keep coming back, and all three have little to do with the model.

The chain is too long. Error rates multiply. Asking an agent for twenty steps in a row builds a system that mostly gets stuck somewhere. What helps is shorter assignments, intermediate checks, and tools that return something usable on failure instead of a bare exception the model cannot do anything with.

The context fills up. Every tool output, every intermediate answer and every attached file takes up room in the context window, until the essential part sits so far back that it simply drowns. Context is a limited resource and has to be managed actively. That is what memory, summarisation and selection are for.

The permissions are too broad. An agent that may write will eventually write something wrong. The question is not whether that happens. The question is what it costs. Narrow permissions, a second look before expensive actions and a hard spending cap are cheaper than any correction after the fact.

The terms that keep coming up

A vocabulary has grown around agents that we all use loosely. Here are the most important terms in two sentences each. Every one of them leads on to the page where it is covered in full.

Token. The unit models count in. Not a letter and not a word, but a chunk of text the tokenizer has learned. Cost, speed and the context limit are all measured in tokens and not in characters, with the details in the LLM call.

Context window. The upper bound of what the model can see at once during a single call. System prompt, history, tool descriptions and tool outputs all share that one space.

Tool calling / function calling. Two names for the same thing. Instead of prose the model emits a structured call that the harness executes. Both terms describe the proposal and not the execution, see tools & loop.

Agentic loop. The cycle of proposal, execution, return, new decision. It is the difference between a model with tools and an agent.

MCP. A protocol that describes tools in a uniform way so that every integration isn't reinvented. It solves the connection problem and not the selection problem. Which tools the model gets to see remains a design decision, see Tiny Agents.

RAG. Search across your own documents, whose hits are placed into the prompt before the call. A variant of memory, only over manuals instead of conversations.

Hallucination. A fluently phrased, factually wrong output. For an agent it is especially expensive, because it sits at the start of a chain and every following step builds on it.

Multi-agent / swarm. Several agents dividing up the work. This is only worth it once a single agent runs reliably. Otherwise you multiply the sources of error instead of sharing the load.

Common questions

Does this need a large model? Not necessarily. In my experience the tool description matters more than the model size for many tasks. Larger models are more forgiving of bad prompts, which is a convenience and not a concept.

Local or via API? Both work, and we run both here. An API is the faster start, a self-hosted model is the answer to questions of privacy, cost and availability. What that takes is covered in Block III.

Is an agent reliable? Not by itself. Reliability comes from guardrails, short chains, checked intermediate steps and from the willingness not to hand a task to an agent when a plain script does it faster and more transparently.

Can't I just click this together in ChatGPT? To get started, yes, and for some tasks permanently. Where clicked-together agents break in production, and which building block explains each case, is covered on Building agents in ChatGPT - so why a platform?.

Where do you start? At Block I, part one. The LLM call is readable without an account and takes fifteen minutes.