GitHub Execution Ledger: Public Proof for Agent Work

Most AI product demos show the output.

The harder question is what happened before and after the output:

• Who asked for the work?
• Which agent accepted it?
• What files changed?
• Which tests ran?
• What failed?
• What got remembered?
• Which action is still waiting for approval?

That chain is the difference between agent theater and a system that can operate inside a real company.

#What Exists Now

On May 16, 2026, S063 moved from outreach-first into infrastructure for repeatable execution. The latest slice created the pieces needed for a public ledger:

This is not the full ledger launch yet. It is the first public milestone artifact: the shape of the ledger and the first proof batch that will feed it.

#Why It Matters

Agents fail in companies when their work cannot be audited.

The problem is not just hallucination. It is missing causality. A model can produce a correct patch and still leave the company unable to answer basic operational questions:

• Was this work requested by a human, a coordinator, or another agent?
• Was the task inside the correct tenant boundary?
• Did the agent use broad secrets or scoped tools?
• Did the result pass tests?
• Did any external action happen?
• Can another agent continue without asking Hadi to re-explain everything?

The GitHub Execution Ledger is the public-facing version of the internal answer we are building into SOS.

#The Ledger Shape

flowchart LR
A[Loom Directive] —> B[SOS Task or MCP Tool]
B —> C[Agent Implementation]
C —> D[Git Diff]
D —> E[Test Evidence]
E —> F[Runtime Smoke]
F —> G[Receipt or Memory]
G —> H[Public Milestone]
H —> I[Next Sprint Context]

Each step should be inspectable.

The ledger does not need to expose private tokens, customer data, or raw internal context. It does need to expose enough structure that a reader can see how work moved:

#The First Entry

The first candidate ledger entry is S063 Universal Onboarding Engine.

Loom asked for a tool that could onboard TROP, Amrita, or a new customer project with one call. Codex implemented sprout_tenant as a system-only SOS MCP tool.

The tool takes an absolute project path and generates:

• AGENTS.md
• .agent.md
• .mumega/inkwell-canvas.md
• .mumega/living-enterprise.json

It is safe by default. Existing files are skipped unless overwrite_existing: true is set. That matters because onboarding should prevent chaos, not overwrite a tenant’s local meaning.

The focused verification set passed:

#What The Ledger Will Not Be

It will not be a vanity changelog.

We do not need a public list of every tiny file edit. We need a ledger of meaningful execution units: the directive, the proof, the verification, the receipt, and the caveat.

The caveat matters. The S063 onboarding slice shipped with one unresolved dependency: configured Gemini credentials are currently invalid or permission-denied. The tool handles that by falling back to deterministic local inspection and returning warnings.

That is exactly the kind of thing a ledger should show. A serious execution record does not hide the imperfect parts. It shows what works, what degraded safely, and what needs repair.

#What Comes Next

The next step is to make the ledger mechanical:

1. Every completed slice emits a compact execution record.
2. GitHub receives the record as a visible artifact.
3. Inkwell can turn selected records into public milestones.
4. SOS and Mirror keep the private receipts that should not be public.
5. Loom uses ledger entries to steer the next sprint without asking agents to reread the world.

If this works, a customer should be able to inspect not just what Mumega claims, but how Mumega works.

That is the standard for a Living Enterprise: not autonomous output, but accountable execution.

#Related Mumega Work

• How mumega.com Runs Itself
• The Transactional Outbox
• What GBrain Teaches Us About Agent Memory
• What 1.191B Tokens Taught Us About Agent Supervision