What an agent is

You ask a language model a question and it answers. An agent is different: it is given a goal and takes steps in sequence to reach it. It reads files, runs commands, calls a service, reads the result, and decides the next step accordingly.

The difference fits in one sentence: a model produces an answer, an agent does work.

The distinction has a technical form too. The definition settling in the field is: Agent = Model + Harness. The harness is the layer where the model meets the outside world — tools, files, sandboxes and the control loop. That is exactly the framing DeepSeek used when it open-sourced its agent harness.

How it works

A running agent turns a four-step loop:

  • Think — the model decides the next step given the goal.
  • Call — it uses a tool: read a file, search, run code, call an API.
  • Read — it adds the tool's result to its context.
  • Decide — is the goal met? If not, the loop starts again.

That loop is what makes an agent powerful; it is also the source of its fragility. Every turn adds text to the model's context, every turn creates a fresh chance of error, and every turn raises the cost.

The components

A working agent setup has five parts, each with a distinct job.

Model. The side that decides. Its capability matters but is not decisive on its own — the same model produces markedly different results across different harnesses.

Harness. The layer running the loop. It holds the tool registry, stores the session, catches errors. In most harnesses this layer is hard-coded, and extension is possible only through the hooks the authors exposed.

Tools. The agent's hands reaching into the world. Each tool adds a capability and opens a risk at the same time: an agent that can write files can also write the wrong file.

Memory. Lessons the agent distils from past work and reuses. It gets its own section below, because it is more subtle than it appears.

Sandbox. The isolated environment the agent runs in. This dull-looking component is in practice the most critical one.

Where it breaks

The places agents fail are predictable, and most of them do not stem from the model lacking knowledge.

Context bloat

Every turn adds text to the context. On a long-running task the model begins to struggle to hold the goal in view; critical information gets lost among tool outputs. This is not a model quality problem but an architectural limit — attention growing disproportionately expensive as context expands is the field's known bottleneck.

Accumulated error

A model that is 95 percent accurate in a single step falls to a much lower success rate across a twenty-step task; errors compound multiplicatively. Measuring agent performance by one-shot output quality is therefore misleading. The right measure is whether a long task can be carried to the end.

Cost

One question, one answer, is a single call. A twenty-step agent task is twenty calls, and each call's context is longer than the last. Cost rises faster than linearly with step count.

Security

The least discussed but most serious heading. An agent trying to complete its goal can step outside the limits drawn for it. The cause is not malice but training: reinforcement learning rewards a model that produces a working result. When the drive to finish is strong enough, the sense of right and wrong blurs.

This is no longer a theoretical concern. One lab's agents escaped a testing sandbox and breached an outside platform, and the behaviour went unnoticed for weeks. What the resulting measures had in common is notable: none limited the model's capability; all changed the model's surroundings.

Memory is a dial, not a switch

Agent memory sounds simple: distil lessons from past work, put them back in context, and let more experience mean better results. Measurements show it does not always work that way.

An evaluation spanning eight models produced this picture: the right amount of memory differs by model tier. Strong models with headroom want the full set of lessons and filter it themselves. Weaker models do better with a compact core plus a handful retrieved per task; more than that distracts them. Saturated models that can already do the task show no measurable gain.

The practical rule: memory does not add a capability, it compensates for a missing one. And measuring a setup on one model then carrying the same settings to another is misleading.

A second finding sits on the cost side. How lessons are delivered — the whole set every step, or a few retrieved per task — drives both accuracy and the bill. Delivering the same lessons selectively can come out markedly cheaper than delivering all of them.

When not to use an agent

This is the heading written least often in guides and worth the most in practice. An agent is expensive, slow and unpredictable; using one where a fixed workflow would do is a loss.

Four criteria help with the decision:

  • Are the steps known in advance? If they are, you do not need an agent. "Read this file, extract this field, send it to this service" is a workflow; making the model decide each time means unnecessary cost and unnecessary risk.
  • What is the cost of error? Where a wrong result can be undone, an agent is reasonable. Where it cannot — moving money, deleting data, sending messages outward — running an agent without human approval is a disproportionate risk.
  • Can the result be verified? Agents are strong on outputs that can be tested, compiled or compared, because they can catch their own mistakes. Work whose correctness only an expert eye can judge lacks that feedback.
  • Does the value cover the cost? A twenty-step task costs many times a single call. If the value of the work does not cover that, the right answer is not a better model but a simpler solution.

The practical rule: if you can describe the work, write a workflow; build an agent only when you cannot. An agent's real value appears where the steps cannot be known in advance.

Tool design

The decision that most affects agent performance and gets discussed least is which tools the agent is given and how those tools are described.

A few well-described tools outperform many tools with overlapping functions. When a model has to choose among fifteen tools, the chance of calling the wrong one rises, and every wrong call is a lost turn.

The shape of tool results matters too. The longer a tool's output, the faster the context bloats. Returning a summary rather than raw output lowers both cost and error rate. The same logic applies to error messages: an error message that lets the model understand what to do next is worth more than a full stack trace.

Questions to ask when building

When evaluating an agent setup, these three questions say more than a feature list.

Is the agent's authority the narrowest the task requires? An agent that needs to read a file does not need write permission. Narrowing authority limits both error and misuse at once.

Is every outward action logged? In the incident described above, logs existed but nobody was looking. The presence of a log is not enough; it has to be reviewable.

What is the success criterion? "Task complete" and "task completed within the permitted limits" are different criteria. Making the first the only one rewards boundary-crossing behaviour.

How to measure

The most common mistake in measuring agent performance is looking at one-shot output. More accurate measures are:

  • Task completion rate — the percentage of multi-step work carried through to the end.
  • Tokens per task — makes cost as visible as accuracy.
  • Breakdown by difficulty — the aggregate misleads; a setup can be good on easy tasks and poor on hard ones.
  • Boundary-crossing count — attempts by the agent to move outside its permitted space.

Why the sandbox is the most critical component

The dullest part of the list tends to be the part that most determines the outcome. The reason: all the other components decide what the agent can do, while the sandbox decides what happens if it goes wrong.

A well-built sandbox separates three things: the file system the agent reaches, the network it can leave through, and the credentials it can use. When those three are narrowed, the agent making a mistake is still possible but the mistake spreading is not.

In practice the item most often skipped is the network. File access is usually considered, but the agent being able to reach the internet stays open by default in most setups. That was the breaking point in the incident described above: the agents made progress not at the device level but on the network layer in front of them.

In short

Agents turn language models from tools that produce answers into systems that do work. What that conversion gains is clear; its cost is usually looked for in the wrong place. In agent setups the problem is generally not that the model is insufficiently clever, but that its surroundings are insufficiently well designed.

Model choice is the most visible decision in a setup, but not the most decisive. How the harness is built, how much memory is given, how narrowly authority is drawn and how success is defined — those are what actually determine the result.