Сидишь на демо, тебе показывают «нашего AI-ассистента». Ты говоришь: «Забронируй столик на двоих на семь вечера». Он отвечает вежливо и грамотно, уточняет — у окна или в общем зале — и желает приятного вечера.

А столик при этом никто не забронировал.

Через неделю тебе показывают другую систему и говорят: «Вот это уже агент». Ты открываешь — внутри тот же самый разговор, только ответы длиннее.

Я долго наблюдаю эту путаницу и вижу одну и ту же причину: разницу пытаются искать в модели. А она — почти всегда — в коде вокруг модели.

Ниже — простой способ перестать путать чат-бота с агентом, и чек-лист, на что смотреть в «обвязке» (harness), прежде чем спорить про «какая модель лучше».

Простое различие: отвечать и делать

Чат-бот отвечает текстом. Пришёл вопрос → ушёл ответ. Он может отвечать блестяще, с примерами и кодом, но продукт его работы остаётся буквами на экране. Дальше действует человек.

Агент выполняет шаги. Это звучит просто, но внутри — конкретная механика:

• выбирает инструмент — функцию, которую ему разрешили вызывать (поиск по базе, отправка письма, запись файла, запрос во внешний сервис)
• вызывает его — не описывает вызов словами, а действительно запускает
• читает результат — включая ошибку, если инструмент упал
• решает, что дальше — повторить шаг, взять другой инструмент, спросить человека
• останавливается по критерию — по заранее заданному условию, при котором задача считается выполненной (или безнадёжной).

Тест на любую «агентность» на демо: спроси, что происходит между вопросом пользователя и ответом системы. Если между ними только генерация текста — перед тобой чат-бот, как бы его ни назвали в презентации. Если между ними есть вызовы инструментов, чтение результатов и явное условие остановки — это агент.

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

Что такое «обвязка» и из чего она собрана

Обвязка (англ. harness) — это программный слой вокруг модели. В этой конструкции модель делает выбор только в одном месте: что сказать сейчас или какой инструмент вызвать сейчас. Всё остальное — ответственность обвязки.

Вот ключевые элементы, без которых агент превращается обратно в красивый чат:

• Память и состояние. Что агент помнит на текущем шаге, что ему подкладывают заново, что выбрасывают как лишнее. Модель почти никогда не видит «всю историю задачи» — она видит ровно тот кусок, который собрали для неё на этот шаг.
• Набор инструментов. Перечень действий с ясными описаниями «что делает» и «когда применять». Инструментов не бывает «в целом»: агент умеет ровно то, что ему дали.
• Изоляция выполнения. Песочница, где команды агента не достают до боевых данных и не ломают ничего за своими пределами.
• Подтверждения действий. Точки, где выполнение останавливается и ждёт человека.
• Поток событий (лог). Каждый шаг — событие: вызвал инструмент, получил ответ, наткнулся на ошибку, пошёл дальше. Это то, по чему потом реально дебажат систему.
• Продолжение задачи между шагами. Механика, которая не даёт агенту «начинать с нуля» после каждого ответа и держит нить: что уже сделано и что осталось.

Почти всё, что потом приходится чинить в работающей системе, живёт в этом списке — а не в модели.

Почему обвязка решает больше, чем модель

Я люблю примеры, где спор закрывается цифрами.

В задачах, где одного ответа недостаточно и нужно действовать последовательно (интерактивные reasoning-задачи вроде ARC-AGI-3), качество может отличаться кратно на одной и той же модели — просто потому, что у одного решения нормальная обвязка, а у другого нет.

Мой практический вывод из агентных пайплайнов такой: когда система упирается в потолок качества, первое желание команды — «давайте сменим модель». Это часто самая дорогая и самая частая ошибка.

Перед тем как платить за миграцию, я бы проверила три вещи:

• контекст-менеджмент: что именно модель видит на проблемном шаге и что ей мешает
• как агент выбирает и вызывает инструменты: попадает ли в нужный инструмент, как выходит из ошибок, не зацикливается ли
• есть ли слой самопроверки: компонент, который смотрит на результат до того, как его отдадут наружу.

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

Где человек должен остаться в цикле

Есть класс действий, которые нельзя отдавать агенту «молча»: запись файлов, отправка сообщений, команды в системах, которые влияют на реальный мир. Всё, у чего есть последствия за пределами агента, должно требовать подтверждения человека.

В своих контентных пайплайнах я держу это правило железно: ничего не публикуется без явного действия человека, и статус в базе меняю только я. Агент может собрать материал, написать черновик, проверить его и положить на стол. Кнопку жму я.

Источник

• https://techcrunch.com/2026/08/21/nvidia-just-showed-that-the-harness-not-the-ai-model-is-now-the-real-hero/

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