Модуль IV — межагентная коммуникация и оркестрация

Модуль IV — это плоскость наблюдения и управления тем, как координируются агенты. Он не переизобретает фреймворк агентов (никаких LangGraph/CrewAI/AutoGen), не запускает агента и никогда не порождает процесс. Он выводит живой граф коммуникации и делегирования из сигналов, уже присутствующих на шине, управляет запланированными/автономными агентами как декларациями желаемого состояния и помечает уклонение от каденции — при этом сам акт запуска агента уходит только через seam с политикой deny-closed.

Что это такое

Бок о бок стоят две вещи. Во-первых, производный граф коммуникации и делегирования — кто кому делегирует (supervisor→worker) и кто с кем общается — построенный как представление поверх уже наблюдённых рёбер доступа, родственник карты доступа (модуль III), но никогда не повторно поглощённая вторая копия. Во-вторых, реестр управляемых расписаний: запланированный или событийно-управляемый агент — это декларация желаемого состояния, и запуск одного из них — единственное действие модуля, влияющее на продакшн.

Контракт и сущности

Модуль владеет тремя видами сущностей, объявленными в общей модели данных:

orchestration.relation (upsert) — производное ребро графа: связь типа delegation, mcp_server или mcp_tool между двумя ссылками, с источником сигнала, режимом mode (чтение/запись), confidence, счётчиками и метками первого/последнего наблюдения.
orchestration.schedule (жизненный цикл) — управляемая декларация: субъект, вид триггера (cron/event/manual), непрозрачная спецификация каденции, которая никогда не разбирается для самозапуска, ожидаемый интервал, фактор допуска (grace factor), желаемый статус и объявляющий принципал, записанный как владелец любого автономного запуска.
orchestration.decision (только добавление) — неизменяемый журнал каждого запроса на запуск, запуска и пропуска каденции, несущий plan_hash, статус gate, op_status и реальный принципал (никогда не system, кроме детектирования пропуска каденции).

Маршруты модуля доступны, но намеренно не входят в публикуемый контракт OpenAPI; их формы на уровне полей живут в типизированных интерфейсах продукта. Запуск двухфазный и с HITL-гейтом: фаза один запрашивает одобрение; фаза два повторно проверяет одобрение и строгое совпадение plan_hash (анти-TOCTOU — смена цели или каденции аннулирует устаревшее одобрение) до любого dispatch. Чтение графа и запуск — привилегированные, ограниченные тенантом, полностью аудируемые действия, разделённые по уровням глагола (чтение для наблюдателей, объявление/перенацеливание для редакторов, запуск только для админов) — см. управление и одобрение.

Что он потребляет и производит на шине

Он потребляет ровно один канал: edge.observed. Ребро session→Task становится отношением делегирования; рёбра MCP-топологии становятся отношениями сервер/инструмент; всё остальное игнорируется. Наблюдённая активность субъекта для проверки каденции выводится из самих отношений, поэтому ни одно расписание не запрашивается для каждого ребра. Он производит находки на finding.reported: orchestration_cadence_miss, когда активное, повторяющееся расписание перестаёт испускать события относительно своей объявленной каденции (одноразовое или приостановленное расписание, которое просто завершилось, — это нормальная тишина, оно ничего не испускает), и orchestration_ungoverned_fire, когда попытка запуска не находит подключённого gate одобрения — пробел в управлении делается видимым, при этом запуск остаётся запрещённым. Проверка выполняется в момент чтения и ограничена закреплённым тенантом запроса; модуль никогда не выполняет межтенантного фонового сканирования.

Живой запуск — это seam с политикой deny-closed. Модуль управляет и планирует; он никогда не актуирует сам. Запуск уходит через seam Dispatcher. При несконфигурированном dispatcher (бинарник по умолчанию) одобренный запуск возвращает честный 200 со статусом declared_not_fired — безопасное состояние «объявлено, не запущено». Dispatcher, собранный и сконфигурированный оператором, направляет одобренный, совпавший по плану запуск на тот же исполнитель развёртывания (deployment executor) или на A2A-задачу, верифицированную по подписанной карточке; ошибка dispatcher возвращает 502 и никогда не сдвигает время последнего запуска. Живое A2A-делегирование добавляет собственную точку применения политик с политикой deny-by-default (подписанная карточка → allowlist → хеш плана → одобрение) и ограничивается тем же образом.
Покрытие графа частично, и об этом сказано. Каждый ответ графа несёт дескриптор покрытия. Производный граф покрывает делегирование Task, MCP-топологию и — где подключён A2A-коннектор — наблюдённый одноранговый (peer-to-peer) A2A; перекрёстное взаимодействие роёв (swarm cross-talk) и не-Task-фреймворки без испускающего коннектора отсутствуют, а не равны нулю. Модуль никогда не представляет граф как полные коммуникации агентов.
Минимум данных при передаче. Модуль сохраняет только отношения и свидетельства управления — кто↔кто, счётчики, тайминг, маскированные ссылки — никогда полезные нагрузки сообщений, промпты, аргументы инструментов или секреты. Такого столбца не существует; чувствительные ссылки хешируются до сохранения. Это свойство протокола передачи, а не настройка.

Связанное

Каталог модулей — слой модуля IV и честный статус актуации.
Справочник по шине событий — edge.observed на вход, finding.reported на выход.
Карта доступа и ресурсов — родственный граф, который этот модуль выводит параллельно.
Управление и одобрение — двухфазный запуск с участием человека (human-in-the-loop).
Честность и ограничения — что актуируется сегодня, а что пока остаётся seam.
Обзор архитектуры — где модуль IV находится в слое Intelligence.