Inspiration

AI coding agents are powerful, but they can also act on stale branches, conflicting documentation, incomplete product context, or assumptions inherited from an old conversation. In a large, long-running repository, the difficult question is often not “Can the agent write the code?” but “Should it act at all, and what evidence supports that decision?”

I built M55 Control Plane to make that decision explicit, deterministic, and portable across humans, AI agents, branches, and machines.

What it does

M55 Control Plane is a repository-native control layer for AI-assisted software development.

It has two complementary parts:

Guardrail checks whether an agent should begin work. It reads Git state, repository authority, worktree registration, current-versus-target declarations, active lanes, Human decisions, and prohibited actions. It returns a fail-closed verdict such as READY, READY_WITH_WARNINGS, or HOLD, and generates a fresh-agent handoff packet.

Consistency checks whether encoded product intent remains aligned across repository surfaces. It produces deterministic evidence records, separates current debt from compliance, keeps Human review explicit, and renders one canonical verdict for JSON, Markdown, operator, judge, and print audiences.

Together they answer two questions:

  1. Is it safe and authorized to act?
  2. Does the repository still represent the intended product contract?

How I built it

M55 is an existing product repository. During OpenAI Build Week, I added the Control Plane as a distinct developer-tooling layer:

  • repository audit and status-reduction engines
  • M55-specific and generic adapters
  • deterministic evidence and semantic digests
  • fail-closed handoff packets
  • judge, operator, Markdown, JSON, and print outputs
  • cross-platform path and output-boundary protections
  • synthetic projects and reusable adapter examples
  • extensive Node test coverage
  • a GitHub Actions example workflow
  • Build Week documentation and judge instructions

The Control Plane demo uses Node.js built-ins only. It requires no API key, no dependency installation, and makes no model or network call at runtime. Generated evidence is written outside the repository so the audit itself does not modify the project being inspected.

How I used Codex and GPT-5.6

I used Codex as the implementation and verification environment. It inspected repository authority, implemented the engines and adapters, ran tests, generated review packets, reproduced Windows-specific behavior, and performed tightly scoped commits and pull-request operations.

I used GPT-5.6 as an architecture and adversarial-review partner. It helped define evidence semantics, identify false-green states, separate current debt from target compliance, design fail-closed behavior, review cross-platform assumptions, and improve how the product communicates decisions to humans and fresh AI agents.

The runtime itself does not call GPT-5.6. The model was used to build, review, and validate the developer tool.

Challenges

The hardest challenge was preventing a superficially successful result from being interpreted as trustworthy evidence.

Examples included:

  • an all-excluded project appearing consistent
  • unreadable source files being treated as proof of absence
  • stale worktrees producing contradictory findings
  • platform-specific path behavior changing results
  • output directories escaping repository boundaries through links
  • a HOLD packet blocking implementation without explaining the reasons well enough to a fresh agent

Each of these cases was converted into deterministic, fail-closed behavior and regression tests.

Real-world pilot

I ran the Control Plane against the actual M55 development worktree.

It correctly returned HOLD rather than allowing implementation from an outdated, prohibited, or unregistered context. That pilot also revealed that the first bootstrap packet did not contain enough information for a new agent to independently explain the decision.

I then made a narrow handoff improvement and reran the same pilot. The resulting bootstrap preserved project identity, branch, commit, reason codes, implementation permission, next action, prohibited actions, Human decisions, and current-versus-target context.

The real-use sequence was:

inspect → refuse unsafe work → expose an evidence gap → make a minimal fix → verify again

Verification

The final implementation was verified with:

  • Guardrail: 55 / 55 tests passed
  • Consistency: 80 / 80 tests passed
  • macOS native execution
  • Windows 11 fresh-clone native execution
  • zero failed and zero skipped tests
  • identical two-run semantic digests
  • unchanged Git status before and after execution
  • no node_modules creation
  • a generic non-M55 “Orbit Field Notes” adapter using the same engine
  • PR #75 with all checks green

What I learned

Reliable AI-assisted development requires more than prompts. It requires explicit repository authority, stable evidence identities, deterministic status reduction, visible scope boundaries, and a Human-controlled decision point.

The most important output is sometimes not generated code. It is a well-supported refusal to act.

What’s next

The next step is to make the Control Plane easier to adopt across larger teams and repositories through additional adapters, CI templates, policy presets, and integrations with multi-agent development workflows.

The long-term goal is:

One repository. Many humans. Many AI agents. One evidence model.

Built With

Share this project:

Updates