Каскадні відмови у багатокрокових агентах — це жорстко, ми це вже з'ясували. Семикроковий воркфлоу з надійністю 95% на крок дає приблизно 70% наскрізної надійності. Три з десяти запусків вибухають. Але ось що ніхто не фіксить: коли четвертий крок кидає HTTP 500, що відбувається з трьома кроками, які вже відпрацювали? Slack-повідомлення вже відправлене, рядок у базі вже записаний, Jira-тікет вже створений. Твій агент не знає, які кроки завершились. У нього немає чекпоінту — збереженої позиції для відновлення. І немає компенсаційної логіки — автоматичного "скасувати" для напівзробленої роботи.

Побачити відсоток відмов — це крок один. Пережити відмову — крок два. Крок два ніхто не шипить.

Театр відновлення

Усі три основні рантайми агентів запустили функції відновлення цього квітня. Жоден з них реально не вирішує відновлення.

Managed Agents від Anthropic (8 квітня) використовують append-only event log — журнал "тільки-на-запис" усього, що агент зробив. Впав? Перезавантажуйся, перечитай журнал, продовжуй. Їхня інженерна команда: "Нічого в обв'язці не має переживати краш." Звучить стійко. Але немає dead-letter queue для зафейлених задач, немає exactly-once гарантії, що кожна дія виконається рівно один раз, і немає способу відкотити вже виконані побічні ефекти.

Оновлення Agents SDK від OpenAI (15 квітня) додало знімки стану та регідратацію — збереження і відновлення стану агента між перезапусками контейнерів. Але воно зберігає історію повідомлень, а не стан виконання. Модель пам'ятає, що вона сказала; вона не відстежує, що зробила.

Google ADK (анонсований на Cloud Next, 22 квітня) постачає SequentialAgent, ParallelAgent, LoopAgent плюс ResumabilityConfig. Дрібний шрифт: викликаючий код має сам виявити переривання і повторно запустити агента вручну. Ніякого автоматичного відновлення.

Три різних підходи до стійкості. Усі три моделюють виконання як цикл інференсу — "думай → виклич інструмент → спостерігай → повтори." Жоден не моделює це як стійку скінченну автомат — систему, що точно відстежує, в якому стані вона перебуває і які переходи допустимі, як торговий автомат, що пам'ятає, що ти вже вкинув гривню, навіть після відключення світла.

Рішення, які вже існують (поза AI)

Рушії воркфлоу вирішили durable execution десять років тому. AI-індустрія просто їх ще не адаптувала.

Temporal обгортає кожен крок у повторювану, відтворювану активність. Впав посеред воркфлоу? Temporal відтворює з останньої завершеної активності — не з нуля. Ось як виглядає крок агента, обгорнутий у Temporal:

@activity.defn
async def file_jira_ticket(ctx: AgentContext) -> TicketResult:
    """Temporal автоматично ретраїть це при збої.
    Якщо агент впаде посеред воркфлоу, він відтворює
    з останньої завершеної активності — не з нуля."""
    return await ctx.tools.jira.create_issue(
        summary=ctx.draft.title,
        idempotency_key=ctx.run_id  # запобігає дублюванню тікетів
    )

Цей idempotency_key — унікальний ідентифікатор, що гарантує, що один і той самий запит не виконається двічі — і є вся різниця між "production-grade" та "вражаюче демо".

Cloudflare Project Think (15 квітня) пішов зовсім іншим шляхом: per-agent SQLite бази, step.do() чекпоінти, і безкоштовна гібернація. Кожен агент — це стійка ізольована сутність із власним персистентним станом, а не задача в централізованому оркестраторі. Для команд, які вже на Cloudflare Workers, це, мабуть, найчистіший шлях — без зовнішнього workflow engine, без message broker, просто durable objects з вбудованим чекпоінтингом.

Restate сидить посередині: легший за Temporal, більш структурований, ніж сирі durable objects. Він надає exactly-once гарантії з журнальним механізмом відтворення і вже опублікував прямі інтеграційні патерни з Google ADK.

Незручна середина

Ось проблема, яку ніхто не хоче визнавати: прірва працює в обидва боки.

Workflow engines не розуміють LLM. Вони не знають, що таке token budgets — скільки тексту AI може обробити за один виклик. Не вміють у model fallback routing — переключення на дешевшу модель, коли дорога влетіла в rate limit. Не мають поняття про версіонування промптів, управління контекстним вікном чи еволюцію схем tool-call. Прикрутити агентів до Temporal означає написати translation layer між "кроком воркфлоу" та "викликом інференсу" — і підтримувати його щоразу, коли провайдер моделі змінить свій API.

Агентні платформи не розуміють стійкість. Вони трактують виклики інструментів як ефемерні побічні ефекти інференсу, а не як переходи станів, що потребують транзакційних гарантій. LLM, що викликає інструмент, філософськи відрізняється від кроку воркфлоу, що викликає функцію: LLM може вирішити викликати інструмент ще раз, викликати інший інструмент або галюцинувати інструмент, якого не існує. Workflow engines припускають детерміновані визначення кроків. LLM за визначенням недетерміновані.

Жодна сторона не помиляється. Вони вирішують різні половини однієї задачі.

Що це означає для тебе

Якщо твій агент змінює зовнішній стан більш ніж у трьох кроках — відправляє листи, пише в базу, смикає сторонні API — тобі вже потрібні гарантії workflow engine. Твоя агентна платформа їх не дає. У тебе три варіанти:

  1. Прикрутити Temporal/Restate самому. Реальна складність інтеграції, але бойова стійкість. Має сенс, якщо ти ганяєш агентів у продакшені з реальними SLA.
  2. Піти all-in на Cloudflare. Якщо ти вже на Workers, Project Think дає тобі стійких агентів без оркестраційного оверхеду. Ціна: vendor lock-in.
  3. Прийняти відсоток відмов і побудувати ручну тулзу для звірки. Чесно кажучи, для внутрішніх інструментів з поблажливими юзерами це може бути раціонально. Тільки не називай це "production-ready".

Конвергенція неминуча. Перший вендор, який зашипить durable state-machine execution як дефолтний примітив агента — не як допис, не як стороння інтеграція — заволодіє шаром продакшн-надійності над усіма трьома рантаймами. Temporal це розуміє; їхня інтеграція з OpenAI Agents SDK — це захоплення території. Cloudflare це розуміє; Project Think спроектований, щоб зробити агентів фічею платформи.

Твоє семикрокове демо все ще працює чудово. Вишипити його в продакшн все ще означає обрати, з яким режимом відмови ти готовий жити.