Skip to content
Olivares AI docs

Module IV — inter-agent communication & orchestration

Module IV is the observe-and-govern plane for how agents coordinate. It does not reimplement an agent framework (no LangGraph/CrewAI/AutoGen), it does not run an agent, and it never spawns a process. It derives a live communication & delegation graph from signals already on the bus, governs scheduled/autonomous agents as desired-state declarations, and flags cadence-evasion — while the act of running an agent leaves only through a deny-closed seam.

What it is

Section titled “What it is”

Two things sit side by side. First, a derived communication & delegation graph — who delegates to whom (supervisor→worker) and who talks to whom — built as a view over already-observed access edges, a sibling of the access map (module III), never a re-ingested second copy. Second, a register of governed schedules: a scheduled or event-driven agent is a desired-state declaration, and firing one is the single production-affecting action the module exposes.

Contract & entities

Section titled “Contract & entities”

The module owns three entity kinds, declared in the shared data model:

  • orchestration.relation (upsert) — the derived graph edge: a delegation, mcp_server or mcp_tool link between two references, with a signal source, a read/write mode, a confidence, counts and first/last-seen timing.
  • orchestration.schedule (lifecycle) — a governed declaration: subject, trigger kind (cron/event/manual), an opaque cadence spec that is never parsed to self-fire, an expected interval, a grace factor, a desired status, and the declaring principal recorded as the owner of any autonomous fire.
  • orchestration.decision (append-only) — an immutable ledger of every fire request, fire and cadence-miss, carrying the plan_hash, gate status, op_status and the real principal (never system, except for the cadence-miss detection).

The module routes are reachable but deliberately not part of the served OpenAPI contract; their field-level shapes live in the product’s typed interfaces. Firing is two-phase and HITL-gated: phase one requests approval; phase two re-verifies the approval and a strict plan_hash match (anti-TOCTOU — a re-target or re-cadence invalidates a stale approval) before any dispatch. Reading the graph and firing are privileged, tenant-scoped, fully-audited actions, split by verb tier (read for viewers, declare/retarget for editors, fire for admins only) — see govern and approve.

What it consumes & produces on the bus

Section titled “What it consumes & produces on the bus”

It consumes exactly one channel: edge.observed. A session→Task edge becomes a delegation relation; MCP-topology edges become server/tool relations; everything else is ignored. A subject’s observed liveness for the cadence check is derived from the relations themselves, so no schedule is queried per edge. It produces findings on finding.reported: orchestration_cadence_miss when an active, recurring schedule stops emitting versus its declared cadence (a one-shot or paused schedule that simply finished is normal silence and emits nothing), and orchestration_ungoverned_fire when a fire attempt finds no approval gate wired — the governance gap is made visible while the fire stays denied. The check is read-time and scoped to the request’s pinned tenant; the module never runs a cross-tenant background scan.

Section titled “Related”