The governed harness above coding agents

Run your coding agents as one crew

You already pay for Claude Code, Codex, Cursor and OpenCode. MUON puts one director in front of all of them. You give the mission once, the crew shares a single record of what the project knows, and the work comes back to you at the moments that need a human decision.

curl -fsSL https://getmuon.com/install.sh | bash
  • Works with the agent subscriptions you already pay for
  • Runs on your machine and keeps your code there
  • One record of what the team decided, confirmed by a person
The shared recordClaude CodeCodexCursorOpenCode

The shared record sits in the middle. Each frame around it is one coding agent you already use, receiving the context it needs and returning evidence the whole team can read.

The problem

Running four agents in four windows turns one project into four

Each agent starts a session knowing nothing about the last one. You paste the same background again, you review the same mistake again, and the decision you made on Tuesday is gone by Thursday. The tools are good. The way they are run is the problem.

You pay a context tax on every session

You spend a large part of every session re-explaining the codebase, the constraints and the reason the last approach was rejected.

Silent collisions

Two agents edit the same file in two branches. Nobody notices until the merge, and the cheapest fix has already been thrown away.

No memory of decisions

The reasoning behind a change lives in a chat log nobody can search. Six weeks later the same question gets a different answer.

Review without evidence

A diff arrives with no record of what the agent read, which constraints applied, or which callers the change reaches.

What MUON is

MUON is a harness that runs the models you already pay for

MUON does not write code and does not compete with the agents you use. It sits above them and supplies the three things they cannot supply for themselves: a director that plans the crew, a shared record of what is true, and a place where a person keeps authority.

Direction

A single director in front of every agent you use

You describe the outcome once. The superagent decides how many agents the job needs, which vendor suits each part, and how they hand work to each other. You stop copying context between four consoles.

How crews are built
Authority

Every agent works inside a role contract

A role names the purpose, the files it owns, the tools it may call, the sandbox it runs in, the evidence it owes and the budget it holds. A role can narrow what a lane may do. Nothing can widen it.

Read about roles
Shared record

Three graphs that all read from the same underlying record

The code graph, which we get from GitNexus, knows what calls what. The knowledge graph knows what your team decided and why. The coordination graph knows who is working on what right now. All three read from the same ledger.

See the graphs
Memory

Memory becomes trusted only after a person confirms it

Agents propose freely. Deterministic checks and independent corroboration filter what survives. A person turns a claim into canon. A classifier never gets that vote.

See how memory works
Control

A person authorizes the points that carry risk

Merging, releasing, spending more money, widening permissions, touching secrets and confirming company truth are authorized by a person — at the gate, or through standing consent you grant per agent and can revoke at any time. Egress and review-blind merges still ask, always. Ordinary reading and messaging inside an existing grant continue without ceremony.

Read the security model
Ownership

Everything runs on your machine, under your own accounts

The brain runs locally and listens on loopback only. MUON drives the agent binaries you installed and never holds a vendor token. Nothing about your repository has to leave the laptop it lives on.

What leaves your machine
4+
Agent vendors in one crew
3
Graphs over one ledger
0
Vendor tokens MUON holds
100%
Of merges authorized by a person

See it run

Follow one mission from the first prompt through to the merge

This sample mission is hand-authored and simulated — not a recording of anyone's real run. Scrub the timeline, watch the crew take shape, see the blast radius before the first edit, and make the merge decision yourself at the end.

Keyboard: Space plays or pauses, the left and right arrow keys step one beat, R replays from the start, and the timeline slider scrubs directly.

Sample mission · simulated replay · repository acme/payments-service

Add idempotency keys to the checkout charge path so a retried request cannot charge a customer twice.

Ready

Crew

  • Claude Code
    coordinate

    Mission coordinator

    Waiting for dispatch

    main0 tok
  • Codex
    write

    Implementer

    Waiting for dispatch

    muon/idempotency-keys0 tok
  • Cursor
    read-only

    Explorer

    Waiting for dispatch

    read-only checkout0 tok
  • OpenCode
    read-only

    Reviewer

    Waiting for dispatch

    review worktree0 tok

Mission log

Waiting for the mission to start.

    Your desk

    No decision needed

    The crew works inside the authority you already granted. You are called back only when a gate opens.

    Blast radius

    POST /checkoutretryQueuechargeCustomerchargeLedgerrefundWorkercharge testsreceiptMailer

    Memory recalled

    D-114 gateway retries a …C-27 payment writes stay…Retries come from the ga…Idempotency keys are der…Charges are safe to retr…
    0.0s / 32s

    Shared memory

    A claim only becomes something the whole crew can trust after review

    Most tools treat everything an agent writes down as knowledge. MUON treats it as a proposal until it earns its place. That single rule is what keeps a shared memory useful after the first month.

    Step 01

    An agent writes a claim

    Any agent in the crew can write into the pending tier. The claim is stamped with who wrote it, from which session, against which file or symbol.

    Step 02

    Deterministic checks run

    MUON checks the scope, the anchor, the policy, and whether the text is trying to smuggle in an instruction. Failures are held with a reason.

    Step 03

    A second agent corroborates

    A claim that another agent independently confirms becomes crew vouched. It can be retrieved and cited, and it is still not company truth.

    Step 04

    A person confirms it

    You or a scoped steward turn a crew vouched claim into canon. No classifier can do this step, and the superagent cannot confirm its own claim.

    The record a payments team builds while it works

    Select any record to read what it holds, who put it there and what depends on it. The colour tells you how far the claim has travelled towards being company truth.

    supportssupersedesconfirmedD-114C-27C-31retry originretry windowkey derivationunique indexold beliefchargeCustomer0054_keysPriya
    Decisions and constraints in blue, crew vouched memory in green, pending proposals in amber, superseded records in red, code anchors in yellow.

    Selected record: The payment gateway retries a charge up to three times

    Confirmed decision

    The payment gateway retries a charge up to three times

    Confirmed by Priya on 12 March after a duplicate charge incident. Nine later missions have cited this decision, and every one of them is listed on the record.

    Confirmed 12 Mar · cited 9 times

    Connected records

    What we are actually building

    Your agents share three graphs, and a person still makes the decision

    The code index is not our invention. We pin and ship GitNexus for that, and we credit it openly. What MUON builds is the layer above it: a memory graph, a coordination graph and a communication graph that several agents from different vendors can read and write at the same time, under one set of rules.

    Memory graph

    What the team decided, and what is still only a proposal

    Decisions, constraints, conventions, contradictions and supersessions, each with the person or agent behind it and the evidence they were given. Nothing becomes company truth until a person confirms it.

    Coordination graph

    You can see who holds which piece of work at any moment

    Live tasks, role contracts, work claims, budgets and dependencies. Two lanes cannot claim the same file, and every dispatch is recorded with the authority it was given.

    Communication graph

    What the agents told each other, and what was delivered

    Messages, handoffs, context frames and deliveries. When a review asks why an agent went down a particular path, the answer is a record rather than a guess.

    How the three graphs change a working session

    • An agent is told what a change would reach before it is allowed to make the change
    • Prior decisions about the same symbol arrive with the code, so nothing has to be re-explained
    • A change to a public route or a payment boundary raises a gate for a person automatically
    • Untrusted input keeps its label as it moves through summaries and messages
    • Every refusal names the exact step that would make the work possible

    Repository indexing is handled by GitNexus, an open project we pin to each workspace. We are grateful for it, and we would rather credit it than pretend we wrote it.

    Context allocated for one turn

    200,000 TOKEN WINDOW · IMPLEMENTER ROLE

    • Authority and role contract8%
    • Mission and task brief12%
    • Standing canon14%
    • Task relevant memory18%
    • Code and decision evidence22%
    • Live coordination state9%
    • Conversation continuity7%
    • Response headroom10%

    The shares move with the role, the phase of the mission, the risk of the change and how much the crew already knows. Every turn records what was eligible, what was included, what was left out and the reason for each.

    Start with the agents you already have open

    Installing MUON does not ask you to change model, change editor or move your code. It picks up the agent binaries on your machine, indexes the repository you point it at, and runs the first mission in a few minutes.

    curl -fsSL https://getmuon.com/install.sh | bash

    MUON is written for three kinds of reader. Individual developers who want their agents to stop repeating each other. Teams who want one shared memory instead of four private ones. Engineering leaders who need to answer who decided what, and why, months later.