BGOODWorks

Your coding agents can write the code.
The hard part is knowing what to trust.

BGOOD Orchestrator is an operating layer for coding agents. It decides what is safe to delegate, verifies each stage against your repository, and stops when a person needs to decide. It is in development, and we are looking for teams already running agents against real repositories.

You keep control of merge and deployment. BGOOD takes on the mechanical supervision work in between.

Does this sound familiar?

You still have to drive every step.

Start the story, watch the session, notice the stall, restart the work, and kick off the review yourself.

A green suite can still validate the wrong thing.

Tests can pass while the specification contradicts itself or quietly drifts from what was asked.

Finished-looking is not the same as finished.

An agent can report success without proving that the committed result is complete, reviewable, and the one that was actually checked.

More agents can mean more supervision.

Increasing agent volume increases coordination, recovery, and review effort unless the workflow can carry its own evidence.

The operating layer around your agents.

Your existing agent still writes the code. BGOOD runs the delivery process around it: choosing eligible work, launching each stage, checking validated handoffs and repository state, resuming bounded failures, and parking the decisions that need a person.

Before

A story is sized and checked for contradictory or oversized scope before an agent is dispatched.

During

Each stage must produce the evidence its next stage needs; a timeout costs a stage, not the whole story.

After

Completion is established from the verified commit and its repository evidence, not from an agent saying “done.”

A first pilot might be a low-risk bug fix or isolated feature in an existing repository—small enough to review, real enough to expose where the machinery is wrong. BGOOD works around your existing harnesses, tests, CI, pull requests, and review practice.

Apply for the early-access pilot

Why BGOOD exists

I wanted to queue a sprint on a Friday and read a pull request on Monday. That was the whole of it.

Even with a good workflow framework, I was still the one invoking every step, watching for stalls, and deciding whether what came back was finished or merely finished-looking. Automating the sequence for throughput would remove the reviewer along with the driver, because an agent reports success the same way whether or not it succeeded.

Writing the code stopped being the constraint. Checking it became the job. The mechanical questions — did the story make sense, did its criteria contradict each other, did the tests run against the commit under review — have right answers. They should not consume the attention needed for design, architecture, and the decisions that have no mechanical answer.

That is what everything here that looks like governance is: machine- executable checks grounded in the repository, evidence instead of assurances, and a refusal to call something done that has not been measured as done. A machine vouching for a machine is the problem, not the solution.

More throughput is the intent. Whether it materialises on your work is something to measure, not something for us to claim.

The controls are not the point. They are the price of the point.

Join the early-access pilot.

If your team is already running coding agents against real repositories and feeling what it costs to supervise them, we would like to run one bounded story with you and learn where the machinery is wrong. This is an early-access pilot, not a sales demo: there is nothing to buy, and your team keeps merge and deployment authority.

Questions worth asking

Answered from what the engine does today, not what we intend it to do. Where the honest answer is that we have not established something, it says so.

Before the pilot

The Orchestrator is in closed beta, and we are inviting a small number of teams to help test it on real work.

Can I use it today?
Not generally. It is available only to selected closed-beta pilot teams; there is no published package or public install path yet. Pilot access is for teams ready to run BGOOD against real work before public release.
Is BGOOD open source?
The Orchestrator will be. The commercial layer above it will not. The boundary is architectural: enforcement stays local and inspectable, and a customer who stops paying keeps the guardrails they installed working.

Whether the machinery can be trusted

The questions we would ask first, and the ones the code was mostly written to answer.

Doesn't TDD already solve this?
Partly, and the part it does not solve is the part this exists for. TDD stops tests being shaped by the implementation, and the engine requires tests as part of its own gates. But TDD’s oracle is the specification: it proves the code does what the spec says and is silent on whether the spec was right. In one real run the validation stage rejected a specification whose acceptance criterion required a state the specification’s own clause forbade. The session that wrote it would have written tests agreeing with it — independence comes from a different actor, not a different order.
How can I trust an agent that writes its own tests and its own review evidence?
You do not have to trust the agent’s prose. BGOOD accepts a stage only when it can verify the required result and evidence independently; a response that simply says PASS is not enough. Findings above the agreed threshold stop the work and send it back for correction rather than being waved through.
What stops a plausible but incomplete result from passing?
A stage passes only when it can show the specific result it is responsible for; a successful process exit is not enough. Before work starts, BGOOD checks the story’s scope and readiness. Before delivery, it verifies that the commit being pushed is the same commit that passed the checks. The project’s own validator enforces its schema and policies, including splitting stories that are too large.
If one model family judges its own work, isn't that a monoculture?
Yes. Correlated judgement is a known failure mode, so judgement seats can be routed to a different declared model or harness. Evaluation can use two samples, and the execution summary records which models actually ran so a reviewer can check the independence afterwards.
How does it know a story is done rather than looking done?
Completion is measured, not claimed. BGOOD confirms that the exact change it verified is the one that reached the pull request; it does not treat an agent report or a successful API response as proof. If the remote branch has changed, it stops rather than overwriting that work.
Your gates run inside the agent's worktree. Can they actually see what was committed?
Not by themselves. Worktrees can contain ignored files, so BGOOD performs a separate clean-tree verification from the committed revision before treating the result as complete. The project still controls which command runs during that verification.
What happens on a timeout?
The stage fails and re-enters rather than restarting the story. The work already completed is preserved, so a dead session costs the affected stage—not the entire delivery.
Does it have self-healing?
It recovers from bounded, defined failures and refuses to pretend about the rest. A failed stage can be repaired and retried, while a rejected specification can return for revision. When requirements conflict, a guardrail is implicated, or product judgement is needed, the story parks with a named reason.
What if a run damages my repository?
Each story runs in an isolated worktree, so the main checkout is not changed during the run. Before cleanup, the working state—including uncommitted files—is preserved for recovery. A failed run can be inspected without losing the work that led to it.
Can it roll work back safely?
Rollback is a new, stopped run from a known checkpoint, never an in-place revert. You review the plan before starting it, while the original run and its history remain unchanged. Nothing already deployed is touched.

Fitting the process you already have

The engine is meant to be additive. Where it is not, that is a bug in it.

We already use BMad. Why would we need this as well?
They answer different questions. A workflow framework defines how an agent should produce work; BGOOD runs that process, decides what is eligible to delegate, verifies each stage against repository evidence, and handles retry, recovery and escalation. It sits around the workflow rather than replacing it. If supervising and recovering agent work is not costing you anything today, you do not need another layer.
Which Agent harnesses and models are supported by BGOOD?
Claude Code, Codex and Copilot are supported along with whichever models your subscriptions provide access to.
Does this weaken my pull request review, or my CI?
No. It prepares a better-evidenced candidate for the same pull request, the same CI and the same reviewers, and where its evidence disagrees with either, they win and the disagreement becomes feedback for the policy. Merging is a human act; the engine initiates every crossing and completes none of them.
Does it force me into your workflow or your agent harness?
No. It works around the workflow and harnesses you already use. You declare which integrations are allowed, and if a control is not available in one of them, BGOOD names that limitation instead of silently dropping it.
What does a reviewer actually receive?
A pull request with a review brief and an execution summary: which stages ran, what verdict each received, which tools judged them, and why anything ran twice. The summary is accompanied by machine-readable evidence for tooling.
Where does the evidence live once the run is gone?
In your git repository, as tracked content. The delivered story ships its evidence package inside the story commit, so it travels with the change and remains covered by the repository’s existing history, backup and access controls.
Can I actually queue an epic and walk away?
A queue can take a single story, a list, or an epic from the sprint board. It holds stories whose declared prerequisites are not done and re-checks them as work finishes; it does not schedule, prioritise or run stories in parallel. Whether walking away is wise on your repository is exactly what a pilot should establish.
How do we stop people delegating work that should not be delegated?
Sizing runs before dispatch and returns go, split or blocked with an effort, risk and confidence assessment. Low-confidence approval is checked again, and disagreement takes the conservative result. Split and blocked are successful safety outcomes, not failures.
Does it re-specify work that is not deliverable as written?
It can send a specification back for revision, but it cannot redefine the work. If requirements conflict or the story is not ready to implement, BGOOD pauses before dispatch and requires the specification to be rewritten and re-validated. It cannot quietly narrow a requirement, change public behaviour, or alter acceptance criteria just to make the tests pass. Any change to product intent, business rules, risk, or acceptance criteria requires a human decision.
How much setup and ongoing maintenance does this need?
It requires real setup because BGOOD works with your project’s rules and tools. Your team defines what counts as valid work, which checks run, where evidence goes, and how much uncertainty is acceptable. BGOOD checks that configuration before dispatch and stops with a clear list of problems rather than guessing.

Cost, risk and accountability

The questions an engineering leader has to be able to answer to someone else.

Does it use more tokens? Is it cost-efficient?
BGOOD adds model calls for sizing, validation, review and evidence, so a clean task may use more tokens than direct assistance. But preventing a bad specification, unnecessary implementation or full restart can reduce the total tokens spent on an accepted delivery. The right comparison is total cost and token use per accepted change, including rework and retries—not the cost of one task. For trivial work, direct assistance may still be the better trade; a pilot should measure the difference against your current workflow.
How would we know this is better than what we do now?
You would not, on our word. Establish a baseline first, then compare lead time, engineer supervision time, restarts, rework, review acceptance and incidents on your own work. BGOOD is better only if it delivers acceptable changes with less coordination, freeing engineers for design, architecture and judgement without increasing risk. Expand only if your own numbers show that.
Will this create audit, security or accountability problems?
It is intended to improve accountability by keeping run state, evidence, decisions and the delivered commit joined. It does not replace your security controls, CI or approval policy; those remain authoritative. Dispatch permissions are explicit in your configuration rather than silently assumed.
Is this just automating developers out of the process?
No. BGOOD removes the mechanical half of checking agent-produced work—scope, consistency, evidence and completion—not engineering judgement. Decisions, merge and deployment stay human, so freed attention can go to design, architecture and exceptions.