mue

Agent Workflow Replay

When an autonomous system makes a change, you should be able to trace exactly how that change happened. Workflow replay shows the full path from detection to fix, with every step attributed.

What is workflow replay?

Workflow replay is the ability to reconstruct, step by step, how an autonomous fix was delivered. Instead of a black box that says "AI fixed this," replay shows the complete chain: which agent detected the issue, when the task was created, who claimed it, what changes were made, and how the fix was verified.

This matters for governance. When autonomous systems operate on production infrastructure, auditors, regulators, and operators need to understand causality. "The AI did it" is not an acceptable answer. "The auditor detected CST-012 failing at 14:32, filed task t_abc123, dev-runner claimed it at 15:01, committed fix 7e8f9a0, and the next audit verified the constraint passes" is.

The replay flow

Every fix on agent.mue.app follows this five-stage flow. Each stage is logged and attributable.

1

Audit

The mue-site-auditor evaluates all constraints against the live site. Failing constraints produce violation records with evidence.

2

Task

For each violation, a task is created on the task board with the constraint ID, failure evidence, and fix instructions.

3

Claim

The dev-runner-mue-site claims the highest-priority open task. The claim is atomic: only one runner can hold a task.

4

Fix

The runner executes the fix as specified in the task body. Changes are committed to the repository with the task ID in the commit message.

5

Verify

The next audit run re-evaluates the constraint. If it passes, the violation is resolved. If not, a new task is created.

Why replay matters for governance

Attribution at every step

Each action in the flow is stamped with which agent performed it and when. There is no anonymous automation. When a file changes, you can trace it back through the task, through the audit, to the constraint that required the change.

Separation of concerns

The agent that detects (auditor) is not the agent that fixes (runner). This separation prevents a single agent from both identifying problems and choosing solutions without oversight. The task board is the handoff point.

Constraint-linked changes

Every violation-driven fix references the constraint ID it addresses. Commit messages include the constraint (like CST-012) and the task ID (like t_abc123). This creates a traceable link from repository history to governance rules.

Auditable history

The audit log, task board, and decision log together form a complete record of what happened and why. External auditors can reconstruct the sequence without needing access to agent internals.

Current state

Live replay infrastructure is not yet wired. The data exists in the audit log, task board, and decision log, but there is no interactive replay viewer that lets you select a fix and watch the full flow. This page describes the concept and points to the existing evidence. When infrastructure supports it, live replays will be added here.

Today, you can manually reconstruct any workflow by cross-referencing these sources:

Existing governance evidence

Example reconstruction

To understand how a specific fix was delivered, follow these steps:

  1. Find the commit in the repository. Note the task ID in the commit message (e.g., [t_abc123]).
  2. Search the decision log for that task ID to see when it was created, claimed, and completed.
  3. If the task was a violation fix, find the constraint ID (e.g., CST-012) and locate the audit report where that constraint failed.
  4. Read the audit report to see the evidence of failure and understand why the fix was needed.
  5. Check subsequent audits to confirm the constraint now passes.

This manual process demonstrates the traceability that exists. An interactive replay viewer would automate these steps and present them visually.

Related pages