Анатомия автоматизации Fractera — онтология из 13 сущностей | Агентная инженерия

Fractera — это Agentic Engineering Infrastructure: защищённый самохостинг-воркспейс, где ИИ-модели пишут и запускают твоё приложение на твоём сервере. Этот документ — плотный, но живой разбор одной его части: онтологии автоматизаций. Он написан так, чтобы его одинаково понимали технический человек и ИИ-агент.

Что такое автоматизация здесь

Не скрипт, написанный с нуля, а сборка из типовых сущностей — как конструктор: деталей конечное число, но из них собирается что угодно. Агент (или человек) описывает автоматизацию графом, а движок проверяет граф по канону и материализует его в живую страницу с диаграммой, таблицами и рабочим процессом. Смысл: у любой автоматизации — единый словарь. Поэтому её можно сгенерировать надёжно (ИИ не может «намахать рукой») и прочитать (человек видит ровно то, что построено).

Из чего она собрана — 13 сущностей, четыре класса

A. Определение правила («когда X, при условии Y, сделай Z»)

• Automation — сам контейнер-правило (один проект = одна автоматизация).
• Trigger — что запускает прогон: сообщение, расписание, ручной запуск, вебхук или событие от другой автоматизации.
• Hook — произносимая фраза, привязанная к действию («запомни это» → сохранить). Фирменная голосовая специфика Fractera.
• Condition — объявленный страж: «выполнить только если…».
• Action — именованный результат (сохранить / напомнить / ответить). Центральная сущность: настроить автоматизацию = настроить Actions.
• Router — классификатор: превращает событие в конкретное действие.
• Step — атомарная операция (вызов API, запись строки).

B. Ресурсы

• Integration — внешний сервис и его ключи (Telegram, OpenAI, память).
• Channel — куда уходит результат действия (чат бота, письмо, страница).
• State — данные между запусками (курсор опроса, векторная память).

C. Рантайм

• Run — один экземпляр исполнения (журнал прогонов).
• Record — долговечная строка-результат (+ документ памяти) в универсальной таблице.

D. Кросс-автоматизация

• Subject (13) — долгоживущий объект, над которым работают НЕСКОЛЬКО автоматизаций (блогер, лид, ученик): один стабильный id, статус-машина и вся история по этому id.

Почему этому можно доверять — гейты

Канон — это закон с зубами. Движок отклоняет граф, который его нарушает: у каждого действия есть свой узел; узлы ссылаются только на объявленные действия; есть Router, если объявлены Hooks; названное условие непусто; колонки таблицы — из закрытого набора типов над реальными данными; событийный триггер обязан назвать, на что подписан; переход статуса — только внутри объявленной статус-машины.

Как автоматизация рождается из твоих слов — и кто её строит

Ты говоришь: «автоматизируй создание курсов с проверкой знаний». Дальше — две фазы, два актора. Первая — оркестрация: Гермес (или любой агент — навык оркестрации продублирован во ВСЕ агенты, не только Гермес) читает канон, пишет граф, движок его валидирует и материализует каркас: обзор проекта, диаграмму, рабочий процесс и очередь шагов. Кода ещё нет. Вторая — разработка: каждый шаг очереди — это делегирование кодеру; сильный агент (Claude Code / Codex / …) в отдельной сессии берёт один шаг и пишет его тело. Оркестратор не программирует сам — он раздаёт номера шагов.

Жизненный цикл — автоматизация не готова с одного запроса

• Создание → каркас и очередь шагов (фрагментация запроса).
• Развитие → кодер достраивает шаги по одному; кокпит показывает очередь в реальном времени.
• Настройка → ключ бота, интервал, хуки — прямо на странице автоматизации, без кода.
• Возобновление → под описанием автоматизации есть ссылка «продолжить редактировать и настраивать» — она ведёт в кокпит разработки, сфокусированный на этом проекте.

Когда автоматизаций несколько — pub/sub-хендофф

Одна автоматизация публикует событие («урок готов»), не зная, кто слушает. Другая подписана на это имя и просыпается. Общий Subject несёт статус и историю через обе — переход это смена статуса плюс событие, никогда не копирование строки между таблицами. Пример: «конструктор курса» создал урок → событие → «проверка знаний» запустила квиз. Ученик прошёл `записан → урок готов → проверен`, и вся его история — по одному id.

Где живут ссылки на созданные страницы

Результат работы автоматизации — Record. Ссылка на созданную страницу (например, урок ученика) пишется в результат прогона (`result_url`) и показывается в таблице колонкой-ссылкой «Открыть». Таблица результатов config-driven: автоматизация объявляет свои колонки в графе, движок их генерит, единая универсальная таблица их рисует. Никто не программирует таблицу вручную — новая колонка это расширение графа, а не правка компонента.

Рамки, в которых агент развивается

Канон — это не только словарь, это граница свободы агента, и это, пожалуй, главное. Агент всегда знает, где его граница: расширяй ГРАФ, не обходи схему.

• Может: авторить граф из 13 сущностей; расширить граф и перезапустить движок; реализовать тело шага; настраивать автоматизацию.
• Не может: добавить «теневой шаг», которого нет на диаграмме («чего нет на диаграмме — того нет в проекте»); вписать новый результат кодом вместо расширения графа; программировать таблицу вручную вместо объявления колонок; копировать Subject между таблицами вместо смены статуса; изобретать сущность вне онтологии.

Экспериментируй без устали. Если работаешь «как принято» — твой потолок известен заранее. Пробуй иначе — не как все.