Ти зібрав агента. Протестував на ноуті. Він працював — навіть красиво. І ти запушив його в прод так, як у 2003 році деплоїли сайти: відредагував файл на сервері, натиснув «зберегти», помолився.

А потім о другій ночі твій агент починає галюцинувати виклики тулів, розсилати листи людям, які нічого не просили, і палити API-бюджет як матрос у портовому барі. Ти тягнешся до кнопки «відкотити». Кнопки немає. Попередньої версії немає. У твого агента немає версій — це системний промпт у текстовому полі, купка конфігів тулів і те, що залишилось у твоїй голові.

Ласкаво просимо в деплой агентів, квітень 2026.

Платформи запустили. Пайплайни — ні.

Між 8 і 22 квітня три гіперскейлери один за одним випустили свої агентні платформи: Managed Agents від Anthropic (8 квітня) із хостованими пісочницями та CLI ant, Agents SDK v0.14 від OpenAI (15 квітня) з шістьма мінорними релізами за десять днів, і ADK 1.0 від Google на Cloud Next (22 квітня) із мультимовними SDK та дашбордом для моніторингу. Порівняння фіч ми вже робили. Чого не випустив жоден: дисципліни деплою.

Як написали xpander.ai 24 квітня: "Чого вони не пропонують: мультихмарної портативності, нативного CI/CD для агентів, версіонування, відкату чи канаркових деплоїв." Кожен гіперскейлер отримав оцінку "DIY" за життєвий цикл агента.

Справедливості заради — Anthropic підійшов найближче. CLI ant обіцяє промоцію зі staging у production. Але в їхньому власному інженерному блозі нуль згадок про відкат, канаркові деплої чи blue-green перемикання. Версіонування існує; дисципліна деплою — ні.

Чому агенти зламали CI/CD

CI/CD — continuous integration та continuous deployment — це те, як нормальний софт потрапляє в прод. У тебе є деплойний артефакт (Docker-образ, скомпільований бінарник), ти тестуєш його на staging (безпечна копія проду), пускаєш канарку (5% трафіку на нову версію), і якщо щось ламається — відкочуєш однією командою.

У агентів немає єдиного артефакту. Поведінка агента живе щонайменше на чотирьох поверхнях:

# Поверхня 1: Код (версіонується в git)
agent = Agent(model="claude-sonnet-4", tools=[search, email, calendar])

# Поверхня 2: Системний промпт (часто редагується в дашборді, не в git)
SYSTEM_PROMPT = "You are a scheduling assistant who..."

# Поверхня 3: Конфіги тулів (дозволи, рейт-ліміти, API-ключі)
# Поверхня 4: Пам'ять / вивчений контекст (живе... десь)

Системний промпт і описи тулів — найкритичніші компоненти поведінки, але за замовчуванням вони живуть поза version control. Саймон Віллісон продемонстрував це 18 квітня, вручну створивши Git-історію з підробленими датами комітів лише для відстеження змін промптів — зворотна інженерія версіонування, яке мало б бути фічею платформи.

Як самі Anthropic визнали: "Щоб задеплоїти production-grade агента, команді потрібно побудувати не лише самого агента, а й значний обсяг інфраструктурного обвʼязування."

Ера ізоленти

Обхідні шляхи існують. Можна версіонувати файли промптів у git. Можна робити blue-green свопи вручну. Можна фіче-флажити списки тулів. Ось мінімально життєздатне "версіонування агента":

# Саморобне версіонування агента
agent_config = {
    "version": "1.4.2",
    "prompt_sha": "a3f8c1d",  # git hash файлу промпта
    "tools": ["search_v2", "email_v1"],
    "permissions": {"email": {"max_per_hour": 10}},
    "model": "claude-sonnet-4",
}
# Деплой: завантажити конфіг → валідувати → переключити трафік
# Відкат: завантажити попередній конфіг → переключити назад

Але це ізолента, яка вимагає дисципліни, котру жодна платформа не забезпечує. І все розвалюється в той момент, коли зʼявляється памʼять агента — контекст, накопичений за сесії. Неможливо відкотити те, що агент запамʼятав.

Наскільки все може бути погано? У березні 2026 року пост-мортем Reworkd задокументував один невдалий деплой промпта, який спричинив 14 000 помилкових API-викликів за 47 хвилин — $2 300 токенів, перш ніж хтось помітив. Без канарки. Без відкату. Тільки Slack-алерт, що прийшов запізно. Помножте це на тисячі команд, які зараз будують агентів без деплойних гарантій, і ви побачите масштаб проблеми.

Що робити прямо зараз

Якщо ви будуєте агентів сьогодні: ставтеся до кожного промпта, конфігу тулів і політики дозволів як до infrastructure-as-code. Тримайте їх у version control. Ніколи не оновлюйте production-агента без попереднього тестування staging-копії. Закладайте час на побудову деплойної обвʼязки, яку ваш вендор платформи пропустив. Це не опціонально — це різниця між демкою і продуктом.

Шар, якого бракує

Памʼятаєте, ви починали цей шлях, редагуючи файл на сервері. Саме тут зараз перебувають агенти — до-Docker-ова ера "на моїй машині працює". Платформа, яка перша зробить агентний CI/CD примітивом за замовчуванням — staging, канарка, відкат, з агентом як версіонованим артефактом — захопить операційний шар, що знаходиться вище за якість моделі та кількість тулів. Це справжній приз, і станом на 26 квітня 2026 року його ще ніхто не забрав.