Inspiration
I did not start ABC Governance as a software framework.
I started it as a working habit.
I am a novelist and writing instructor. My projects often contain long drafts, research notes, reference documents, and decisions made across many conversations.
Like many people who are new to AI, I used to put everything into one long thread.
At first, it felt convenient. Then that single thread had to become the manager, the researcher, the worker, the reviewer, and the memory of the entire project—all at the same time.
The longer the work continued, the harder it became to answer one simple question:
Does the AI still understand what I actually asked it to do?
This was not a problem I encountered once, and ABC was not an idea created for a hackathon.
By the time I decided to turn ABC into a product, I had already used Codex across 5,895 tasks and 16.46 billion tokens. My longest task had run for 51 hours and 51 minutes.
The B-executor and C-auditor skills I had built for my own work had already been invoked 517 and 159 times.
Those numbers do not prove that ABC is cheaper or better. They show that the problem was real, repeated, and lived.
ABC grew out of daily work—not out of a competition prompt.
After enough long projects, I realized that complex AI work should feel less like personally managing a crowd of agents and more like working with a good construction project manager.
A homeowner should not have to coordinate every electrician, tiler, painter, cabinet installer, and inspector personally.
They should be able to explain what they want to one project manager.
The project manager protects the plan, schedules the trades, and keeps the work aligned with the homeowner’s requirements. A surveyor checks the site before construction begins. Different workers enter at the right stage. An independent inspector approves each stage or sends it back for repair.
The homeowner remains in control, but does not have to manage every worker.
That became the clearest model for ABC Governance:
- A — Controller: acts as the project manager. It stays close to the user, protects the goal and boundaries, and coordinates the work.
- B0 — Scout: surveys the site. It maps the available materials, identifies gaps, and clarifies what exists before execution begins.
- B — Worker: performs a clearly scoped job using the relevant sources.
- C — Auditor: independently checks the evidence and the result before A accepts the work.
I used this method repeatedly in my own projects.
ABC Governance is my attempt to make that working method available to other writers and knowledge workers.
What it does
ABC Governance is not limited to document comparison.
It is designed for most non-trivial knowledge-work tasks: research, writing, analysis, planning, project coordination, document review, and software work.
The user does not need to be a programmer or understand multi-agent systems. They describe the goal, materials, boundaries, and expected result in ordinary language.
A typical request can be as simple as:
“Use ABC Balanced to complete this task, work from the available materials, respect the stated boundaries, and return a result that has been independently checked.”
A then turns that request into a governed workflow:
- A stays close to the user, protects the goal and boundaries, and decides how the work should be organized.
- B0 maps the available materials, identifies gaps, and clarifies what is known before execution begins.
- One or more B workers complete clearly scoped parts of the task.
- C checks the evidence and the result independently.
- If something fails review, A sends a targeted RepairTicket back to the appropriate worker.
- A returns the completed work, the audit result, and any decisions that still require human judgment.
The user does not need to create agents manually, assign every subtask, or inspect every intermediate step.
Very small tasks may not need ABC. But when work involves multiple sources, stages, dependencies, specialist roles, or independent review, ABC allows the user to explain the work once and remain in control without managing every worker personally.
For the verified demo, we deliberately chose a small document-comparison task because it is transparent and easy for judges to inspect:
“Use ABC Balanced to compare the documents in input, identify conflicts, missing information, and uncertainties, produce a decision report, and do not modify the source files.”
That demo is one application of ABC Governance, not the limit of what the workflow can support.
Instead:
- A stays with the user and keeps the main context focused.
- B0 maps the available materials before work begins.
- B reads the relevant sources and completes the scoped task.
- C independently checks the sources and the draft.
- A returns the result and identifies anything that still requires human judgment.
The user receives three readable outputs:
- a final report;
- a result card showing what passed and what still needs a decision;
- a run receipt showing what happened, which roles participated, and what the system could not verify.
In a verified demo, ABC surfaced conflicting decisions, missing information, and unresolved questions while preserving every source file byte for byte.
The same governed workflow has completed fresh Windows runs in both Local Work and Local Codex.
Local Work is the formally supported surface. Local Codex is included as an optional experimental path validated in a scoped managed Windows project using a documented system PowerShell runner configuration.
How we built it
Codex was not simply a code generator for this project.
It became the local engineering partner.
Codex helped build and test:
- project-level agent profiles;
- validation scripts;
- clean runtime rules;
- SHA-256 manifests;
- a blank runnable demo;
- a verified example;
- repeatable test runs;
- and the public release candidate.
It also helped us deal with failures honestly.
At one point, two test threads wrote into the same output directory. The results appeared successful, but the evidence was contaminated.
We did not hide the failure or treat the outputs as valid. We preserved the evidence, rebuilt the test using two isolated projects, and ran it again.
Later, named agents in Local Codex repeatedly failed before PowerShell could even start. The problem was eventually traced to the Windows runner being selected.
Codex helped identify the smallest project-level repair: explicitly selecting the system Windows PowerShell runner. We then validated a fresh A → B0 → B → C run without disabling the managed security mode, using generic substitute workers, or modifying the source files.
The project profiles are configured to use different GPT-5.6 capability tiers:
- Luna for material scouting;
- Terra for scoped execution;
- Sol for independent auditing.
The user chooses the model and reasoning level for A, the root controller.
This makes it possible to assign different capability levels to different responsibilities instead of automatically using the most expensive model for every step.
We also separate configured intent from verified runtime evidence.
When the host does not expose an actual model, session identifier, or telemetry value, ABC records that value as unknown rather than presenting an assumption as a verified fact.
Challenges we ran into
The hardest part was not getting several agents to communicate.
It was deciding who needed to know what.
If A reads every source and absorbs every execution detail, the main thread becomes overloaded again.
If B receives too little context, it may complete the wrong task.
If C only trusts B’s summary, the audit is not truly independent.
If every small correction creates a new worker, the system repeatedly pays the cost of reading the same materials again.
We therefore had to define:
- what each role must read;
- what information A should retain;
- when independent tasks can run in parallel;
- when the same B should be retained for a local repair;
- when a worker should be replaced;
- how C remains independent;
- how repair tickets return to the correct worker;
- and how to prevent the governance process from becoming more expensive than the task itself.
We also learned that local environments do not always behave identically.
The same ABC workflow may require different runtime handling in Work and Codex, even when the role definitions and user experience remain consistent.
Those failures became part of the product design rather than something we removed from the story.
Accomplishments that we are proud of
What I am proudest of is what the user does not have to see.
The user does not edit TOML or JSON.
The user does not manually create several agents.
The user does not need to understand task packets, sandbox policies, manifests, model routing, or audit contracts.
They open a project, explain the work once, and remain in control of the result.
The current MVP:
- completes a real A → B0 → B → C workflow;
- supports a one-sentence, plain-language entry point;
- preserves the source files;
- includes an independent C audit;
- supports targeted repair instead of restarting the entire task;
- produces a report, result card, and run receipt;
- separates a blank runnable demo from a verified example;
- reports evidence limits honestly;
- and has completed validated Windows runs in both Work and a scoped experimental Codex configuration.
What we learned
More agents are not the product.
The useful part is governance.
A useful multi-agent system needs clear responsibilities, bounded context, independent review, repair routes, and honest uncertainty.
It must know:
- when to continue;
- when to stop;
- when to repair;
- when to replace a worker;
- what evidence is sufficient;
- and what still requires a human decision.
A construction project is not well managed simply because many workers are present.
It is well managed because the right worker enters at the right time, the plan remains protected, each stage is inspected, and the owner knows when a real decision is required.
ABC Governance is not intended to remove human judgment.
It is intended to make the boundary of human judgment visible.
What’s next
The next step is to use ABC on the work it was born from: real writing, research, document review, and knowledge-management projects.
The MVP is now available in a public MIT-licensed repository.
Next, we will:
- simplify onboarding for non-technical users;
- test the workflow with early users;
- expand beyond the current document-comparison demonstration;
- harden the Local Codex adapter across more Windows environments;
- test long-running task continuity and worker reuse;
- and measure context reuse, cost, and quality only after the basic experience is reliable.
The long-term goal is simple:
Let people explain the work once, stay in control of the important decisions, and rely on a governed local AI team to manage the complexity in between.
Log in or sign up for Devpost to join the conversation.