10 июля началось не с работы: почему более 50 AI-агентов перестали стабильно выдавать результат

10 июля у меня началось не с обычной работы. Вместо того чтобы:

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

Раньше многие задачи проходили с первой попытки. Иногда требовалась одна корректировка. В этот день часть сценариев не собиралась ни с пятой, ни с десятой попытки …

Я ничего не менял в бизнес-логике. Не переписывал инструкции. Не заменял исходные файлы. Не перестраивал процессы. Но результат стал другим.

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

Мы не будем раскрывать внутреннюю кухню

В моих проектах используется более 50 агентов для разных бизнес-задач:

• работы с документами,
• исследованиями,
• контентом,
• встречами,
• кодом
• и другими повторяемыми процессами.

Полную внутреннюю кухню, архитектуру, системные инструкции и перечень агентов публично не раскрываю.

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

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

Что именно начало происходить

Проблему можно разложить на 3 группы симптомов.

1. Нестабильный результат

Самый неприятный симптом - не единичная ошибка, а потеря предсказуемости.

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

Раньше я понимал рабочую механику:

• сформулировал задачу,
• передал контекст,
• получил материал,
• проверил. Теперь появилось ощущение, что каждая попытка может пойти по новому маршруту.

Для разового диалога это раздражает. Для агента это разрушает сам смысл автоматизации. Агент ценен не тем, что однажды выдал красивый ответ, а тем, что повторяемо выполняет понятную работу.

2. Лишние действия

Вместо одного запуска появились:

• повторные запросы;
• ручное сравнение вариантов;
• возврат к старым инструкциям;
• попытки менять уровень размышления;
• переключение моделей;
• дополнительная проверка полноты;
• ручное восстановление пропущенных требований.

Каждое отдельное действие кажется небольшим. Но когда оно умножается на десятки процессов, компания теряет не минуты, а рабочий ритм.

3. Резкий рост времени

Высокий уровень размышления у ChatGPT стал заметно дольше, но это не всегда давало пропорциональный рост качества.

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

В итоге почти весь день ушел не на работу с помощью ИИ, а на диагностику самого ИИ.

Первая гипотеза: дело в обновлении модели

Самая очевидная рабочая гипотеза была простой: изменился основной модельный слой OpenAI, а вместе с ним изменилось поведение процессов, которые на него опирались.

Важная оговорка: совпадение по времени еще не доказывает единственную причину.

На результат могли влиять:

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

Поэтому корректная формулировка звучит так:

После обновления ChatGPT я увидел падение стабильности в части привычных сценариев. Первой гипотезой стало изменение модели и маршрутизации. Дальше эту гипотезу нужно проверять по классам задач.

Это менее эффектно, чем сказать, что новая модель все сломала. Зато честно и полезно для последующих решений.

Как простой выбор превратился в систему

Помнб, когда-то взаимодействие с ChatGPT было заметно проще.

Я выбирал старую или новую модель и писал запрос. Затем появились модели с размышлением и ручной выбор глубины. Для меня это уже было лишним решением: непонятно, где достаточно быстрого режима, а где нужен максимальный.

Я, наверное, как и многие пользователи, просто выбирал максимальную глубину потому, что не хотел рисковать качеством.

Позже интерфейсы начали сильнее автоматизировать выбор. Идея мне, кажется, понятной:

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

Теперь появился следующий уровень сложности:

• семейство Sol, Terra и Luna;
• еще больше уровней размышления … да ё-маё …;
• отдельные режимы Pro, Max и Ultra в разных продуктах;
• разные поверхности - Chat, Work, Codex и API;
• разные лимиты и контуры использования.

Технологически это дает больше возможностей. С точки зрения меня, как пользователя, появляется новый налог на выбор.

Раньше у меня вопрос был: “Как сформулировать задачу?” Теперь вопросов несколько:

1. Где ее выполнять?
2. Какую модель выбрать?
3. Какой уровень размышления поставить?
4. Нужен ли один агент или несколько?
5. Как это повлияет на лимиты?
6. Нужно ли менять старую инструкцию?
7. Как проверить, что новая конфигурация действительно лучше?

Я не хочу изучать документацию ради восстановления старого результата

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

Я хочу поставить задачу и получить результат.

Но как собственник компании я не могу сделать вид, что ничего не произошло. Если ИИ встроен в десятки процессов, зависимость от внешней модели нужно управлять так же, как зависимость от CRM, облачного сервиса или API.

То есть мне придется разобраться:

• что изменилось в поведении модели;
• какие старые инструкции теперь мешают;
• где максимальный режим размышления создает только задержку;
• где новая модель действительно сильнее;
• какие процессы пока разумнее оставить на GPT-5.5 и как долго её еще будет поддерживать;
• как проверять переход без массового ручного хаоса.

Почему нельзя просто вернуться назад и забыть

Самый быстрый локальный шаг - вернуть критичный процесс на прежнюю конфигурацию.

Но один возврат не решает стратегическую задачу. Старые модели не будут вечным неподвижным фундаментом. Новые возможности будут появляться дальше. Интерфейсы, тарифы, лимиты и способы управления уровни размышления продолжат меняться.

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

• тестировать;
• вводить поэтапно;
• сравнивать результаты;
• мониторить;
• уметь откатывать.

Что будет в этой серии

Эта серия появилась не из желания пересказать релиз OpenAI.

Она появилась из практического вопроса: как продолжать работать, когда новая модель обещает больше, но существующая система начинает вести себя менее предсказуемо.

Дальше я разберу:

• что именно изменилось между GPT-5.5 и GPT-5.6;
• чем отличаются Sol, Terra и Luna;
• что выбирать в ChatGPT, Work, Codex и API;
• почему высокий уровень размышления не всегда дает лучший практический результат;
• как устроены лимиты и почему тариф Plus не означает бесконечный ресурс;
• почему одна задача расходует условный 1%, а другая 10%;
• как теперь ставить задачи новой модели;
• какие старые инструкции ограничивают GPT-5.6;
• как мигрировать более 50 агентов без массовой ручной пересборки.

FAQ

GPT-5.6 точно стала причиной всех сбоев?

Нет. Мы увидели временную связь и сформулировали рабочую гипотезу. Для доказательства нужно сравнивать старую и новую конфигурации на одинаковых задачах, данных и критериях приемки.

Почему не раскрыть список из более чем 50 агентов?

Потому что их инструкции, архитектура и назначение являются внутренним операционным контуром компании. Для публичной серии достаточно показать масштаб зависимости и общие принципы миграции.

Нужно ли сразу возвращать все процессы на GPT-5.5?

Нет. Критичные нестабильные процессы можно временно откатить. Остальные нужно проверять поэтапно, не меняя одновременно модель, уровень размышления, инструкцию и рабочую поверхность.

Значит ли это, что GPT-5.6 хуже?

Нет. Новая модель может быть сильнее на многих задачах и при этом вести себя иначе в существующей инструкции. Предмет исследования - не абстрактный рейтинг модели, а качество конкретной рабочей конфигурации.

Источники и границы выводов

Базовый материал подготовлен по состоянию на 10 июля 2026 года. Функции, доступность и лимиты OpenAI могут меняться. Перед операционным решением стоит проверять актуальную документацию.

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