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

> Agents API у public beta переносить агентний harness у managed cloud: сесії, tools, MCP, subagents, environments і довгі задачі. Розбираємо, що насправді продає API і коли self-hosted оркестрація досі виграє.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-10-15
- Категорія: AI в роботі розробника
- Canonical: https://cookiesoftware.io/blog/openai-agents-api-typescript

---

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, точний синтаксис звіряй з актуальними доками перед використанням):

```ts
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](/blog/mcp-2026-stateless-typescript) як універсальний спосіб підключати можливості – вже не нішева ідея, а спільний знаменник екосистеми.

## Що насправді продає 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 крутиться. Як їх будувати – [окремий розбір](/blog/ai-agent-observability).
- **Межі для рішень.** Коли агент має зупинитись і спитати людину, вирішуєш ти, а не API. До речі, для типізованих рішень усередині агентного циклу OpenAI тепер має й [окремий Decisions API – порівняння з Jev тут](/blog/openai-decisions-api-vs-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. Якщо унікального більше половини – твій харнес і є продукт, бережи його.