BCO + Critical Boiler: From a Project Brief to an AI Development Workflow

I want to give a development system a serious project brief, let it organize the work, and come back to something I can inspect: implemented features, verification, review findings, and a clear account of what still needs my attention.

That ambition has shaped Better Codex Orchestrator, or BCO, the product I am getting ready to put in the hands of a small private beta group.

BCO brings task management, agent orchestration, execution history, and control over automation into one local development workspace. Paired with Critical Boiler, it connects the preparation of a repository to the ongoing work of building a project from a brief.

The appealing part is how much coordination this can take off your hands. The consequential part is that you can still see what happened, examine why work stopped, and decide how much independence to give the system.

I built BCO, so this is a creator’s preview based on my own use during a real development workflow on September 21, 2026, including unfinished work and visible blockers. The original screenshots have been replaced with clearly labeled conceptual illustrations that explain the workflow. These illustrations do not reproduce the application interface or provide evidence that the project shown was finished.

This article preserves that September preview. Its reported counts and invitation plans describe that point in development; they are not a live availability notice or evidence from independent beta users. The October review clarifies execution permissions below without replacing the original workflow with an unrecorded success story.

The work between prompts

An AI coding session can produce an impressive feature. Developing a whole project introduces another set of responsibilities.

Someone has to break the brief down, notice that one feature depends on another, provide project conventions, check that the right tools exist, decide when testing should happen, and send rejected work back for correction. Someone also has to remember what happened across sessions.

Often that someone is the developer, manually passing context between conversations and keeping a separate backlog synchronized with the repository.

BCO is my attempt to make that coordination part of the product. You can supervise closely when the work is uncertain, or allow a prepared sequence to continue without manually starting every step. The same task records and execution history remain available in either case.

For an independent developer, that could mean spending more attention on product direction and acceptance. For a small team, it could mean a more consistent way to prepare, delegate, and review agent work. Those are the benefits I want the private beta to test against projects beyond my own.

Why Critical Boiler and BCO belong together

Critical Boiler prepares the repository an agent will work in. It writes the repeatable context: project instructions, architecture guidance, framework skills, styling foundations, command notes, and a definition of done.

Its optional BCO enhancement adds the project’s orchestration roles and the skills used to prepare and execute native BCO tasks. This saves a considerable amount of manual setup before the first meaningful workflow.

The responsibilities fit together like this:

1. Prepare with Critical Boiler. Establish the repository conventions, relevant skills, and orchestration setup.
2. Plan from your brief. Produce a proposed task graph with dependencies, acceptance criteria, and verification requirements.
3. Review and import in BCO. Inspect readiness and correct problems before the plan becomes active work.
4. Run and supervise. Follow specialist execution, approvals where required, live activity, and retained evidence.
5. Continue from the result. Inspect the proposed next action and launch it yourself or allow BCO to execute it automatically.

There is a practical boundary here: Critical Boiler is a repository starter and guidance generator, not a complete web-framework scaffold. For web projects, the actual application entrypoints, dependencies, scripts, and required tools still need to exist. You can establish those during project setup or include appropriate enabling work in the plan.

The supported frontend families include React, Vue, Angular, Svelte, Astro, Next.js, and Nuxt, with framework-aware guidance and styling choices. That makes the combination particularly interesting for frontend projects. Existing projects can also benefit, provided their real conventions and commands are reflected in the setup.

BCO does not require every project to use the same team of agents. Critical Boiler supplies a ready-made arrangement; the project defines the roles it actually uses.

My earlier Critical Boiler launch post describes its original Beads integration. The combination shown here uses BCO’s native task system. That is the current setup discussed throughout this preview.

From briefing to a plan you can actually run

The starting point should be a description of the product you want to build: its users, pages, interactions, design expectations, constraints, and what counts as a successful delivery.

Consider an illustrative brief for a small observatory website: a distinctive visual identity, an events section, research pages, an accessible image gallery, responsive navigation, and a production build. The brief should also say which content and assets already exist, which need to be produced, and whether deployment is included.

Automatic decomposition becomes useful when it identifies the relationships inside that request. Navigation depends on agreed routes. A gallery depends on usable assets. Visual acceptance needs a browser and a design target. Final integration depends on the feature work it is supposed to verify.

Critical Boiler supplies two complementary skills:

• $bco-project-planning prepares the project task graph from an authorized brief. It examines the repository, checks prerequisites, and produces the structured JSON plan that BCO can preview and apply.
• $bco-task-orchestration guides execution of assigned native tasks, including coordination, evidence, and completion requests.

This means you do not have to hand-author a large JSON backlog. The planning agent can prepare it, review it against the brief, and repair missing prerequisites or conflicting expectations before you import it.

A useful planning request can be as straightforward as:

Use $bco-project-planning to turn this brief into a complete BCO task plan. Inspect the repository and available tools. Preserve the requested product scope, identify dependencies and missing inputs, and define observable acceptance and verification. Return the complete plan JSON and explain anything that is not ready. Leave application of the plan and automation settings to me.

That last stage matters. A generated plan is still a proposal. BCO previews the plan, checks its structure and readiness, and performs an AI review against the repository before applying it. If the plan needs correction, you get findings to work through rather than an apparently successful import that hides the problem.

Some tasks can legitimately wait for a tool or input supplied by earlier work. An importable plan therefore does not imply that every task is immediately launchable. BCO checks requirements again when work is about to start.

The practical setup sequence is short enough to repeat:

1. Prepare the repository and run Critical Boiler with the BCO enhancement enabled.
2. Establish the framework and tools needed for the initial work, or explicitly plan the steps that provide them.
3. Register the project in BCO, select native tasks, and select the generated developer orchestrator.
4. Give the planning skill your brief and review the resulting JSON and readiness report.
5. Preview and apply the plan in BCO, then inspect the task dependencies and outstanding requirements.
6. Start the first ready task and choose how much supervision you want for subsequent work.

There is also a direct-prompt path for work that does not need a managed backlog. The full planning flow earns its place when the project has enough dependencies and follow-up work to make coordination expensive.

A task board that understands readiness

The board provides familiar lanes: Open, In progress, Blocked, Deferred, and Completed, along with project selection, search, priority, type, and status filters.

Its value becomes clearer in the information attached to those cards. A task can have acceptance criteria, verification requirements, parent and dependency relationships, required tools or inputs, ownership, evidence, and a history of the work performed against it.

During the September workflow, I observed 40 visible tasks, including work in progress, completed prerequisites, and an explicit capability wait. That count describes that moment in the project, not a performance benchmark or a count encoded in the illustration.

That lets the interface communicate distinctions that a plain checklist cannot. A task may have a valid automation setup but still depend on unfinished work. Another may be waiting for a required capability. Another may need its own definition corrected before execution is appropriate.

For the user, this reduces the amount of detective work behind “Why hasn’t this started?” You can look for the missing input, unfinished dependency, or readiness defect instead of repeatedly telling an agent to continue.

Completion also carries more meaning than a conversational “done.” Testing, review, artifacts, and Git delivery evidence can be associated with the task. When verification or independent review rejects the work, the workflow can move through correction and fresh verification within its available limits.

The depth is there when you need it, while the board remains an overview of the project.

Choose how closely you want to supervise

BCO has two controls that are easy to confuse because both affect how hands-off development feels.

Experimental Brain Effect, or EBE, controls automatic continuation. After a workflow ends, BCO’s AI governor reviews the result and records what should happen next. With EBE disabled, you inspect that decision and start the next workflow manually. With EBE enabled, BCO can execute that same recorded decision automatically.

YoLo changes Codex execution permissions. In the preview implementation, Standard requests approval when needed and uses the workspace-write sandbox. YoLo selects approvalPolicy: "never" and sandbox: "danger-full-access": it removes Codex approval prompts and filesystem/network sandbox boundaries for execution. BCO’s task scope and readiness rules still apply, but those workflow rules are not an OS sandbox. It does not create missing credentials or tools. OpenAI’s explanation of sandbox and approval settings

• Closely supervised — EBE off, YoLo off. You launch each next workflow and handle requested approvals.
• Manual handoffs — EBE off, YoLo on. You choose each workflow transition; execution uses full access without Codex approval prompts.
• Automatic handoffs — EBE on, YoLo off. BCO continues between workflows automatically, but approval requests can still need you.
• Most unattended — EBE on, YoLo on. The prepared workflow sequence can continue with full-access execution and automatic handoffs, while BCO readiness and runtime limits still apply.

With both disabled, you retain close human supervision without losing the planning and coordination benefits. You still get specialist work, review, task history, and a proposed next step.

With both enabled, a suitably prepared project can progress through a sequence of development workflows without your intervention at every handoff. That is the strongest form of automation BCO is aiming to make useful.

Unattended development still depends on a good brief, executable tasks, available tools, and a working runtime. Missing credentials, exhausted usage, unavailable services, unresolved product decisions, or failed checks can stop progress. Successful local development also does not automatically mean authorization to deploy or publish.

The next decision may be another task, focused recovery work, a task repair, a request for your action, or project completion. This is where the orchestration becomes more useful than automatically running the next line of a list.

See the team and the work it is doing

Critical Boiler’s complete orchestration setup includes a developer orchestrator, frontend and backend coordination, and specialist roles for planning, coding, testing, independent review, and documentation.

BCO makes that arrangement visible in the Orchestration scheme. You can inspect the roles configured for a project, their model and reasoning settings, their capabilities, delegation relationships, and when their source configuration was updated.

The workflow view then shows the agents actually involved, their roles and states, and their dependencies. You can distinguish running, waiting, and completed work, select an agent, and focus the activity view on that agent.

The available role catalog is not a promise that every task needs every specialist. A small change and a substantial feature should not automatically launch identical teams. Likewise, a card marked as reused represents more work on the same agent thread; it should not be mistaken for additional parallel workers.

This visibility makes a complex workflow easier to follow. If the coder has finished but testing is active, you can see that. If a reviewer rejects the result and the work returns for correction, that is part of the visible process.

During the September run, the reviewer recorded a rejection because the visual work did not meet the requested finish. Development continued, but that observation does not establish that the final design passed. The system needs to make incomplete work legible if I am going to trust it with longer sequences.

Come back later and understand what happened

Long workflows need a useful retrospective. I want to inspect the result without reconstructing an entire development session from disconnected conversations.

BCO retains workflow history and a timeline of activity. You can inspect agent updates, approvals, command activity, and the evidence available from the run. Linked command events lead to the corresponding command entry and retained output; linked subagent events let you focus on the relevant agent.

That makes practical questions easier to answer: Which command ran? What did it return? Which specialist was involved? Did review identify a problem? What evidence supports the next action?

Task evidence can connect those results to changed artifacts and Git commits. Git remains the place to inspect the actual source patch; BCO provides the task and workflow context around that change. The orchestration view’s source-update information serves a different purpose: showing which project role configuration you are inspecting.

The history also has honest limits. Retained command output is bounded, and older commands may have only completion summaries. An earlier passing check does not establish that later source changes passed the same check. A finished workflow and an accepted task are separate milestones.

This is the kind of detail that becomes valuable when you return after an hour, a restart, or several rounds of correction. You have a record to investigate instead of relying entirely on the latest summary.

The agents have faces, names, and a collection

One of BCO’s more personal features is its cast of actors.

Agents receive procedurally generated visual identities, with named characters drawn from historical figures. The faces have distinct variants, so the people you encounter across workflows build up a recognizable visual history.

The capture feature lets you save an actor variant from a workflow to your collection. You can browse characters by category, keep multiple variants of the same figure, and choose which variant appears at the front of that character’s card. Short descriptions introduce the historical person, and milestone information connects the capture to the work in which it appeared.

At the September observation, my collection contained 91 variants across 61 characters. The Computing & Engineering category included Lovelace, Tesla, and Turing, with two saved Tesla variants. These are reported collection observations; the illustrative medallions above do not verify the counts or reproduce those portraits.

There are categories spanning mathematics, physics, life sciences, medicine, computing, philosophy, and history. It adds a small discovery loop to the application: an unfamiliar name can become an invitation to learn about someone, and a favorite variant can become a souvenir of a development session.

The name and portrait are presentation, not a claim that an agent reproduces the historical person’s intelligence or personality. What I like about the feature is more ordinary: it makes the workspace memorable. “The reviewer from that difficult run” can have a face you recognize.

The operational features justify using BCO. This is one of the features that makes me enjoy spending time in it.

The controls that matter after the first impressive run

Daily use requires more than starting agents. BCO includes settings for the workspace, project configuration, attention, storage, and recovery.

Arrange the workspace around your habits. Sections in the navigation rail can be reordered, including through keyboard controls. The application header can stay pinned while you move through a long workflow. Those preferences help keep frequently used views within reach.

Manage projects explicitly. Settings brings together registered project folders, root agents, task mode, Git delivery choices, specialist limits, and the Standard or YoLo default. Project setup is visible and reviewable rather than something you have to remember from an earlier conversation.

Choose when the app asks for attention. Audio preferences control workflow sounds. Windows background attention can signal a pending approval or a result, so close supervision does not have to mean continuously watching the window.

Keep an eye on runtime health. Diagnostics and setup support help inspect connection health, project registration, and prerequisites. These become especially useful when the app and development environment have been running for a while.

Manage the data behind the history. Storage settings show database and backup health. Backup controls cover on-demand creation, archive verification, daily or weekly scheduling, retention preferences, and reviewed deletion of managed archives.

During the September observation, the storage view reported a healthy database and an existing backup. I did not change backup or retention settings for the article, and this was not a restore test.

These controls have boundaries worth understanding: scheduled backups require BCO’s background service to be running; saving a retention policy does not itself delete archives; and verifying an archive is different from successfully testing a restore. BCO’s database backups also serve a different purpose from backing up your project repository.

EBE adds a neural activity backdrop to the workspace, giving automatic continuation a visible presence. Reduced-motion presentation is supported. The visual treatment and character collection give BCO a personality, while the task board and inspection views remain the useful center of the application.

Where I expect this combination to be useful

The best starting point is a project whose desired outcome can be described and checked: a frontend with defined pages and interactions, an internal tool with clear states, or a sequence of features in an existing repository.

For a fresh project, Critical Boiler reduces repeated preparation. For a substantial backlog, automatic decomposition makes dependencies and verification explicit. During development, BCO coordinates the work and retains the evidence. Across repeated runs, the board and history help you understand where the project stands.

There is also value when you prefer to remain closely involved. You can use the same environment to inspect the plan, approve actions, examine review findings, and start the next workflow yourself. You do not need to adopt the most autonomous mode to benefit from the combination.

I would be much less confident handing it a vague instruction to “build a great business,” a project missing essential access, or a design brief with no usable acceptance target. Automating the sequence cannot supply decisions that nobody has made.

More agents also means more model usage and coordination. BCO is intended to reduce the developer’s orchestration burden; I am not claiming a universal speedup, a fixed token saving, or guaranteed production readiness. Local orchestration still uses Codex and its connected services, so it is not an offline AI system.

Why I am starting with a private beta

BCO is close to the point where I want other developers to use it seriously. It is still a beta: onboarding, long-running workflows, recovery, and the clarity of the interface need feedback from people with different projects and habits.

My current evaluation build runs on Windows. Access to the beta will include the relevant setup requirements; this preview is not a public download announcement or a commitment to a release date.

I am collecting email addresses from a selected group of people for that first private release. The most useful testers will have a real project in mind and be willing to describe what worked, what confused them, where they had to intervene, and whether the final result actually met their brief.

I particularly want to learn whether the task decomposition preserves intent, whether the readiness messages explain what to fix, whether the execution history makes review easier, and where the tradeoff between supervision and autonomy feels right.

I am managing those invitations personally and keeping the first group small enough to work through concrete feedback. This first release will help establish where BCO already earns its place in a developer’s workflow and what needs more work before broader availability.

The outcome I am working toward is a development environment where you can define a product, let a prepared team of agents carry the work forward, and return with enough visibility to judge the result. Critical Boiler provides the starting conditions. BCO makes the ongoing work something you can operate, inspect, and increasingly delegate.