Selected work

Private system · Engineering operations

Provider-Neutral Multi-Agent Engineering System

A control plane for moving software work from requirement to independently verified handoff across AI coding providers without losing ownership, evidence, or state.

Type
Engineering control plane
Role
System designer / engineer
Status
Active internal system
Focus
Agent orchestration, QA, state, recovery
PythonGitWorktreesJSON schemasCI gatesMulti-provider agentsIndependent QAEvidence trails
System map

The operating path.

A deliberately simplified architecture view. The case study below explains where the important guarantees and decisions live.

  1. 01Requirement
  2. 02Planner
  3. 03Work packet
  4. 04Implementer
  5. 05Independent QA
  6. 06Verification
  7. 07Handoff

The problem

Why this system needed to exist.

Most AI coding workflows are still organized like conversations. Context drifts, two agents can believe they own the same work, claims are accepted without durable evidence, and a handoff often means pasting a summary into another chat.

That is manageable for a small edit. It becomes dangerous when multiple providers, branches, worktrees, QA roles, recovery paths, and long-running implementation arcs are involved.

The system

How the pieces work together.

The system turns each unit of work into an explicit, stateful workflow: requirement, plan, work packet, implementation, independent QA, verification, and handoff. Agents can change while the contract and evidence remain stable.

A Python control plane manages ownership, branch and worktree expectations, locks, state transitions, immutable receipts, recovery, and blocking checks when identity or evidence does not match. Completion is treated as a verified state, not an agent saying it is done.

01

Workflow, not chat history

Every stage has a defined input, output, owner, and acceptance condition. A provider can be replaced without reconstructing the project from memory.

02

Fail-closed by design

Ambiguous ownership, identity mismatch, stale state, or invalid recovery is a blocking condition rather than an invitation to guess. Pre-mutation refusal and recovery behavior are treated as explicit hardening invariants.

03

Verification as a product feature

Tests, evidence, receipts, and independent review are part of the delivery path. They are not cleanup added after implementation.

Source boundary

This is an active private operating system used for real engineering work and continuously hardened as new failure modes are discovered. The public case study focuses on the workflow and safety model rather than exposing private repositories, prompts, or customer work packets.

A system like this on your roadmap?

Let’s make the hard parts explicit.

Discuss the project