The post has been translated automatically. Original language: Russian
The AI agent demo almost always looks convincing: the model gets the task, calls up a couple of tools, and returns the result. The problems begin when the chain becomes longer than three steps, and it's not about a weak model.
Where exactly is the crash happening
- The error accumulates. With 95% accuracy at each step, after ten steps, about 60% remains. The agent does not make mistakes much, he makes mistakes little by little and repeatedly.
- The context is overflowing with garbage. Each call to the tool adds a raw response to the history: JSON for a thousand lines, logs, duplicates. After a few steps, the model searches for a task among its own intermediate results.
- The model does not distinguish between "failed" and "turned out empty". An empty API response is often interpreted as a valid result, and the agent confidently continues to work on an empty basis.
- There is no stopping point. Without an explicit completion criterion, the agent either spins in a loop or stops before the task is completed.
What helps in practice
- Compress the results of the tools. The extracted fields should go into the context, not the full body of the response. This reduces both the request price and the noise level.
- Divide the task into deterministic sections. Filtering, sorting, and arithmetic should be left to the usual code. The model is good at choosing an action, not executing it.
- Do the verification in a separate step. A cheap model or a simple validation function at the output intercepts most of the silent errors.
- Log every intermediate solution, not just the final answer. Without tracing the steps, debugging the agent turns into guessing.
- Set a budget: maximum steps, maximum tool calls, timeout. A restriction from above is almost always more useful than hoping that the model will figure it out on its own.
Things to keep in mind when choosing an architecture
The more freedom an agent has, the worse the reproducibility. A rigid pipeline with one or two model solutions is usually more reliable than a free loop and debugging is much easier. A free agent scheme is justified where scenarios are unknown in advance, for example, in research tasks or when working with poorly structured data.
How to measure
Evaluating an agent based on the final answer alone is not enough. It is more useful to look at three indicators: the proportion of tasks that are completely solved, the average length of the successful chain, and the proportion of steps with the wrong tool. The third indicator most often indicates that the problem is not in the quality of generation, but in the description of the tools.
Most improvements in agent-based systems are achieved not by changing the model, but by working with context, constraints, and checks. Boring engineering, which determines whether a demo will survive to production.
And what is your practical limit on the length of the chain, after which the agent ceases to be reliable?
Демо ИИ-агента почти всегда выглядит убедительно: модель получает задачу, вызывает пару инструментов, отдаёт результат. Проблемы начинаются, когда цепочка становится длиннее трёх шагов, и дело здесь не в слабой модели.
Где именно происходит сбой
- Ошибка накапливается. При точности 95% на каждом шаге через десять шагов остаётся около 60%. Агент не ошибается сильно, он ошибается понемногу и многократно.
- Контекст переполняется мусором. Каждый вызов инструмента добавляет в историю сырой ответ: JSON на тысячу строк, логи, дубли. Через несколько шагов модель ищет задачу среди собственных промежуточных результатов.
- Модель не различает «не получилось» и «получилось пусто». Пустой ответ API часто трактуется как валидный результат, и агент уверенно продолжает работать на пустом основании.
- Нет точки остановки. Без явного критерия завершения агент либо крутится в цикле, либо останавливается раньше, чем задача решена.
Что помогает на практике
- Сжимать результаты инструментов. В контекст должно уходить не полное тело ответа, а извлечённые поля. Это снижает и цену запроса, и уровень шума.
- Разбивать задачу на детерминированные участки. Фильтрацию, сортировку, арифметику лучше оставить обычному коду. Модель хороша в выборе действия, а не в его исполнении.
- Делать проверку отдельным шагом. Дешёвая модель или простая функция валидации на выходе перехватывает большую часть тихих ошибок.
- Логировать каждое промежуточное решение, а не только финальный ответ. Без трассировки шагов отладка агента превращается в угадывание.
- Задавать бюджет: максимум шагов, максимум вызовов инструмента, таймаут. Ограничение сверху почти всегда полезнее надежды на то, что модель разберётся сама.
О чём стоит помнить при выборе архитектуры
Чем больше свободы у агента, тем хуже воспроизводимость. Жёсткий пайплайн с одним или двумя решениями модели обычно надёжнее свободного цикла и отлаживается в разы проще. Свободная агентная схема оправдана там, где сценарии заранее неизвестны, например в исследовательских задачах или при работе с плохо структурированными данными.
Как измерять
Оценивать агента только по финальному ответу недостаточно. Полезнее смотреть на три показателя: доля задач, решённых полностью, средняя длина успешной цепочки, доля шагов с неверно выбранным инструментом. Третий показатель чаще всего и указывает, что проблема не в качестве генерации, а в описании инструментов.
Большинство улучшений в агентных системах достигается не сменой модели, а работой с контекстом, ограничениями и проверками. Скучная инженерия, которая и определяет, доживёт ли демо до продакшена.
А какой у вас практический предел по длине цепочки, после которого агент перестаёт быть надёжным?
Share
