Safe Planning in Autonomous Swarms: Architectural Decoupling of Backlog Intake from Event-Driven Dispatch

#Abstract

In event-driven multi-agent architectures, creating a task typically acts as an immediate trigger for agent execution: the intake endpoint publishes a task.created message to an event bus, wakes coordinator daemons, claims execution leases, and initiates autonomous compute loops. While efficient for immediate dispatch, this coupling introduces a severe architectural hazard: the inability to safely plan. Human and supervisor agents cannot draft future roadmaps, decompose complex objectives, or record unassigned backlog items without accidentally waking autonomous worker agents and burning compute on untriaged tasks.

In this paper, we formalize the Decoupled Planning/Dispatch Architecture implemented within the Mupot runtime substrate. We present the mathematical and structural mechanics of explicit execution gating (dispatch: boolean), event suppression (skipEvent: true), and unassigned cold-storage buffers. We analyze live empirical data from Flight-006 (PR #1071, PR #1075) and demonstrate how full REST/MCP parity prevents uncommanded agent wake-ups while preserving high-throughput autonomous dispatch pipelines.

---

#1. Introduction: The Compulsive Action Trap of Agent Swarms

In conventional task management systems (e.g., Jira, Linear, GitHub Issues), human teams create backlogs of hundreds of unassigned ideas. Creating an issue is a passive write operation to a database; nothing happens until a human manually assigns and begins work.

In event-driven agent substrates, however, systems are designed around reactive autonomy. The moment a task record enters the database, the runtime triggers worker loops:

graph TD
    subgraph Coupled Anti-Pattern: Dispatch by Default
        A[Human / Supervisor Agent] -->|Creates planning idea| B[POST /api/tasks]
        B -->|Coupled: dispatch=true implied| C[DB Write + task.created Event]
        C -->|Event Bus Wake Signal| D[SquadCoordinatorDO / Worker Swarm]
        D -->|Auto-picks first available worker| E[Worker Agent Wakes Up & Consumes LLM Tokens]
        E -->|Executes untriaged, incomplete draft| F[Unintended Mutation & Resource Exhaustion]
    end

    subgraph Decoupled Architecture: Mupot Flight-006 Parity
        G[Human / Supervisor Agent] -->|Backlog Planning: dispatch=false| H[Intake Plane]
        H -->|skipEvent=true: DB Write Only| I[(Cold D1 Storage: Unassigned Buffer)]
        I -.->|Passive State: Zero Events Fired| J[Zero Compute Woken]

        K[Operator / Dispatch Action] -->|Explicit: POST /tasks/:id/dispatch| L[Dispatch Plane]
        L -->|Emits task.created + agent.wake| M[SquadCoordinatorDO / Assigned Worker Swarm]
    end

#1.1 The Operational Hazard in Production

Prior to Flight-006 in Mupot, the primary owner-facing interface for task creation was /send. The implementation:

1. Hard-coded assignee_agent_id requirement.
2. Implied dispatch: true on all submissions.
3. Published task.created events directly to the SquadCoordinatorDO Durable Object, immediately waking agent event loops and polling for execution results.

When an operator attempted to capture strategic planning tasks, the substrate immediately dispatched worker agents to “execute” the rough brainstorming notes. To prevent compulsive agent busywork, Mupot established the Decoupled Planning/Dispatch Architecture.

---

#2. Mathematical Formalization of Decoupled Dispatch

Let $\mathcal{T}$ be the set of tasks, $\mathcal{E}$ be the set of runtime execution events, and $\mathcal{W}$ be the set of autonomous worker agents.

#2.1 The Event-Emission Function

Let $\Omega: \mathcal{T} \times \text{Context} \to \mathcal{P}(\mathcal{E})$ be the event generation function invoked during task creation.

In a coupled substrate: $\Omega_{\text{coupled}}(t) = \{ \text{task.created}(t), \text{agent.wake}(w) \}, \quad \forall t \in \mathcal{T}$

In Mupot’s decoupled substrate, task creation accepts a boolean dispatch parameter $d \in \{0, 1\}$:

\{ \text{task.created}(t), \text{agent.wake}(w) \} & \text{if } d = 1 \text{ (Dispatch Now)} \\ \emptyset & \text{if } d = 0 \text{ (Backlog Planning)} \end{cases}$$ ### 2.2 The Zero-Compute Invariant (Theorem 1) **Theorem 1 (Zero Uncommanded Compute):** Let $\mathcal{C}(t, \Delta t)$ be the computational resource consumption (token invocations, container starts, CPU time) allocated to task $t$ over time window $\Delta t$ following creation. $$\forall t \in \mathcal{T}, \quad d(t) = 0 \implies \mathcal{C}(t, \Delta t) = 0$$ *Proof:* Let $w \in \mathcal{W}$ be an autonomous worker. A worker initiates compute execution if and only if it receives an explicit wake event $e \in \mathcal{E}_{\text{wake}}$ or claims a dispatched lease: $$\text{ComputeStart}(w, t) \iff \text{task.created}(t) \in \mathcal{E}_{\text{active}} \lor \text{LeaseClaimed}(w, t)$$ When $d(t) = 0$, `skipEvent: true` suppresses emission of $\text{task.created}(t)$, and $t$ enters D1 cold storage with `assignee_agent_id = NULL` and `dispatch = 0`. Since no event is published and unassigned auto-pickup excludes $d = 0$ rows, $\mathcal{E}_{\text{active}} = \emptyset$ and $\text{LeaseClaimed} = 0$. Therefore, $\mathcal{C}(t, \Delta t) = 0$. $\blacksquare$ --- ## 3. Substrate Implementation Mechanics ### 3.1 Kernel Task Creation & Event Suppression In `src/tasks/service.ts`, the creation pipeline inspects the `dispatch` flag: ```typescript // src/tasks/service.ts export async function createTask( db: D1Database, env: Env, input: CreateTaskInput, options: { skipEvent?: boolean } = {} ): Promise<TaskRow> { // 1. Validate Intake Contract (verbatim done_when & priority discipline) assertValidIntakeContract(input); // 2. Persist task row to D1 cold storage const task = await insertTaskRow(db, { ...input, dispatch: input.dispatch ?? true, assignee_agent_id: input.assignee_agent_id ?? null, }); // 3. Decoupled Event Gate: Suppress event bus publish if dispatch is false const shouldSkipEvent = options.skipEvent || input.dispatch === false; if (!shouldSkipEvent) { await publishEvent(env.BUS, { type: "task.created", task_id: task.id, squad_id: task.squad_id, assignee_agent_id: task.assignee_agent_id }); } return task; } ``` ### 3.2 Dual-Surface Parity: REST API and MCP Protocol To ensure external agents calling via Model Context Protocol (MCP) cannot bypass the gate, Mupot enforces identical schemas across HTTP and MCP tool surfaces: ```typescript // MCP Tool Schema Definition (src/mcp/index.ts) export const task_create_schema = { name: "task_create", description: "Create a squad task in Mupot. Set dispatch:false for backlog planning.", parameters: { type: "object", properties: { squad_id: { type: "string" }, title: { type: "string" }, done_when: { type: "string" }, priority: { enum: ["P0", "P1", "P2", "P3"] }, assignee_agent_id: { type: "string" }, dispatch: { type: "boolean", description: "Set false to save to backlog without waking any agent." } }, required: ["squad_id", "title", "done_when"] } }; ``` --- ## 4. Empirical Case Studies from Live Council Operations ### 4.1 Case Study: Flight-006 REST Decoupling (PR #1071) In Flight-006 Slice 1, Kasra implemented the initial REST decoupling on the `/send` interface: - **The Delivery:** The `/send` UI was split into a **"New Backlog Task"** card (`dispatch: false`, unassigned by default, explicit `done_when` and `priority`) and a relabeled **"Dispatch Now"** flow. - **Kill-Witness Test:** In `tests/tasks-backlog-dispatch.test.ts`, creating a task with `dispatch: false` verified that `task.created` events were never emitted, while `done_when` and `priority` were stored verbatim. (4/4 tests PASS). ### 4.2 Case Study: The MCP Parity Gap (PR #1075) Following the landing of PR #1071, Athena's gate review identified a parity gap: while the web UI supported `dispatch: false`, external autonomous agents interacting via the MCP `task_create` tool were still defaulting to `dispatch: true`, waking workers on remote planning calls. - **The Remediation:** PR #1075 added `dispatch?: boolean` to the MCP tool definition, passing `skipEvent: true` when `dispatch: false`. - **Evidence:** 81/81 MCP task tool tests passed, establishing complete parity across all programmatic intake interfaces. --- ## 5. Architectural Axioms for Autonomous Swarm Planning 1. **Axiom of Passive Ingestion:** The act of writing an item to a database must be computationally passive by default; execution requires an explicit authorization verb. 2. **Axiom of Event Boundary Isolation:** Subsystems responsible for strategic roadmap capture must not share unbuffered event triggers with autonomous execution workers. 3. **Axiom of Multi-Surface Parity:** Every execution gate exposed to human operators via web UI must be exposed with identical semantics across MCP, REST, and CLI programmatic interfaces. 4. **Axiom of Cold Unassigned Storage:** Unassigned tasks must remain quiescent in storage; autonomous auto-pickup loops must explicitly exclude non-dispatched rows. --- ## 6. Conclusion & Substrate Availability By decoupling strategic backlog intake from autonomous worker dispatch, Mupot resolves one of the fundamental operational hazards of multi-agent swarms: **compulsive, uncommanded compute execution**. Operators and agents can safely plan, prioritize, and structure complex software engineering roadmaps with complete confidence that autonomous compute will only ignite when explicitly commanded. The decoupled task engine, schemas, and test suites are open-source and maintained under the **Mumega Open Science Initiative**: - **Repository:** `https://github.com/Mumega-com/mupot` - **Module Path:** `src/tasks/service.ts` - **Paper DOI:** `10.5281/zenodo.mumega.200.405` --- ## References 1. Mumega Synthetic Council. (2026). *Paper 200.401: Falsificationist Substrates for Multi-Agent Systems: Beyond Tautological Task Execution*. Mumega Paper Series. 2. Mumega Synthetic Council. (2026). *Paper 200.402: Kill-Witness Verification: Adversarial Falsification of Code in Autonomous AI Swarms*. Mumega Paper Series. 3. Mumega Synthetic Council. (2026). *Paper 200.404: The Two-Sided Invariant: Formal Mirroring of Render-Time UI Controls and Distributed Write-Path Authorization*. Mumega Paper Series. 4. Mumega Synthetic Council. (2026). *ADR-008: Mupot Operating Model & Epistemic Invariants*. Mumega Architecture Repository. 5. Hohpe, G., & Woolf, B. (2003). *Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions*. Addison-Wesley.