Chatbot or Agent: The Difference Is the Harness, Not the Model

You write to a bot: "Book a table for two at seven this evening." It replies politely and correctly, asks whether you'd like a window seat or the main room, wishes you a pleasant evening. Meanwhile nobody has booked anything: not a single call, not a single entry in the restaurant's system. A week later someone shows you a different system and tells you that this one is an "agent." You open it - inside is the same conversation, only the answers are longer.

The difference between these two things is not in the model. It's in the code around the model. By the end of this article you'll stop confusing a chatbot with an agent, you'll understand what that code is made of, and you'll learn to look at it before you look at the list of available models.

A simple distinction: answering versus doing

A chatbot answers with text. That's its whole cycle: a question comes in, an answer goes out. It can answer brilliantly, with examples and code, but the product of its work always stays as letters on a screen. What happens next is up to a human.

An agent executes steps. That short phrase hides all the mechanics, so let me unpack it:

• picks a tool - a function it's been allowed to call: a database search, sending an email, writing a file, a request to an external service
• calls it - doesn't describe the call in words, actually runs it
• reads the result - including the error, if the tool failed
• decides what's next - retry, reach for a different tool, ask a human
• stops on a criterion - a condition set in advance, at which the task counts as done or as hopeless

From this comes a simple test for any meeting where you're being shown "our AI assistant": ask what happens between the user's question and the system's answer. If all that's in between is text generation, you're looking at a chatbot, whatever the slide calls it. If what's in between is tool calls, reading results, and an explicit stopping condition - that's an agent.

flowchart TB
  subgraph CB["Чат-бот"]
    C1["Вопрос"] --> C2["Генерация текста"] --> C3["Ответ"]
  end
  subgraph AG["Агент"]
    A1["Вопрос"] --> A2["Модель: что сделать сейчас"]
    A2 --> A3["Вызов инструмента"]
    A3 --> A4["Чтение результата"]
    A4 --> A5{"Условие остановки"}
    A5 -->|"нет"| A2
    A5 -->|"да"| A6["Ответ"]
  end

What a harness is and what it's made of

A harness is the software layer around the model. The model itself, in this arrangement, makes a decision at only one step: what to say or which tool to call right now. Everything else is done by the harness. Here's what it's made of:

• Memory and conversation state management. What the agent remembers at the current step, what gets fed back in, what gets thrown out as excess. The model never sees the whole history of the task - it sees exactly the slice that was assembled for it.
• The tool set. A list of actions with descriptions of what each one does and when to use it. There are no tools "in general": an agent can do exactly what you gave it.
• An isolated execution environment. A separate environment - a sandbox - where the agent's commands can't reach production data and can't break anything outside their own boundaries.
• Action confirmations. Points where execution stops and waits for a human.
• The event stream. Every step the agent takes is an event: called a tool, got a response, hit an error, moved on. This is what you'll be reading when you sit down to work out why everything went wrong.
• Task continuation across steps. The machinery that keeps the agent from starting over from scratch after every action and instead holds the thread: what's already done, what's left.

Almost everything you'll later be fixing in a working system lives in that list, not in the model.

Why the harness decides more than the model does

There's a recent and unusually clear-cut argument for this. On August 21, 2026, Nvidia published results on the ARC-AGI-3 benchmark - a set of interactive reasoning tasks where you can't get by with a single reply: you have to act in sequence and adapt to what came out of the previous step.

The same model with no special harness scored 30 percent. The same model with a custom harness scored 100 percent. The model wasn't changed: no fine-tuning, no move to a bigger version. Only the layer around it changed.

Two things produced the difference: careful handling of memory, and an overseeing component - a supervisor that directs the agent's steps and checks them.

My practical takeaway from working with agent pipelines matches this exactly. When an agent hits a quality ceiling, the team's first impulse is to swap the model. That's the most expensive and most common mistake: you pay for the migration, rewrite the prompts, rebuild the tests, and the gain turns out to be within the noise. Look at three things first:

• context management - what exactly the model sees at each step and what's getting in its way
• how the agent reaches for tools - whether it picks the right one, what it does with an error, whether it loops
• the presence of a self-check layer - a component that looks at the result before it goes out the door

flowchart LR
  A["Решение агента"] --> B{"Есть последствия<br/>за пределами агента?"}
  B -->|"нет: чтение, поиск,<br/>черновик"| C["Выполняет сам"]
  B -->|"да: запись файлов,<br/>отправка, команды"| D["Останов<br/>и запрос подтверждения"]
  D --> E["Человек"]
  E -->|"да"| F["Действие выполнено"]
  E -->|"нет"| G["Действие не выполнено,<br/>причина записана"]

Where the human has to stay in the loop

There's a class of actions you can't hand to an agent unasked: writing files, sending messages, running commands on a system. Anything with consequences beyond the agent itself should require a human confirmation. An autonomous run in this design doesn't perform the action itself - it puts a request in a queue, and a human works through that queue.

I have this rule wired into all my content pipelines: no text gets published without an explicit human action, and I'm the only one who changes status in the database. The agent can gather the material, write the draft, check it, and put it on the desk. I press the button.

The second mark of a mature agent is reproducibility. Every run leaves a full trace of what it did: which tools it called, what it got back, why it turned where it turned. Without that trace there is literally nothing to debug with: you look at a bad result and guess which of twenty steps went off the rails. With it, you open the log and see the step where the agent read the wrong document.

Sources

• TechCrunch on Nvidia's results: the real hero is the harness, not the model