Short answer: Надійне виконання для AI‑агентів означає, що план агента та його побічні ефекти переживають рестарти, розриви мережі, нестабільні інструменти та очікування на людину — без втрати коректності. Ми структуруємо цикл агента як надійний workflow, ізолюємо побічні ефекти в ідемпотентні інструменти, робимо чекпойнти стану на кожному рішенні та використовуємо реплей для дебагу й оцінювання. Рантайми на кшталт Temporal або керовані сервіси воркфлоу дають таймери, сигнали та детерміновану оркестрацію — те, чого бракує нотатникам і простим чергам. Людина в контурі стає повноцінним станом очікування зі SLA, а не імпровізованою паузою. Так ми закриваємо розрив між хайпом і продакшеном: агенти, які реально завершують роботу, за дні, рівно один раз.

Durable execution for AI agents: definition and scope

Більшість демо агентів припускає швидкий безперервний цикл: поміркувати, викликати інструмент, знову поміркувати — і все. У продакшені агенти не живуть у такому світі. Вони координують довготривалу роботу через API, користувачів і системи з різною затримкою та збоями.

Надійне виконання дає три конкретні гарантії:

  • Прогрес переживає збої. Якщо воркер падає чи йде деплой, агент відновлюється з останнього безпечного чекпойнта без повторення небажаних побічних ефектів.
  • Exactly‑once наміру. Зовнішні ефекти (листи, тікети, платежі, записи у файли) відбуваються один раз, навіть якщо всередині ми ретраїмо багато разів.
  • Аудит і реплей. Ми можемо відтворити, що вирішив агент, які інструменти викликав, що повернулося і чому він обрав наступний крок.

Для AI‑агентів ці гарантії накладаються на недетерміновані компоненти (LLM, сторонні API). Ми не намагаємося зробити LLM детермінованим. Ми робимо оркестрацію детермінованою і записуємо недетерміновані виходи як події. Це дає надійний прогрес і чесну форензику.

The failure modes that break naive agents

Коли команди ведуть прототип у продакшен, повторюються ті самі сценарії поломок. Надійне виконання спроєктоване, щоб їх нейтралізувати.

  • Смерть процесу й деплої. Ефемерні воркери помирають. Без персистованого стану й таймерів багатогодинний агент тихо зникає посеред виконання.
  • Мережеві розриви й нестабільні API. Виклики інструментів тривають хвилини, тайм‑аутяться, успішно завершуються пізно або двічі. Наївні ретраї створюють дублі й неконсистентний стан.
  • Недетермінізм LLM. Семплінг дає інші виклики інструментів при повторі, тож відновлення після збою небезпечне, якщо ми не фіксуємо рішення.
  • Латентність людини. Кроки з погодженням зупиняються на години або дні. Якщо стан агента в RAM, він зникне до того, як хтось натисне Approve.
  • Зсув годинника й розкладу. Пауза через cron і sleep не переживає рестартів і не має надійних хендлів; таймери губляться.
  • Зсув схем. Пейлоади інструментів еволюціонують. Без версійованого стану й міграцій старі запуски стають нечитаємими й непридатними до реплею.
  • Часткові побічні ефекти. Крок записує дані в одну систему і не записує в іншу. Немає компенсації і немає реєстру для звірки.

Надійне виконання робить кожен із цих аспектів першокласним: час, ідемпотентність, очікування людини й компенсації живуть в оркестраторі, а не в розрізнених try/catch.

Patterns that make agents durable

Мета проста: зробити оркестрацію детермінованою, побічні ефекти — ідемпотентними, а час — стійким. Ось патерни, на які ми спираємося.

Саги та компенсації

Агенти рідко мають ACID‑транзакції між сервісами. Використовуємо патерн Saga: розбиваємо роботу на кроки з прямими діями і компенсаціями. Якщо крок N+1 безповоротно падає, запускаємо компенсації для кроків 1..N, щоб відновити консистентний бізнес‑стан.

  • Прямі дії: створити тікет, записати запис, надіслати лист.
  • Компенсації: закрити/відкотити тікет, видалити запис або позначити як недійсний, надіслати виправний лист.
  • Реєстр: зберігати, які компенсації ще можливі; компенсації теж мають бути ідемпотентними.

Саги тримають зовнішній світ агента консистентним, навіть коли інструменти збиваються або люди не схвалюють зміни після часткового виконання.

Ідемпотентні інструменти й дедуплікація

Ми обгортаємо кожен побічний ефект інтерфейсом інструмента, який приймає ключ ідемпотентності та повертає стабільний зовнішній ID. Якщо оркестратор ретраїть інструмент, провайдер або повертає початковий успіх, або нічого не робить.

  • Ключі ідемпотентності на логічну дію, а не на спробу.
  • Природні ключі де можливо (напр., «invoice for order-123»).
  • Кеші дедуплікації з нашого боку, коли апстрім не має ідемпотентності; мапимо логічні ключі на відповіді провайдера.
  • Версійовані інструменти, щоб еволюціонувати пейлоади без псування реплею старих запусків.

Ідемпотентність — це різниця між безпечними ретраями та дублями побічних ефектів. Ми ніколи не шипимо без неї.

Чекпойнтинг стану й рішень

Ми персистимо стан агента після кожного змістовного кроку: план, обраний інструмент, аргументи, сирі й розібрані відповіді, а також будь‑які введення від людини. Не покладаємося на «чернетку» LLM для відновлення контексту.

  • Журнал запуску: структурований лог кроків із таймстемпами, промптами, відповідями, викликами інструментів і артефактами.
  • Статуси кроків: успіх, заплановано повтор, заплановано компенсацію, очікування сигналу, перервано.
  • Розділення даних: PII або секрети зберігати поза загальною розмовою і підвантажувати за посиланням; шифрувати на диску.
  • Версія схеми: фіксувати версію схеми стану на кожному кроці для підтримки міграцій.

З чекпойнтами рестарт відновлюється з останнього зафіксованого рішення. Ми уникаємо повторного запиту до LLM на те саме рішення, якщо цього явно не хочемо.

Детермінізм реплею та event sourcing

Ми трактуємо недетерміновані виходи як події. На холодному реплеї підсовуємо записані події у воркфлоу замість їх повторної генерації. Це дає покроковий детермінізм без «заморожування» моделі.

  • Записуйте один раз кожен недетермінований результат: виходи LLM, випадкові ID, значення, залежні від часу, відповіді зовнішніх API.
  • Чистий код оркестрації, що під час реплею використовує записані події; той самий код виконується й у лайві, читаючи подієвий лог.
  • Вибіркове повторне виконання, коли нам навмисно потрібен інший результат (напр., політика тепер забороняє раніше дозволений інструмент). Ми позначаємо подію невалідною і продовжуємо з того місця.

Реплей дозволяє дебажити з хірургічною точністю, запускати офлайнові евяли на реальній історії та відтворювати продакшен‑баг без здогадок про промпти чи таймінги.

Стійкий час: таймери, хартбіти та лізи

Асинхронній роботі потрібні стійкі уявлення про час і володіння. Ми не «присипляємо» треди; ми ставимо таймери й хартбіти в оркестраторі.

  • Стійкі таймери будять воркфлоу через хвилини, години або дні. Таймери переживають рестарти й деплої.
  • Хартбіти від активностей (обгорток інструментів) дозволяють нам скасовувати або ретраїти довгі виклики та виявляти завислі воркери.
  • Лізи на зовнішні ресурси не дають двом воркерам діяти над одним елементом одночасно.

Зі стійким часом агент може поставити на паузу очікування відповіді користувача або вікно бекоффу вендора без утримання обчислювальних ресурсів і без втрати позиції.

Людина в контурі як сигнал першого класу

Погодження й уточнення — це не винятки. Ми моделюємо їх як сигнали, що розблоковують очікування з SLA та шляхами ескалації.

  • Стан очікування з дедлайнами. Якщо дедлайн минув — автоескалація, автоденай або маршрут на фолбек.
  • Дифи артефактів для рев’ю (напр., пропоновані зміни в PR, чернетки листів, деталі платежу) для швидких і безпечних апрувалів.
  • Контроль доступу — хто може схвалювати які дії; апрували стають підписаними подіями в журналі запуску.

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

Бекоф, circuit breakers і бюджети

Коли інструменти поводяться погано, ми швидко фейлимося і захищаємо систему.

  • Експоненційний бекоф із джитером і стелями для кожного інструмента.
  • Circuit breakers, що відкриваються при стрибку помилок; маршрут у черги на ручний перегляд.
  • Бюджети помилок на кожну здатність агента. Якщо бюджет вичерпано — деградуємо або вимикаємо ризикові дії.

Це охороняє надійність агента і обмежує зону ураження під час відмов вендорів чи змін схем.

Choosing an execution substrate

Нам потрібен рантайм, що персистить стан воркфлоу, дає стійкі таймери й сигнали та виконує оркестрацію детерміновано попри збої. Є кілька варіантів; вибір залежить від вашого стеку та операційних обмежень.

  • Temporal: код‑перші надійні воркфлоу з сильними гарантіями щодо детермінізму, таймерів, сигналів і реплею. Чудово підходить для довготривалих агентів. Потрібно оперувати сервісом або користуватися керованою пропозицією, плюс дисципліна в еволюції коду воркфлоу.
  • AWS Step Functions: керовані воркфлоу з інтеграціями сервісів. Добре для AWS‑центричних стеків і коротших логічних флоу. Менш природно для ітеративних циклів інструментів LLM, але можливо з продуманим станом і зовнішніми активностями.
  • Azure Durable Functions / GCP Workflows: мовно‑інтегровані надійні патерни у своїх екосистемах. Подібні компроміси до Step Functions.
  • Zeebe/Camunda: BPMN‑орієнтований рушій із сильним моделюванням процесів і масштабуванням. Корисно, якщо ви вже моделюєте бізнес‑процеси візуально й можете відобразити стани агента в BPMN.
  • Argo Workflows: контейнерні DAG на Kubernetes. Найкраще для батчу й дата‑тасок; може підтримувати кроки агента з кастомними контролерами, але бракує готових семантик детермінованого реплею.
  • Вбудована персистенція у фреймворках: деякі агентні фреймворки/бібліотеки дають граф‑виконання й чекпойнтинг. Корисно для старту, але перевіряйте гарантії таймерів, ідемпотентності й реплею між версіями, перш ніж робити ставку.

Ми уникаємо ад‑хок міксів черг, cron і базової таблиці «runs», якщо не готові перевинайти пів рушія воркфлоу. Це виглядає просто, а потім тихо з’їдає місяці на крайові випадки: втрачені таймери, подвійні доставки, неконсистентні ретраї й нетрасовані дедлоки.

Критерії рішення, які ми застосовуємо:

  • Відповідність мові до ваших ключових сервісів і скілів команди.
  • Модель детермінованого реплею і стратегія міграції при змінах коду воркфлоу.
  • Таймери й сигнали, що переживають рестарти та мають сильні гарантії доставки.
  • Операційна модель: керований сервіс vs self‑hosted; латентність, пропускна здатність, придатність до спостереження.
  • Складність інтеграцій із вашими секретами, ідентичністю та межами VPC.

Migration path: from prototype to durable production

У більшості команд уже є робочий прототип агента. Чудово. Ми зберігаємо поведінку, але змінюємо «скелет», щоб він витримував реальні таймінги та збої. Ось шлях, яким ми йдемо.

  1. Заморозьте критичний бізнес‑шлях. Запишіть мінімальний набір дій, які агент має виконати, щоб приносити цінність. Все інше можна відкласти.
  2. Винесіть побічні ефекти в інструменти. Обгорніть кожен виклик, що змінює світ (тікети, листи, платежі, репозиторії), за межу інструмента з ключами ідемпотентності.
  3. Додайте журнал запуску. Запровадьте структурований лог промптів, викликів інструментів, виходів і введень людини. PII та секрети тримайте за посиланнями, не інлайньте.
  4. Уведіть надійний оркестратор. Перенесіть цикл (plan‑act‑observe) у рушій воркфлоу, що підтримує таймери та сигнали. Інструменти лишіть як активності, що можуть ретраїтися й надсилати хартбіти.
  5. Чекпойнтьте після кожного рішення. Персистьте план, обраний інструмент, аргументи й виходи. Відновлюйтеся з чекпойнтів, а не перепитуйте LLM.
  6. Моделюйте людські кроки як сигнали. Замість ад‑хок блокувань — надійні очікування, дедлайни та ескалації. Відкривайте артефакти для рев’ю.
  7. Робіть інструменти ідемпотентними й безпечними за замовчуванням. Додайте ключі ідемпотентності, таймаути, бекоф і circuit breakers. Логуйте стабільні зовнішні ID для аудиту.
  8. Підключіть спостережуваність. Додайте trace‑ID крізь воркфлоу, виклики LLM й інструменти. Метрики: успішність, ретраї, тривалість очікувань, частота компенсацій.
  9. Увімкніть реплей і пісочниці. Зберігайте недетерміновані події. Побудуйте хаскіс для реплею, що проганяє прод‑історію офлайн на останньому коді.
  10. Визначте SLA та бюджети помилок. Задайте цілі для латентності, частки завершень і максимуму дублів побічних ефектів. Автоматизуйте деградацію, коли бюджети вибиті.
  11. Плануйте еволюцію схем і коду. Версіонуйте стан, інструменти й промпти. Пишіть шими міграцій для запущених флоу перед деплоєм несумісних змін.

Типові пастки, яких слід уникати:

  • Ігнорування ідемпотентності через те, що провайдер «рідко» дублює запити.
  • Зберігання всього в транскрипті замість моделювання структурованого стану та артефактів.
  • Використання sleep для багато годинних очікувань замість надійних таймерів.
  • Вшивання викликів інструментів усередину кроку LLM, тож не можна ретраїти або компенсувати окремо.
  • Хардкод промптів без версіонування, що робить реплей неможливим, а аудити — непереконливими.

Виконуйте міграцію шматками. Почніть з однієї здатності end‑to‑end, доведіть надійність, далі розширюйтеся на сусідні флоу.

How Moai Team approaches this

Ми будуємо агентів, що доходять до продакшену і там залишаються. Надійне виконання — не післямова в наших проєктах; саме на нього ми спрямовуємо інженерну увагу після першого вдалого демо. Наш підхід прагматичний: зберегти те, що працює, замінити «скелет» під ним і шипити з запобіжниками з першого дня.

  • Скопінг до критичного шляху. Ми «обрізаємо» здатність до суті, щоби спроєктувати ідемпотентні інструменти та компенсації для небагатьох важливих дій.
  • Інженерія хаскісу. Формалізуємо цикл агента як детермінований воркфлоу з чекпойнтами стану, таймерами й сигналами. Уникаємо прихованого стану в пам’яті та ізолюємо побічні ефекти.
  • Зміцнення інструментів. Обгортаємо зовнішні системи ідемпотентністю, політиками ретраїв, бекоффом і circuit breakers. Додаємо спостережуваність і стабільні зовнішні ID для аудиту.
  • Дебаг і еввали з реплею в основі. Записуємо недетерміновані результати та будуємо хаскіс реплею, щоб відтворювати проблеми й міряти апдейти до релізу.
  • Людина в контурі за дизайном. Робимо апрували й уточнення надійними — з дедлайнами й ескалаціями. Виносимо компактні артефакти для швидкого рев’ю.
  • Говернанс і SLA. Визначаємо бюджети помилок, гейти розгортання та режими деградації. Якщо бюджет вибито, агент автоматично відступає або перемикається на безпечніший шлях.
  • Глибина інтеграції. Підключаємося до реальних систем запису та безпечно рухаємо дані крізь межі ідентичності, секретів і комплаєнсу. Ми не шипимо тіньові бази.

Результат простий на словах і складний для підробки: агент завершує довготривалу роботу рівно один раз, із ланцюжком доказів і планом відкоту. Це різниця між демо і продакшен‑системою. Це розрив, який ми закриваємо.

Frequently Asked Questions

What is the difference between durable execution and a queue with retries?

Черга з ретраями просто переграє всю задачу при збої. Надійне виконання персистить стан‑машину роботи, тож ми відновлюємося з останнього безпечного кроку, а не з початку. Воно також дає стійкі таймери, людські сигнали та семантику exactly‑once для побічних ефектів через ідемпотентні інструменти. Черги чудові для незалежних коротких задач. Довготривалим агентам потрібен рушій воркфлоу.

Do I need Temporal to get durable execution for AI agents?

Ні. Temporal — сильний варіант, але можна реалізувати надійне виконання керованими опціями на кшталт AWS Step Functions, Azure Durable Functions або GCP Workflows, а також BPM‑рушіями Zeebe/Camunda. Головне — виконати вимоги: персистований стан, стійкі таймери й сигнали, детермінована оркестрація та можливість реплею. Ми обираємо субстрат, який пасує вашому стеку й операційній моделі.

How do you keep determinism when an LLM is nondeterministic?

Ми робимо оркестратор детермінованим і трактуємо кожен недетермінований результат як записану подію. На реплеї підсовуємо записані події замість їх регенерації. Текст промптів і схеми інструментів версіонуємо. Так ми відтворюємо будь‑який минулий запуск точно, водночас у лайві система може вільно семплити.

How do you add human approval steps without stalling the agent?

Моделюйте апрували як надійні стани очікування з дедлайнами. Використовуйте таймери для автоескалації або вибору безпечного дефолту після дедлайну. Пакуйте артефакти для швидкого рев’ю і обмежуйте, хто може схвалювати які дії. Агент «спить» у сховищі, а не в треді, і прокидається, коли приходить сигнал або спрацьовує таймер.

What does “exactly‑once” really mean for external systems?

Ми наближаємо exactly‑once через дизайн ідемпотентних інструментів і дедуплікацію. Кожна логічна дія має стабільний ключ ідемпотентності, а ми зберігаємо отриманий зовнішній ID. Якщо стається ретрай, провайдер повертає той самий результат або ми виявляємо попередній успіх і пропускаємо. Це прибирає дублікати листів, подвійні тікети й повторні записи.

Can we bolt durable execution onto our existing prototype without a rewrite?

Часто так. Почніть із винесення побічних ефектів в ідемпотентні інструменти, додавання журналу запуску та перенесення циклу оркестрації у воркфлоу. Збережіть промпти й схеми інструментів, але версіонуйте їх. Міґруйте одну здатність end‑to‑end, зробіть висновки й розширюйтеся.

Маєте прототип, який сиплеться в полі, або роадмап, що потребує надійного виконання? Напишіть нам у Moai Team — контакти. Ми прокладемо найкоротший шлях від демо до продакшену.