Diagrid выпустил Catalyst 2.0 с двумя функциями, которых агентным системам давно не хватало в боевой среде: восстановлением после сбоя без запуска всей цепочки заново и проверяемой историей действий. Для команд, которые уже тратят деньги на ИИ-агентов в продакшене, это не украшение интерфейса, а попытка убрать один из самых дорогих классов сбоев.
По сути, компания заходит не в гонку «чья модель умнее», а в более приземлённую и куда более полезную нишу: как сделать так, чтобы агент не терял прогресс посреди рабочего процесса и чтобы потом можно было доказать, кто именно выполнил действие.
Что Diagrid добавил в Catalyst 2.0
По данным The New Stack, Catalyst 2.0 добавляет к агентным фреймворкам слой durable execution и механизм подтверждения происхождения действий. В документации Diagrid это описано так: платформа сохраняет шаги рабочего процесса, переживает сбои, перезапуски и выкатывания новой версии приложения, а после восстановления продолжает выполнение с последней успешной точки, а не с нуля.
Второй слой связан с проверяемостью. Diagrid пишет, что Catalyst криптографически подписывает события в истории выполнения и помечает её как подменённую, если проверка не сходится. Проще говоря, это уже не просто логи, которым нужно верить на слово, а журнал, который можно проверить. Сама компания формулирует идею коротко: «Keep agents running. Prove every action».
Платформа не требует выбрасывать текущий стек. В документации Catalyst перечислены десять поддерживаемых агентных фреймворков, включая LangGraph, Microsoft Agent Framework, Google ADK, OpenAI Agents, CrewAI и Pydantic AI. Это важная деталь: Diagrid продаёт не новый язык и не ещё один «магический» конструктор агентов, а слой исполнения поверх уже используемых инструментов.
Почему проблема упирается в деньги и побочные эффекты
На демо агент легко проходит пять шагов подряд: получил задачу, сходил в API, вызвал инструмент, собрал ответ и завершил работу. В реальной эксплуатации всё ломается в самой неудобной точке: между вызовом модели, внешнего сервиса и записью результата. Если после этого агент стартует заново, команда повторно платит за токены, повторно вызывает инструменты и иногда повторно делает то, что повторять вообще не стоило.
И вот здесь начинается самое неприятное. Если агент уже успел создать заявку, отправить письмо клиенту или записать данные в CRM, обычный перезапуск превращается в источник дублей и ручной разбор полётов. Catalyst 2.0 как раз пытается развести две вещи, которые часто путают: память агента и надёжность исполнения. Первая отвечает за контекст, вторая — за то, чтобы система не разваливалась после первого же сетевого сбоя.
Куда смещается рынок агентной инфраструктуры
Для русскоязычной аудитории это сигнал о том, что рынок ИИ-агентов взрослеет и начинает упираться не в качество демо, а в эксплуатацию. Оркестрация, вызовы инструментов и маршрутизация уже есть у многих стеков. Узкое место теперь в другом: как пережить сбой в середине цепочки, как не задвоить действие и как показать службе безопасности или заказчику, что агент не получил лишних прав и не переписал историю задним числом.
Для стартапов это разговор про себестоимость и скорость запуска пилотов. Для корпоративных команд — про контроль, аудит и предсказуемость расходов. Для интеграторов и продуктовых команд — про то, что при выборе платформы уже мало смотреть на качество ответа модели: нужно проверять, как система ведёт себя после таймаута, деплоя и падения внешнего API.
Если этот класс платформ закрепится, конкуренция в агентной разработке пойдёт не только по качеству моделей, но и по куда менее гламурным вещам: восстановлению после сбоев, защите от повторных побочных эффектов и доказуемой истории выполнения. Оригиналы: документация Diagrid о durable execution, документация Diagrid о verifiable execution, страница продукта Catalyst.
Следующий логичный шаг для таких платформ — превратить «агент в продакшене» из рискованного эксперимента в обычный инженерный сервис, где сбой считается рабочим сценарием, а не поводом переписывать всё вручную.