СТАТТЯ

OpenAI Agents API (public beta): harness, MCP і sandbox очима Bubble-розробника

Віталій Дорошенко Опубліковано

Розбираємо анонс OpenAI Agents API: що бере на себе керований harness, де підійде зовнішній агентний шар замість складних Bubble workflows, і що це означає для швидкого запуску MVP.

Коли з'являється черговий AI API, засновники та творці no-code продуктів часто ставлять одне й те саме питання: чи варто переписувати власну логіку, чи це просто чергова надбудова? 10 вересня 2026 року OpenAI відкрила у public beta Agents API. Це не просто оновлення викликів моделей через Responses API чи бібліотека на кшталт Agents SDK — це перенесення керованого середовища виконання (harness на базі Codex) безпосередньо на хмарну інфраструктуру OpenAI.

Для тих, хто запускає MVP на Bubble або експериментує з вайбкодінгом без глибокого бекенд-бекграунду, ця новина відкриває зрозумілий практичний поділ: що варто довірити готовому агентному рушію, а що обов'язково має залишатися всередині Bubble.

Три складові Agents API: що всередині

Сервіс спирається на три базові примітиви:

  1. Agent — конфігурація моделі, інструкції поведінки та підключені інструменти (tools і MCP).
  2. Environment — середовище виконання коду. Це може бути none, хмарний openai_hosted (Linux-пісочниця з /workspace, Python, Node.js та ізольованою мережею) або self_hosted (на власних серверах чи партнерських платформах на кшталт Blaxel, Cloudflare, Daytona, Modal, Vercel тощо).
  3. Session — довготривала сесія роботи, яка автоматично зберігає історію поворотів розмови (turns), проміжні події та стан до явного видалення.

Разом вони утворюють керований harness: OpenAI автоматично виконує циклічний loop роздумів моделі, бере на себе компакцію довгого контексту, мультиагентну делегацію subagents і programmatic tool calling. За сам Agents API окрема підписка не стягується — тарифікуються лише використані токени та виклики інструментів.

Де межа: що лишається в Bubble, а що йде назовні

При швидкій перевірці гіпотез не потрібно намагатися перенести весь додаток в AI. Робоча схема для Bubble виглядає дуже конкретно:

  • Що залишається в Bubble:

    • Авторизація користувачів і розмежування прав (privacy rules).
    • Звичні CRUD-операції з даними та зберігання бізнес-сутностей у базі Bubble.
    • UI/UX, тригери інтерфейсу, платіжні сценарії (Stripe) та продуктові правила вашого MVP.
    • Збереження отриманого session_id від OpenAI у полі користувача чи замовлення.

  • Що віддається зовнішньому агентному шару OpenAI:

    • Довгі автономні ланцюжки міркувань (turns), де модель пробує кілька кроків підряд.
    • Виконання коду, обробка файлів і парсинг даних у захищеному sandbox (openai_hosted).
    • Паралельна робота subagents і автоматичне стиснення контексту без ручного підрахунку токенів у Bubble workflows.
    • Підключення до публічних HTTP MCP-сервісів (connection origin: service).

Як зв'язати Bubble і Agents API: практика інтеграції

Для типового no-code стека інтеграція будується через стандартні інструменти:

  1. Старт сесії через Bubble API Connector. Створюється REST-виклик POST https://api.openai.com/v1/agents/sessions із заголовком OpenAI-Beta: agents=v1 та ключами з дозволами (наприклад, api.agents.read/write, api.responses.write). Bubble передає початкове завдання і записує повернений ідентифікатор сесії.
  2. Зворотний канал зв'язку. Сам API Connector призначений для вихідних запитів і не вміє напряму приймати вхідні події. Тому для асинхронних оновлень використовується відкритий Bubble Backend API Workflow як webhook-ендпоінт, що приймає події agent.session.* або статус action_required (якщо агенту потрібні дані від вашої бази). Для простих MVP першим кроком часто є періодичний polling статусу сесії через звичайний API Connector call.
  3. Обмеження по MCP. Якщо ви використовуєте Model Context Protocol (MCP) через прямий HTTP-сервіс (connection_origin: service), OpenAI підключається до нього сама без окремого сервера. Але якщо інструмент вимагає stdio або локальний environment-origin до внутрішніх адрес, для цього потрібен власний worker або self-hosted executor. У чистому Bubble без додаткового коду такі сценарії реалізувати складно, тому для швидкого старту варто фокусуватися виключно на публічних HTTP endpoints або функціях зворотного виклику.

Як зв'язати Bubble і Agents API: практика інтеграції

Мультивендорний контекст: чи варто дивитися на альтернативи?

Agents API вийшов у публічну бету не у вакуумі. Anthropic розвиває свої Claude Managed Agents (також у public beta з квітня 2026), а в екосистемі AWS присутній Bedrock AgentCore з фокусом на мультімодельність та корпоративне управління. Проте для творця no-code застосунку ключова архітектура залишається однаковою: Bubble — це ядро продукту та UI, а вендорний harness — це зовнішній виконавець складних завдань.

Важливі обмеження та ризики для MVP:

  • Статус beta: API позначений як agents=v1 і може зазнавати змін; обов'язково закладайте обробку помилок у ваших workflows.
  • Turn.completed ≠ успіх: завершення кроку агента означає лише те, що модель закінчила дію, але не гарантує, що результат відповідає бізнес-логіці.
  • Безпека та комплаєнс: за офіційною документацією Agents API наразі підтримує data residency лише в US і не має опції Zero Data Retention (ZDR). Стан сесії зберігається на боці OpenAI до її видалення, тому уникайте передачі чутливих персональних даних через відкриті промпти.

Для першого релізу та збору відгуків інвесторів чи перших платних користувачів поєднання Bubble + OpenAI Agents API дозволяє отримати повноцінного автономного асистента за лічені дні без написання власного оркестратора на Python чи Node.js.

Схожі статті

← Усі статті