Сделать демо-агента легко. Подключаешь LLM к нескольким инструментам, добавляешь немного orchestration  - и система начинает работать. Но как только агент начинает обрабатывать реальные задачи и работать под нагрузкой, появляются знакомые проблемы распределённых систем: - задачи выполняются дважды; - воркеры падают посередине выполнения; - состояние сохраняется частично; - результат может появиться до завершения транзакции. В этот момент система начинает вести себя уже не как «агент», а как небольшой распределённый workflow-движок.

LLM здесь не главная проблема.

Главная проблема - инфраструктура исполнения.

Агенты - это вероятностные системы, которые работают внутри детерминированных production-сред, где требуются строгие гарантии: - задача должна выполниться один раз; - состояние не должно теряться; - результат не должен «утекать» до коммита; - система должна корректно восстанавливаться после сбоев.

Распределённые системы решают подобные задачи уже давно: durable execution, retries, idempotency, transactional state. Но в мире AI-агентов эти механизмы только начинают активно появляться. Сегодня есть несколько интересных направлений.

Temporal - workflow-движок с durable execution и deterministic replay. DBOS - экспериментирует с database-native execution, где функции выполняются поверх транзакционной базы данных. LangGraph - гибкий фреймворк для построения агентных workflow с checkpointing и persistence.

Эти инструменты помогают решать задачи orchestration. Но остаётся ещё один важный вопрос - корректность системы. Агентные системы одновременно принимают решения, вызывают инструменты и изменяют состояние. Если orchestration-логика содержит race condition или нарушение инвариантов, такие ошибки могут быть крайне трудно воспроизводимыми.

В академических работах всё чаще обсуждается идея комбинировать AI-агентов с формальными методами. Например, в работе «Trustworthy AI Agents Require Integration of LLMs and Formal Methods» (ICML).

Идея проста: LLM могут принимать решения, но инфраструктура исполнения должна иметь проверяемые свойства корректности.

Мы решили поэкспериментировать с этим подходом и сделали SGR Kernel - execution layer для AI-агентов с акцентом на надёжность системы. Основная идея: разработчик пишет обычный Python-код агента, а ядро берёт на себя гарантии выполнения - durable tasks, retries, управление состоянием и конкурентным доступом к задачам. SGR Kernel использует record-and-replay модель исполнения. Во время выполнения система записывает event log: входные данные, ответы инструментов и результаты шагов. При восстановлении система воспроизводит записанные события, не повторяя LLM-вызовы или side effects. Для распределённого выполнения используется optimistic locking: воркеры атомарно «забирают» задачи из очереди через транзакции базы данных. Это обеспечивает инвариант, что одновременно задачу может выполнять только один воркер.

Ключевые механизмы протокола выполнения - task claiming, commit semantics и retry logic, описаны в модели TLA+ и проверены с помощью model checker, который исследовал десятки тысяч возможных состояний системы.

Это не доказывает корректность всей реализации, но позволяет формально проверить архитектурные инварианты и обнаружить возможные race conditions на уровне модели.

Проект пока находится на ранней стадии, но цель проста: построить execution runtime для AI-агентов, которому можно доверять в production. Код открыт. Будет интересно услышать мнения от людей, которые тоже строят production-агентов и сталкиваются с проблемами orchestration, state management и durable execution.