Агент перестаёт ждать команды и начинает работать рядом

Публикация приложений ведёт к деньгам, а не только к витрине

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

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

Для небольшой команды это важный сигнал. Пользователь внутри компании может быть заинтересован в инструменте, но интерес не превращается в сделку, если закупка слишком тяжёлая. Когда оплата встраивается в уже знакомую статью расходов, барьер ниже. OpenAI при этом строит новый рынок вокруг своей инфраструктуры.

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

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

Decisions API показывает ставку на более быстрые действия

Ещё один практический сигнал - применение Decisions API в Computer Use для значительного ускорения работы. Если технология уже используется внутри такого сценария, направление явно не выглядит экспериментом, который существует только на слайдах.

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

Прямое подключение к приложению через API снимает часть этой нагрузки. Агент получает структуру и доступ к действиям без перетягивания экрана. Это может быть быстрее и точнее в повторяемой работе.

При этом API не отменяет Computer Use. Прямой доступ возможен, только если приложение его даёт. А автоматизация опасна, если агенту разрешено менять важные данные без границ, журнала действий и возможности отмены. Сначала полезно отдавать агенту просмотр и предложения. Правки лучше включать там, где понятны права, последствия и способ отката.

Один тип агента может работать в разных интерфейсах

dots, Codex и Agents API относятся к одному типу агента. Пользователь видит разные поверхности: среду для разработки, API для встраивания, другую инфраструктуру. Но за ними просматривается единая логика: агент получает задачу, контекст и инструменты, а затем действует.

Это полезно учитывать при проектировании собственного продукта. Не стоит привязывать сценарий к одному окну чата или одному экрану. Пользователь может начать задачу в Codex, продолжить её в приложении со схемой и затем получить результат через API. Контекст и правила работы должны переживать такой переход.

Есть 3 уровня, которые стоит разделить ещё до реализации:

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

Параллельная работа ценнее очередного диалога в чате

Показательный сценарий выглядит так. Во время планирования режима BitGN Sandbox для ECOM2 работа шла сразу в нескольких местах: задача обсуждалась в Codex, а схема собиралась в Wire. Затем агенту дали отдельную роль - посмотреть на схему и предложить изменения.

Wire - нативное приложение для macOS с API для одновременной работы и CLI. Агент подключился к нему напрямую, без Computer Use. Он оставил замечания и создал рядом новую схему, пока основная работа продолжалась в Codex.

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

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

Новый агентный режим нужно закладывать в продукт с первых экранов

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

Нужны не «умные подсказки» вообще, а конкретные договорённости: что агент видит, что может предложить, где создаёт черновик, кто подтверждает изменение и как вернуть предыдущее состояние. Эти правила можно описать ещё до написания интеграции.

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