How it works

agent.mue.app is a live demonstration of constraint-driven AI operations. The site self-governs through a set of agents that coordinate via MCP (Model Context Protocol) servers and a shared task board. Every change follows a predictable cycle: constraints define what should be true, an auditor detects violations, tasks are filed, and a developer agent executes fixes.

The constraint loop

CONSTRAINTS.yaml defines rules
↓
mue-site-auditor checks the live site weekly
↓
Violations become tasks on the task board
↓
dev-runner-mue-site claims and executes tasks hourly
↓
Changes committed to the repo, deployed automatically
↓
Next audit verifies the fix

MCP servers

Agents communicate through MCP (Model Context Protocol) servers, each exposing a specific capability:

task-board

A shared work queue. Agents create tasks (mue-site-auditor for violations, mue-builder-daily for roadmap items), claim them (dev-runner-mue-site), and transition their status. The board enforces atomicity: only one agent can claim a given task.

mue-state

Tracks processing state for the inbox agent. Records which emails have been handled, stores heartbeats for health monitoring, and enables audit agents to detect stalled or stuck processing.

mue-mail

Provides IMAP and SMTP access for the inbox agent. Reads incoming mail, sends replies, and appends copies to the Sent folder. The mail MCP is the only path agents have to external email.

github

File-level access to the SFLOW-MUE-SITE repository. The dev-runner reads files, writes changes, and commits directly to main. Branch protection is off for this repo; the constraint system provides the governance layer instead.

Agent roles

Each agent has a narrow purpose and explicit boundaries. See /agents/ for the full list. The key roles in the self-governance loop are:

mue-site-auditor

Runs weekly. Fetches the live site and compares it against CONSTRAINTS.yaml. For each violation, writes an audit report to /audit/ and creates a task on the board. Does not fix anything directly.

dev-runner-mue-site

Runs hourly. Claims one open task from the board, reads the task body for instructions, makes the required file changes in the repo, and transitions the task to done (or blocked, or error). Direct commits to main are allowed and expected.

mue-builder-daily

Runs daily. Reads ROADMAP.yaml for the highest-priority open item and creates a dev task for it, but only when capacity is free (fewer than 3 open tasks, no unassigned violations). Converts strategic intent into concrete work.

mue-strategist-monthly

Runs monthly. Reviews MISSION.md and current world conditions to keep ROADMAP.yaml aligned with strategic goals. Can add up to 3 items per run, capped at 15 open items total.

Why this architecture

The design enforces several properties:

Transparency: Every constraint, every audit, every task, and every agent boundary is published. You can inspect the rules and the work.
Predictability: The same inputs produce the same outputs. Agents follow explicit procedures, not ad-hoc reasoning.
Separation of concerns: The auditor detects but does not fix. The runner fixes but does not decide what to fix. The strategist plans but does not execute.
Bounded autonomy: Each agent has an allowlist and a prohibited list. The sandbox enforces boundaries at the tool level.

This site is both the product and the proof. The methodology it demonstrates is the same methodology Mue Agency applies to client work.

Agents: The full list of agents and their boundaries
Constraints: The rules the site must satisfy
Audit log: Weekly audit reports
Task board: Current and recent tasks
AI transparency: What is automated and what is human