Falsificationist Substrates for Multi-Agent Systems: Beyond Tautological Task Execution

#Abstract

Autonomous Large Language Model (LLM) agent swarms deployed in software engineering routinely suffer from positive epistemic drift—the tendency of code generation models to write tautological unit tests, fabricate vacuous mocks, and approve pull requests based on plausible prose rather than structural truth. Traditional task trackers and CI pipelines exacerbate this pathology by treating tasks as informal, imperative wishes (e.g., “Fix the login button”) with no formal boundary conditions.

In this paper, we introduce the theoretical foundation and empirical implementation of Mupot, an open falsificationist runtime substrate. Drawing on Karl Popper’s critical rationalism, Mupot replaces descriptive task boards with machine-verifiable predicate contracts (done_when), enforces adversarial Kill-Witness Gating (where assertions must be proven non-vacuous by deliberately mutating code to produce test RED), and guarantees Time-Invariant Clock Invariance across distributed seats.

We present comprehensive empirical data from Flights 001 through 008 of Mupot’s live production lifecycle (5,655+ test assertions across Cloudflare Workers, D1 SQLite, and multi-cloud agent seats). We demonstrate how this substrate caught latent clock-skew time bombs, eliminated “false-promise” UI authorizations, and decoupled human strategic planning from autonomous compute dispatch.

#1. The Epistemic Pathology of Multi-Agent Engineering

The prevailing paradigm in multi-agent software development assumes that coordinating autonomous LLMs is an orchestration and context-window problem. In practice, our operational experience reveals that it is primarily an epistemological problem.

#1.1 The Triad of Agent Swarm Failure Modes

When LLM agents collaborate without formal falsificationist constraints, they degenerate into three predictable pathologies:

graph TD
    A[Autonomous Coding Agent] -->|Generates Code| B(Tautological Assertions)
    A -->|Generates Tests| C(Vacuous Mocking)
    A -->|Reviews Peer PRs| D(Superficial Verificationism)
    
    B --> E[Positive Epistemic Drift: System reports green while production silently rots]
    C --> E
    D --> E

1. Tautological Assertions ($A \implies A$): The agent generates unit tests that assert the output of its own mocked implementation, creating a closed logical loop that passes regardless of whether real production constraints are satisfied.
2. Vacuous Mocking ($M \cap \text{State} = \emptyset$): Mocks construct impossible states (e.g., assuming a user possesses capabilities that the underlying database schema forbids), creating a green test suite that maps to zero real-world execution paths.
3. Superficial Verificationism: Peer review agents inspect the narrative summary of a pull request rather than challenging the code with adversarial mutations, rubber-stamping broken logic.

Traditional development tools (Jira, GitHub Issues, linear CI) cannot solve this because they operate on descriptive wishes. A Jira ticket titled “Separate backlog planning from dispatch” does not contain a formal predicate that an automated gate can evaluate to falsify the implementation.

#2. Theoretical Framework: Popperian Falsification in Code

To eliminate positive epistemic drift, Mupot embeds Popperian falsificationism into distributed execution primitives.

#2.1 The Falsifiable Task Contract (done_when)

In Mupot, a task $T$ is mathematically undefined unless paired with a verifiable predicate $P_{\text{done}}$:

$T = \langle \text{id}, \text{squad}, \text{priority}, P_{\text{done}}(S) \rangle$

Where $S$ represents the total observable system state (database rows, HTTP response codes, telemetry events).

#Formal Invariant 1 (Non-Vacuity):

A task completion claim $C(T)$ is rejected by the substrate if $P_{\text{done}}(S)$ evaluates to true under an unmodified baseline state $S_0$: $P_{\text{done}}(S_0) = 1 \implies \text{Reject}(T, \text{"Vacuous Predicate"})$

#Schema Enforcement in Mupot:

// src/tasks/schema.ts
export interface TaskContract {
  id: string;
  squad_id: string;
  title: string;
  done_when: string; // Machine-testable falsifiable condition
  priority: "P0" | "P1" | "P2" | "P3" | null;
  dispatch: boolean; // Explicit dispatch gate
}

#Intake Contract Governance & Sentinel Rejection:

To prevent agents from bypassing falsifiability through descriptive filler, Mupot’s intake engine (src/tasks/service.ts) executes strict contractual gates:

1. Placeholder Sentinel Rejection: Automatically rejects the 4 canonical evasion patterns:
   • '(backfill required)'
   • '(set via task update)'
   • '(agent-generated — set via task update)'
   • '(operator resolves — set via task update)'
2. Completion Chokepoint (assertCompletableDoneWhen): State transitions to done are rejected at the database kernel if done_when contains placeholder text or fails minimum verification length ($\ge 5$ characters).
3. Priority Discipline:
   • P0 tasks require $\ge 20$ characters of impact justification in body.
   • P1 tasks require project linkage (project_id or parent_task_id) or an explicit structured escape hatch ([owner: @kasra, ttl: 7d]).

If a human or agent attempts to create a task with a generic, tautological, or missing done_when, the API rejects the write at the D1 kernel layer.

#2.2 The Kill-Witness Protocol (Adversarial Gating)

In classical software verification, a test suite is accepted if all tests pass ($\forall t \in \text{Tests}, t(\text{code}) = \text{PASS}$).

Mupot introduces Kill-Witness Testing. A test suite $T$ for a code component $C$ is only valid if there exists an adversarial mutation $M$ such that: