OpenAI Agents API: agent infrastructure тепер можна не будувати самому

OpenAI випустила Agents API у public beta: hosted-харнес для агентів із сесіями, tools, MCP-серверами, паралельними subagents і керованими середовищами виконання – той клас інфраструктури, який команди досі збирали самі навколо model API. Продається тут не інтелект, а оркестрація. І тому головне питання до цього релізу не «наскільки розумна модель», а класичне buy vs build.

Що це таке

Agents API будується на трьох примітивах:

• Agent – конфігурація: модель, інструкції, tools і MCP-сервери, доступні агенту;
• Environment – опційний sandbox, де агент працює з файлами, підвантажує skills і запускає команди;
• Session – довгоживучий інстанс агента, який працює над задачею, приймає ввід і може тривати значно довше за один request/response.

Окремо заявлена підтримка паралельних subagents: незалежні підзадачі делегуються агентам, кожен із яких тримає власний контекст. Якщо ти колись будував це сам – ти знаєш, скільки коду ховається за цим одним реченням.

Приклад створення сесії виглядає приблизно так (за анонсом; API у beta, точний синтаксис звіряй з актуальними доками перед використанням):

const session = await client.beta.agents.sessions.create({
  agent: {
    model: 'gpt-6-astra',
    tools: [
      {
        type: 'mcp',
        server_label: 'observability',
        transport: {
          type: 'http',
          server_url: 'https://example.com/mcp',
        },
      },
    ],
    multi_agent: {
      enabled: true,
      max_concurrent_subagents: 3,
    },
  },
  input: 'Investigate elevated 5xx rate',
});

Зверни увагу на MCP як first-class транспорт для tools: ставка на stateless MCP 2026 як універсальний спосіб підключати можливості – вже не нішева ідея, а спільний знаменник екосистеми.

Що насправді продає Agents API

Не інтелект. Модель ту саму можна викликати й через звичайний API.

Продається інфраструктура:

• context management на довгих задачах;
• tool loop із retry і відновленням;
• subagents і їх координація;
• long-running execution, який переживає таймаути;
• environments із файлами й командами;
• recovery після збоїв.

Сформулюю різницю одним рядком: Model API відповідає на «що модель сказала». Agent API – на «як робота продовжується годинами й не розвалюється після першого timeout».

Це чесна пропозиція. Приблизно 80% командного часу в агентних проєктах іде не на промпти, а саме на цю обвʼязку – і вона в усіх приблизно однакова.

Build vs buy

Managed harness виглядає привабливо, якщо:

• оркестрація – не твій core IP, а податок на шляху до продукту;
• потрібні burst workloads: сьогодні 3 агенти, завтра 300;
• hosted sandbox знімає з тебе клас security-проблем, які ти не хочеш вирішувати сам;
• команда маленька і кожен інфраструктурний компонент – це мінус фіча продукту.

Self-hosted оркестрація має сенс, коли:

• потрібен повний контроль виконання: свої межі, свої ліміти, свій аудит;
• є regulatory constraints – дані не можуть виконуватись у чужому середовищі;
• важлива provider portability: harness, який працює з будь-якою моделлю, – це страховка від vendor lock-in (а він тут подвійний: і модель, і оркестрація);
• agent architecture – конкурентна перевага продукту. Якщо твій продукт і Є агент, віддавати його серцевину вендору – дивне рішення.

У 2026 агентна інфраструктура стає таким самим buy-vs-build рішенням, як auth, payments або observability. І, як і з auth, відповідь «купити» правильна частіше, ніж хочеться визнавати, – але не завжди.

Що залишається твоєю роботою в обох випадках

Managed harness не скасовує інженерію – він зміщує її:

• Observability. Трейси «що агент робив і чому» потрібні незалежно від того, чий while-loop крутиться. Як їх будувати – окремий розбір.
• Межі для рішень. Коли агент має зупинитись і спитати людину, вирішуєш ти, а не API. До речі, для типізованих рішень усередині агентного циклу OpenAI тепер має й окремий Decisions API – порівняння з Jev тут.
• Evals. Хостинг не відповідає за якість: регресії після зміни промпта чи моделі ловить тільки твій eval suite.

Об що спіткнуться перші користувачі

• Плутати beta-API з стабільним контрактом. Public beta означає: синтаксис і семантика можуть змінитись. Ізолюй виклики за власним інтерфейсом, щоб міграція коштувала один файл, а не весь проєкт.
• Заносити всі секрети в environment агента. Hosted sandbox – це чуже середовище. Короткоживучі креденшели з мінімальним scope – не рекомендація, а вимога.
• Вмикати subagents «бо можна». Паралельність без чіткої декомпозиції задачі множить вартість і плутанину, а не швидкість.
• Вважати, що managed = не треба думати про відмови. Сесія може впасти, environment – зникнути. Ідемпотентність твоїх tools досі на тобі.

Інвентаризація власного харнеса

Перед тим як переносити щось у Agents API, зроби інвентаризацію власного харнеса (якщо він є): випиши всі компоненти навколо твого while-loop – retry, контекст, tools, sandbox, логи. Для кожного постав оцінку: «це типова обвʼязка» чи «це наша унікальна логіка». Якщо типового більше 70% – ти кандидат на managed. Якщо унікального більше половини – твій харнес і є продукт, бережи його.