Monomind v2.2: Org Runtime v2 - Real Agent Sessions, Not Scripted Prompts

1. OrgDaemon: One Process, Many Orgs, Real Sessions

Every role is a live agent session, not a scripted turn in a shared prompt

At the center of Org Runtime v2 is OrgDaemon, a process that can host multiple orgs concurrently. Each org is defined by a config file at .monomind/orgs/<name>.json, and each role within that config gets its own agent session - a real, provider-backed session, not a simulated or scripted stand-in inside a shared conversation.

The execution path for a role is straightforward: runAgentSession() sets up the session, hands off to runOneSession() to run a single turn, which in turn calls into the underlying runner's run() method to actually talk to the provider. Because each role's session is a distinct object with its own state, one role's context window, tool calls, and conversation history never bleed into another's.

This matters because it's what makes the rest of the system - the event bus, the mailbox, the policy engine - possible in the first place. You can't govern or audit a role's behavior if that role doesn't have a clean, separately addressable execution context.

{
  "name": "sample-team",
  "roles": [
    {
      "name": "lead",
      "provider": "claude-code",
      "policy": {
        "tools": { "allow": ["Read", "Edit", "Bash"] }
      }
    },
    {
      "name": "reviewer",
      "provider": "claude-code",
      "policy": {
        "tools": { "allow": ["Read"] }
      }
    }
  ]
}

2. OrgBus and Mailbox: How Roles Actually Communicate

An append-only event log replaces the old dashboard curl posts

In the v1 flow, keeping a dashboard in sync meant the boss agent manually curl-posting status updates as it went. Org Runtime v2 removes that entirely. Every meaningful event in an org's lifecycle - a role starting, a message being sent, a tool call happening - is written to OrgBus, an append-only JSONL event log with in-process fanout.

Because OrgBus is append-only, both the dashboard and any historical view of the org are reading from the same source of truth: nothing is summarized or re-derived after the fact. Messages between roles are delivered through a per-role Mailbox, so a role only ever sees the messages actually addressed to it, rather than the full firehose of the org's activity.

The dashboard itself runs on port 4242 and is auto-launched by a Claude Code SessionStart hook - there's no separate CLI command to start it. It discovers running daemons through .monomind/control.json, which is how it finds the right OrgBus stream to tail.

{"ts":"2026-07-17T14:02:31Z","org":"sample-team","role":"lead","type":"message.sent","to":"reviewer"}
{"ts":"2026-07-17T14:02:33Z","org":"sample-team","role":"reviewer","type":"session.started"}

3. PolicyEngine: In-Process Governance, and Migrating from v1

Tool limits, file scope, web access, and token budgets - enforced per role, with an audit trail

Each role session in Org Runtime v2 runs behind its own PolicyEngine. This is real, in-process enforcement, not documentation of intended behavior: tool allow/deny lists, file scope restrictions, web access control, and token budget caps are all checked before a role's session is permitted to act, and every decision is written to an audit trail.

This is a direct consequence of the OrgDaemon architecture - because each role is a distinct session rather than a turn inside one shared prompt, the policy engine has a clean boundary to attach to. A role restricted to Read-only tools genuinely cannot invoke Edit or Bash; there's no shared context for it to reach around the restriction through.

The old v1 flow - the Task-tool boss agent driving everything through prompts and manual dashboard posts - is now legacy. It's still reachable via /mastermind:runorgv1 for org configs that haven't been migrated yet, and the org migrate command converts v1 configs into the v2 shape shown earlier in this post.

“Governance has to live inside the session boundary, not around it - otherwise it's just a label on a config file.”

- Monomind Core Team