Индустрия автономных мультиагентных систем (MAS) сейчас на подъеме. В начале 2026 года фреймворк OpenClaw получил сотни тысяч звезд на GitHub и задал стандарт: локальный Gateway, фоновый процесс, легко подключаемая система скиллов и интеграция с мессенджерами - «LLM с руками», классический ReAct-цикл (Reason + Act), умный ассистент.

Но попытка приспособить OpenClaw и его аналоги под сложные инженерные задачи с большим контекстом и высокой ценой ошибки упирается в архитектурные ограничения. IMHO, можно выделить четыре проблемы, из-за которых современные MAS сыплются при масштабировании:

1. Классический ReAct работает линейно - модель генерирует вызов инструмента, получает ответ, делает следующий шаг. Агент пытается решить задачу сходу. Сталкиваясь с высокой неопределенностью, система начинает галлюцинировать или уходит в бесконечный цикл одних и тех же ошибок. Она не умеет останавливаться, фиксировать пробел в знаниях и уходить в точечный ресерч, т.е. рефлекс вместо познания.

2. Обычно агенты делегируют задачи, перекидывая друг другу сырые абзацы текста. На третьем-четвертом шаге цель искажается, ограничения забываются, а контекстное окно забивается мусором из промежуточных логов. Возникает архитектурный дрейф, хаос нетипизированных промптов.

3. Если свалить все факты, историю диалогов, накопленную информацию и куски кода в один локальный файл или единую векторную базу, поиск быстро начинает выдавать шум. Нет жесткого разделения на рабочий кэш, подтвержденные факты и поведенческие привычки.

4. Давать LLM бесконтрольный доступ к локальной файловой системе и терминалу – огромный риск. Запреты в системном промпте легко обойти. Агент в процессе экспериментов может случайно затереть файлы или слить данные. Примеров - множество.

   Сразу отвечу на гневные комментарии - "Это все решается так-то и так-то!!!!!" - да, и это еще раз подтверждает, что проблема в фундаменте есть и ищутся пути ее решения. Так вот - это один из вариантов.

Стало ясно, что очередная обертка из промптов поверх Python-скриптов не спасает. Нужен пересмотр идеи, нужен полноценный эпистемический движок.

Эпистемический - термин, относящийся к познанию, знаниям или самой способности (человека) познавать мир, всё, что связано с теорией познания (эпистемологией): как мы получаем знания, насколько они достоверны и где границы того, что мы можем знать.

В этой статье обзорно показано внутреннее устройство многоагентной ИИ-системы. Основная идея системы - смещение акцента с генерации контента на процесс познания и разрешения неопределенностей. Генерация контента - не цель, а лишь один из инструментов, с помощью которого система тестирует гипотезы о картине мире, хранящейся в ее памяти.

Сразу примечание: статус проекта - экспериментальный, рабочий, развивающийся.

Ролевая архитектура, оркестрация

Сначала были грабли, попытка описать все правила, навыки и ограничения в одном гигантском системном промпте. Качество сразу упало. Когда в контекст навалено всё подряд – от правил структуры контента до рекомендаций и доступных инструментов – LLM путается в ролях, забывает инструкции и выдумывает несуществующие инструменты. Гонять такой контекст туда-сюда оказалось дорого и медленно.

Поэтому за основу взята микросервисная архитектура. Функционал разбит на изолированные сущности, а граф выполнения построен на базе оркестратора. Теперь каждый агент получает только тот контекст и те инструменты, которые нужны ему прямо сейчас. Галлюцинации почти исчезли, отладка упростилась.

Ядро системы состоит из трех частей:

• Реестр ролей и инструментов - база знаний о том, кем может быть агент. Никакого хардкода: настройки вынесены в декларативные конфиги и директории с промптами (data/agents). Здесь лежат системные инструкции, разрешенные инструменты, лимиты по токенам и привязки к конкретным LLM.

• Фабрика агентов - движок сборки. Берет данные из реестра и создает экземпляр агента под конкретный шаг плана. Фабрика сама внедряет зависимости, подкидывает инструменты и настраивает базовые метрики - контроль качества и статистика.

• Менеджер состояний (граф оркестрации и память L1) - управляет жизненным циклом и памятью активных агентов. Контекст одного агента физически не может "протечь" к другому. В состоянии агента лежит не только история сообщений, но и эпистемические поля: uncertainty_score, evidence_log, missing_knowledge.

В итоге каждый узел графа работает как узкий специалист:

1. Входная группа и роутинг:

• TriageRouter – диспетчер и входная точка. Анализирует запрос и выбирает стратегию:

  • FastResponder (EXECUTE) - простой вопрос – быстрый ответ без планирования и поиска в памяти.

  • Deep Track (EXPLORE/REASON) - сложная задача. Triage запускает полноценный эпистемический цикл - запрос отдается в MemoryNode (поиск в памяти) и KnowledgeProbe (оценка знаний), а затем в Planner/Replanner.

  • Clarification Track (REFINE) - запрос абстрактный. Агент "Clarification" задаваtn пользователю уточняющие вопросы.

2. Исполнительное ядро, исполнители

• Researcher – главный исследователь. Ищет ответы в локальной памяти, обращается к SearXNG для поиска в интернете, читает сохраненные файлы. Его задача – найти белые пятна в контексте и заполнить их фактами, собирая журнал доказательств.

• Coder – инструмент для проверки гипотез. Пишет скрипты (код, конфигурационные файлы, docker), которые запускаются в изолированной песочнице. Падение скрипта воспринимается системой как ценный эпистемический сигнал.

3. Контроль качества и арбитраж

• Critic – проверяет логику. Находит противоречие в фактах или когнитивное искажение – бракует ветку рассуждений. Работает в связке с узлом Replanner, заставляя систему перестроить план.

4. Фоновые процессы

• Memory Maintainer – архивариус. Разбирает длинные логи и переписку агентов. Доказанные гипотезы сжимает и отправляет в долгосрочную память (Mem0, Qdrant).

• Terminal и Technical Writer – конечный узел графа перед отправкой сообщения пользователю. Собирает из evidence_log итоговый ответ пользователю.

Эпистемический цикл, движок познания

Это то, ради чего затевался весь эксперимент, главное отличие от ИИ-помощников. Обычно агенты работают в схеме «запрос-ответ» - пользователь дает задачу, агент генерирует решение. Здесь реализован принцип - «неопределенность-исследование».

Агенты не пытаются решить задачу с наскока. Вместо этого они запускают непрерывный эпистемический цикл (цикл познания), который заставляет мыслить системно и проверять каждый шаг. Этот цикл состоит из пяти этапов:

1. Активация «Любопытства» - получив задачу, система первым делом оценивает собственные знания. Агенты задают себе вопрос: «Что мы уже точно знаем об этой проблеме, а в чем сомневаемся?». Формируется карта известных фактов и карта неизвестного.

2. Симуляция мира - прежде чем выполнить физическое действие – выполнить поиск во внешних источниках, запустить инструмент или запустить парсер – система прогоняет симуляцию. Агент пошагово предсказывает развитие ситуации: «Если я прочитаю этот файл, там должна быть такая-то структура».

3. Эпистемический пробел в знаниях - как только симуляция сталкивается с нехваткой реальных данных или логическим противоречием, процесс останавливается. Система классифицирует проблему как «эпистемический пробел». Этот конкретный пробел становится новой микроцелью для агентов.

4. Тестирование гипотез - только теперь система переходит к действиям. Инициируется сбор фактов. При необходимости - написание кода, генерация скила на этом этапе происходит исключительно как создание инструмента для устранения пробела. Новый инструмент выступает в роли зонда, который система забрасывает в реальный мир, чтобы получить метрики и закрыть пробел.

5. Обновление картины мира - инструмент запускается в изолированной песочнице. Результат его работы (текстовый контент, успешный JSON, пустой массив или лог с ошибкой) возвращается в ядро. Система анализирует ответ реальности и обновляет свою модель мира. Данные получены и если пробел закрыт, планирование продолжается. Инструмент "упал" – изначальная гипотеза была неверной, система делает выводы и формирует новую теорию.

Такой подход исключает галлюцинации в подавляющем большинстве случаев. Система не может выдать пользователю выдуманный ответ - каждый шаг ее рассуждений обязан пройти тест реальностью (внутренней модели мира) внутри эпистемического цикла.

В проекте этот цикл задан как 8-фазный:

1. P01.DATA_INGESTION – первичный захват нового сигнала: пользовательский запрос, пакет данных из интернета или системный триггер.

2. P02.VECTOR_MATCHING – сверка с векторной и фактологической памятью: «известно ли мне это?».

3. P03.CONFLICT_RESOLUTION_WEB – сетевая(интернет) триангуляция, если в памяти найден конфликт или данных недостаточно.

4. P04.BIO_SENSOR_PING – обращение к человеку как к инструменту верификации, если интернет не закрыл пробел.

5. P05.SEMANTIC_INTEGRATION – встраивание подтвержденных фактов в граф знаний и долгосрочную память.

6. P06.EPISTEMIC_GAP_ANALYSIS – детекция новых слепых зон, порожденных только что обновленной картиной мира.

7. P07.MEMORY_COMPRESSION – сжатие сессионного контекста, архивирование логов и очистка рабочего кэша.

8. P08.AUTONOMOUS_TRIGGER – генерация следующего внутреннего исследовательского запроса и возврат к P01.

Это разница между «агентом с набором инструментов» и эпистемическим движком. В этом случае работает замкнутый операционный цикл. Каждая его фаза обязана передать системе более согласованную модель мира, чем была до нее.

Эпистемическое самосознание и самообучение

По ходу разработки стало ясно, то автономным агентам мало познавать внешний мир. Им нужно «осознавать» самих себя. Поэтому в систему внедрен механизм эпистемического самосознания – способность агентов анализировать собственные мыслительные процессы и ограничения.

Работает это через специальные внутренние метрики (например, inspectstate и selfimprove_probe):

• Интроспекция - в любой момент агент может сделать слепок текущего состояния. Он анализирует этап графа, потраченные токены и риск зайти в тупик. Если агент понимает, что ходит по кругу (например, трижды получил одну и ту же ошибку в своем результате), он прерывает цикл и просит помощи у подсистемы разрешения конфликтов.

• Самосовершенствование - после завершения сессии фоновые процессы анализируют логи успешных и провальных действий. Если агент систематически ошибался при формировании своих ответов (или своих действий), система динамически переписывает внутренние системные промпты (эвристики) для этого агента на будущие запуски. Агенты извлекают уроки из своих ошибок.

• Калибровка уверенности- агенты маркируют свои утверждения флагами уверенности. Если система выдает факт, она сопровождает его метаданными: «Уверен на 95%, проверено через <такой-то> инструмент». Факт из поисковой выдачи получает сниженный рейтинг: «70%, требует экспериментальной проверки».

Изолированные рабочие пространства

Для тестирования гипотез и взаимодействия с реальным миром написан менеджер рабочих пространств. Каждая задача разворачивается в выделенной изолированной среде – например, в папке data/workspace/<workspace_id>.

В архитектуре песочница – это не просто место для хранения изолированного хранения контента, относящегося к текущему исследованию, и безопасного запуска кода. Это контролируемая лабораторная среда. Логический контейнер объединяет файлы, память и права доступа агентов вокруг конкретного проекта. Дать LLM неограниченный доступ к хосту – значит согласиться на удаление файлов или утечку данных. Песочница решает проблему через изоляцию:

• Запуск скриптов - например, Coder пишет Python-скрипты, они запускаются внутри песочницы. Если скрипт падает, песочница перехватывает stderr и возвращает трассировку ошибки агенту. Тот читает ошибку и делает следующую итерацию кода. Аналогично для создания сред выполнения и различных пространств, требующих своей конфигурации.

• Изоляция файловой системы - сервер MCP filesystem запирает агентов в назначенной директории. Агент физически не может выйти за пределы workspace_id и повредить файлы соседнего проекта. Если запрос не привязан к конкретному проекту, используется глобальная песочница default или система просит пользователя выбрать нужную.

• Навыки - песочница поставляется с набором предустановленных безопасных навыков (директория data/skills/, например skills/text_stats). Агент любо их непосредственно использует или импортирует их в скрипты как обычные библиотеки. Каждый навык имеет манифест с описанием. Агенту больше не нужно писать велосипеды для типовых задач.

• Генерация навыков - агенты могут сами предлагать новые навыки через инструмент propose_skill. Но здесь проходит граница безопасности - агент пишет код в специальную карантинную директорию (_pending), к которой у него нет прямого доступа на запись в рабочем окружении. Код проходит статический AST-аудит (блокировка exec, subprocess, сетевых вызовов), проверку размера и криптографических подписей. Только после ручной проверки в дашборде (и в системе в целом) оператор может установить навык. Это защищает систему от инъекций и самостоятельного повышения привилегий.

Для создаваемых инструментов и навыков - хардкод, регулярные выражения (regexp) и парсеры допускаются только в виде исключения, когда задачу нельзя закрыть структурированными API. Если задача решается статичным Python-скриптом вроде подсчета символов, агент не использует токены LLM, а пишет локальный инструмент или скилл.

Песочница еще в стадии осмысления. Пока гибкость и универсальность такого подхода - в стадии формирования. Сложно разделять для агента ситуации когда можно один раз вызвать LLM для решения своей проблемы или написать инструмент или скилл. Пока формируется система метрик, которая позволит разделить эти ситуации.

Что точно появится в песочнице в будущем:

1. Docker-изоляция - сейчас пути изолируются на уровне логики. В планах – оборачивать каждую песочницу в Docker-контейнер с лимитами по CPU/RAM и отрезанной по умолчанию сетью.

2. Изоляция зависимостей (по venv/poetry) - динамическое создание виртуального окружения для каждой песочницы. Агент сможет безопасно делать pip install без риска конфликта пакетов на хосте.

3. Тайм-ауты и контроль ресурсов - принудительное прерывание процессов (например, если Агент случайно написал бесконечный цикл while True), чтобы агент не повесил всю систему.

RAG, семантическая память и хранилища

Эпистемическому циклу нужна память. Неправильно использовать единую базу данных «под всё», необходимо распределенное хранилище. Долговременную память разбита на четыре уровня (L1-L4):

• L1 (Redis) - cостояние и кэш, «короткая память» системы. Управляет машиной состояний графа, кэширует частые запросы и держит механики блокировок.

• L2 (Qdrant) - векторная база, семантический поиск. Факты о предметной области, документация, куски кода, результаты парсинга - знания о мире для семантического поиска. Сюда агент (преимущественно Researcher) складывает эмбеддинги изученных документов. Позволяет быстро находить нужный контекст (например, «Где в используется аутентификация?», "Где написано про рынок акций в 2025 году?").

• L3 (Mem0) - долгосрочная семантическая память. Параллельно из контекста, извлекаются связи «Субъект – Предикат – Объект» поверх Qdrant и Redis, превращая документы в структурированный граф. При поиске алгоритм переранжирует результаты с учетом веса этих троек. Это повышает плотность контекста, который уходит в LLM.

• L4 (подтвержденные знания / SQLite + Redis hot-store) - схема знаний вместо разрозненных БД профилей. Хранит четыре оси: self, user, interaction, world. Сюда попадают предпочтения разработчика (вроде любви к красивому оформлению результата, структуре, языку (русский, японский)), глобальные ограничения и выводы из прошлых сессий. Эти факты поддерживают политику удержания и автоматически встраиваются в промпты. Дополнительно работает пайплайн "память, производная от ответа" - факты автоматически достаются из финальных ответов, убираются повторы и записываются в базу. Записи не удаляются, что позволяет проследить эволюцию накопления знаний.

Все это использует RAG-сервис. Пайплайн обработки знаний:

1. Нормализация текста – чистим сырые данные от мусора, html-тегов и лишних пробелов.

2. Извлечение троек фактов – собираем из контекста граф связей.

3. Реранжирование – сортируем куски знаний и подаем модели только концентрат релевантной информации, отсекая шум.

Автономное планирование, Celery и каскадная отмена

Для сложных задач агенты умеют разделять работу в направленные ациклические графы (DAG). Чтобы выполнять эти графы асинхронно (ну и, наверное, надежно), используется Celery и Redis в качестве брокера сообщений:

• Независимые ветки плана отдаются в Celery-воркерам и выполняются параллельно (например, когда Researcher должен спарсить три разных сайта одновременно).

• Если воркер падает, например, при нехватке памяти на обработке большого файла, состояние в Redis не ломается. Задача перехватывается или помечается упавшей.

• Если ветка заходит в непреодолимый эпистемический тупик, движок отменяет все зависимые, еще не начатые Celery-задачи. Состояние безопасно откатывается назад. Система не тратит токены на бесполезные шаги и переносит промежуточные галлюцинации моделей.

Все это представляет отдельный фоновый контур из двух независимых задач:

• epistemic_cycle_guard – легковесный сканер (страж), периодически сканирует базу знаний и считает долю проблемных знаний (disputed, stale, hypothesis).

• epistemic_cycle_sweep – сборщик(тяжелый), запускает полный 8-фазный цикл, только если сканер видит сильную деградацию памяти.

Триггер запуска завязан не на таймер, а на качество базы - количество сомнительных фактов и непроверенных гипотез. Система тратит ресурсы не раз в час по таймеру, а лишь когда накапливается эпистемический долг.

Отдельно внедрена защита от бесконечных циклов. Если один и тот же факт стабильно ломает результат, он получает счетчик retry_count, а затем уходит в карантин (is_quarantined). Страж перестает на него реагировать. Вернуть факт в использование может только оператор ручным вмешательством в дашборде. Одинаковые уведомления отсеиваются через Redis – система не спамит человека одной и той же проблемой.

Поверх всего этого висит блокировка Redis-lock на весь цикл. Два процесса-сборщика не смогут одновременно переписать одно состояние. В итоге получается автономность без бардака - есть триггеры, предохранители и операционный журнал.

Межагентная делегация

Проблема многих MAS заключается в том, что один агент отдает другому сырой текст. Начинается неконтролируемое каскадное связывание промптов. Контекст искажается, токены утекают.

Здесь используется механизм Prompt-to-Prompt (P2P) со строгой типизацией. Агент A передает агенту B структурированный пакет данных – PromptEnvelope. Внутри зашиты конкретные поля: intent (намерение), objective (цель), input_context (входные данные), constraints (ограничения), output_contract (ожидаемый формат ответа), safety (настройки безопасности) и metadata (трассировка). Межагентная коммуникация должна быть формализованной. Иначе система быстро скатывается в дорогой обмен псевдоумными абзацами. P2P превращает передачу управления в протокол с проверкой, аудитом и рамками безопасности.

Это дало несколько преимуществ:

• Появился протокол(контракт) взаимодействия между агентами.

• Схему и размер пакета можно проверять до запуска целевого агента.

• Появилась трассировка переходов A -> B -> C.

• Передаваемый пакет не может расширить права агента, он только может сузить доступный набор инструментов.

• Стало легко вводить лимиты на глубину делегирования, количество пакетов за ход и токен-бюджет.

Коротко - дашбоард

Когда Researcher ищет данные, Coder гоняет тесты, а Critic бракует результаты, логи сливаются в кашу. Поэтому - веб-дашборд на стеке React + TypeScript + Vite. Дашборд - пульт управления эпистемическим движком. Бэкенд на FastAPI, WebSocket/SSE для потоковой передачи состояний в реальном времени. Что реализовано:

• Визуализация графа и статусов фоновых задач на лету.

• Инспектор памяти – можно смотреть L1/L2/L3 агентов прямо во время работы.

• Контроль токенов, показывающий затраты в реальном времени.

• Управление - пауза, возобновление, управление навыками и подтверждение рискованных действий.

• Библиотека сохраненных планов и история сессий.

Telegram пока не реализован, оставлен как адаптер для коротких команд, мобильных алертов и быстрых подтверждений. Сейчас единая система идентификации (UserIdentity и IdentityResolver), готовые эндпоинты - сводят разные каналы к внутреннему ID, предотвращая деление памяти между вебом и мессенджером.

Экономия токенов и контроль расходов

Агенты любят тратить токены. Оставленная на ночь система при EPISTEMIC_CYCLE_ENABLED = True обнулила баланс API за несколько часов. Надо экономить:

• Фоновый процесс регулярно анализирует историю диалогов. Вместо хранения полного контента (что увеличивает цену каждого шага), агент сжимает пройденные этапы в короткие факты.

• Введены лимиты на контекст. Если агент пытается переработать огромный файл или выдачу поисковика, срабатывают предохранители: умное реранжирование усекает данные, оставляя только самую суть.

• Система выжимает максимум из бесплатных уровней (Gemini 1.5 Pro, Groq) и локальных LLM через Ollama. Платные API с жесткой тарификацией включаются точечно при низкой уверенности (uncertainty_score), ошибках валидации или критичных операциях с памятью.

• YAML-конфигурации позволяют переключать провайдеров под разные задачи. Вся статистика агрегируется, в дашборде видна цена каждой операции.

• Для простых задач система параллельно запускает «быстрого» агента на дешевой модели и «полного». Арбитр сравнивает ответы. Если полный путь не дал серьезного прироста качества (по метрикам), побеждает быстрый вариант. Экономим токены и снижаем задержку.

• Если дневной бюджет исчерпан (TOKEN_BUDGET_USD_PER_USER), система не падает. Она переходит в режим BACKGROUND_SUSPEND - тяжелые Celery-задачи встают на паузу, а Triage переключается на дешевые модели до сброса счетчика.

Мониторинг и собираемые метрики

Поскольку агенты автономны, нужно понимать логику их решений и находить узкие места. Система собирает телеметрию из нескольких метрик:

• Метрики эпистемического цикла - время на сбор данных и время генерации результата, количество итераций на закрытие слепых зон.

• Метрики графа - глубина задач, частота срабатывания каскадной отмены, доля успешных разрешений конфликтов.

• Ресурсы песочницы - потребление CPU/RAM в изолированных средах, время отклика, количество синтаксических ошибок в сгенерированном коде.

• Метрики RAG и поиска - точность переранжирования, процент попадений в кэше Redis, объем сохраненных троек фактов, задержки Qdrant.

• Финансы - подсчет промпт/результат токенов с привязкой к агенту, сессии и провайдеру.

• Качество ответов - тестовые бенчмарки контроля качества памяти.

Для сбора, визуализации и, главное, контроля используется традиционная связка Prometheus + Grafana с алертами при перерасходе.

Но главное(!) – эти метрики напрямую влияют на поведение системы - механизм саморефлексии.

Если время отклика или цена токенов превышает порог, фоновый Triage динамически переключает запросы на дешевую LLM (сознательно снижает качество ради экономии). Если часто срабатывает каскадная отмена, система понимает - стратегия планирования не работает. Researcher автоматически повышает температуру поиска.

Также реализован ночной оценочный контур. Каждую ночь система прогоняет накопленный "золотой" датасет (успешные логи и краевые сценарии) через RAG-пайплайн. Используется мощная модель в роли судьи, которая считает сложные когнитивные метрики:

• Agent Calibration Error (ACE) – совпадает ли уверенность агента с реальностью.

• World Understanding Score (WUS) – насколько полно собраны и осознаны факты.

• Uncertainty Delta – как изменилась неопределенность от начала к концу цикла.

Если показатель WUS падает слишком низко, срабатывает Любопытство. Система формирует запрос на фоновое исследование, чтобы закрыть слепые зоны до того, как о них спросит пользователь.

Что дальше?

Если смотреть глобально, ReAct-подход напоминает поведение джуна. Получив задачу, агент сразу бросается генерировать контент. Если попытка провалилась пробует еще раз – трата токенов и контекст ошибками. Эпистемический движок разделяет действие и познание.

Эта экспериментальная архитектура предлагает три изменения во взгляде на MAS:

1. MAS больше не черный ящик с магическими промптами. Оркестратор, асинхронные воркеры, P2P-контракты и каскадная отмена сделали среду предсказуемой. Система умеет останавливаться и откатывать состояние при попадании в тупик.

2. Модель больше не угадывает ответ, а фиксирует свои слепые зоны. Код работает как зонд для проверки гипотезы о мире. Если песочница не подтверждает ожидания, план перестраивается. Ложный факт просто не попадает в ядро знаний.

3. Агент перестает работать только с контекстным окном. L1-L4 слои семантической памяти и извлечение троек фактов помогают формировать долгосрочную картину мира. Система учится на ошибках, рефлексирует по ночам и закрывает дыры в знаниях фоновым Любопытством.

IMHO, будущее ИИ-агентов лежит не в раздувании контекстного окна или добавлении сотен новых инструментов. Оно – за строгими проверяемыми системами познания. Запуская агентов в рамках типизированных интерфейсов и песочниц, мы даем им настоящую автономность.

Сейчас эпистемический движок – это внутренний эксперимент по исследованию и разработке. Это не очередной Claw, это попытка использовать модель предметной области (мира), фазовый цикл познания, P2P-взаимодествие и предсказуемость среды выполнения.

Проект еще содержит недостатки. Иногда абстракции "протекают", спекулятивное выполнение требует доработки, а ночная саморефлексия - слишком любопытна. Плюс есть нерешенные вопросы с лимитами и безопасностью. Но уже начат процесс отвязки ядра движка от специфичной бизнес-логики. Ближайшие планы - вывести автономный эпистемический цикл в отдельный промышленный контур, реализовать связь каждого факта со своим первоисточником, придумать метрики надежности источника.

Кстати проект стал источником многих внутренних мемов. Например, какое-то время система была убеждена, что работает над секретным проектом "Project 4590" в составе коллектива экспертов. Откуда она это взяла, что это за проект, кто входит в состав этого коллектива - выяснить не удалось.
Или пчелы.... Из-за забытого в рабочем пространстве текстового файлика с вопросом "Кто такие пчелы?". Система после каждой очистки памяти проводила в фоне тщательное исследование по этому вопросу...

Ну вот как-то так...

А как у Вас? Сталкивались ли вы с конфликтующими агентами в своих проектах? Пытались уйти от классического ReAct-цикла? Как решаете задачу изоляции среды исполнения?