Inside Org Runtime v2: How Monomind Coordinates Real Agent Sessions

1. OrgBus and PolicyEngine: The Real Isolation Boundary

An append-only event log for coordination, and a per-role policy engine for governance

Every org runs on top of OrgBus, an append-only JSONL event log with in-process fanout. It's the backbone for everything that happens inside an org: messages between roles, dashboard sync over SSE, and the durable history a run leaves behind. Conceptually it behaves like an event-sourced log rather than a database - every event that happens during a run is appended, never mutated, and anything subscribed to the bus (the dashboard, other roles, the daemon itself) gets it as it happens.

Messages between roles are delivered through a per-role Mailbox, an async queue that each role's agent session reads from between turns. This is how a coordinator role hands off work to a worker role, or how a worker reports back - org_send on one end, a mailbox delivery on the other.

Governance doesn't come from sandboxed containers or schema-validated node transitions - it comes from a PolicyEngine instantiated per role. Each role's PolicyEngine enforces tool allow/deny lists, file scope restrictions, web access control, and a per-role token budget cap. Every decision the PolicyEngine makes - what it allowed, what it denied, and why - is written to an audit trail, so after a run you can see exactly which tool calls a role attempted and which ones the policy blocked.

{
  "name": "example",
  "roles": [
    {
      "name": "coordinator",
      "runner": "claude",
      "policy": {
        "allowedTools": ["org_send", "org_task", "ask_human"],
        "deniedTools": ["bash"],
        "fileScope": ["./docs/**"],
        "webAccess": false,
        "tokenBudget": 200000
      }
    },
    {
      "name": "worker",
      "runner": "claude",
      "policy": {
        "allowedTools": ["org_send", "org_task_done", "ask_human"],
        "fileScope": ["./src/**"],
        "webAccess": false,
        "tokenBudget": 500000
      }
    }
  ]
}

2. Human-in-the-Loop: Approvals, Gates, and Questions

Concrete CLI mechanisms for pausing a role until a human decides

Human oversight in the org runtime isn't a conceptual 'audit queue' - it's a set of specific, CLI-visible mechanisms that actually block execution. When a role needs a decision it can't make on its own, it has a real tool for that: ask_human. Calling it appends a question to the org's pending-questions state and fires a question event on the bus, which the dashboard picks up immediately over SSE.

From there, a human runs monomind org questions <name> to see what's pending and monomind org answer <name> <question-id> "<text>" to deliver an answer back into the role's session - the role genuinely waits for that reply before continuing.

For irreversible or high-stakes actions, roles use decision gates instead: org_gate creates a hard-blocking checkpoint, and a human resolves it with monomind org gates to list pending gates and monomind org gate-approve or monomind org gate-reject to decide. There's a separate, more general approval flow too - monomind org approve and monomind org deny act on pending approvals raised during a run. All three mechanisms (questions, gates, approvals) pause real execution; none of them are simulated.

“A gate that doesn't block execution isn't a gate - it's a suggestion. org_gate stops the role's session until a human runs org gate-approve or org gate-reject.”

- Monomind Core Team

3. Cross-Run Memory and Network Defaults

Learning from past runs, and a runtime that doesn't listen on every interface by default

An org's improvement over time doesn't come from a benchmark score - it comes from org_complete and org_recall. When a boss role calls org_complete, the outcome of that run is recorded; the next time the same org runs, its roles are briefed on what happened last time. org_recall lets any role query that cross-run history directly, so an org can avoid repeating a mistake or reuse a decision it already made in a previous run. That's the project's real self-improvement loop.

On the operational side, since 2.9.0 both the dashboard and the org server bind to 127.0.0.1 only, not all network interfaces - a role's session, the event bus, and the approval UI aren't exposed to the network by default. It's a small detail, but it's the kind of default that matters if you're running orgs on a shared machine.

It's worth separating this from Monomind's swarm/hive-mind layer, which is a related but distinct coordination mode used for things like code review swarms. The project labels it experimental: it runs in-process only with no cross-machine networking, and 'consensus' there means a vote-count threshold, not real distributed consensus - no leader election, no log replication. Org runtime's PolicyEngine and OrgBus are the production mechanism; swarm consensus is a separate, explicitly experimental one.