Build, Operate, Govern: The Model That Lets an AI Company Run Itself

A company that runs itself needs more than agents that can code. It needs a shape that every team can copy, so that adding a tenth capability costs the same coordination overhead as adding the second. That shape is BOG — Build, Operate, Govern — and the part most descriptions of agentic AI get wrong is treating it as three departments. It is not three departments. It is one repeating pattern, applied at every scale from the whole company down to a single team of five agents, and the repetition is what lets the company grow without a human having to redesign the org chart each time. This is a follow-up to How We Built Our AI Agent Operating Infrastructure, which described the substrate BOG runs on. This piece is about the model itself: what a team owns, how it checks its own work, where the two governance boards actually intervene, and what a normal day looks like inside a cell.

Governance as a setting is the industry's real gap

Look at what the agentic-AI tooling market actually ships. The build layer is crowded and excellent — Cursor, Warp, Devin, Claude Code itself, all genuinely good at getting an agent to write code inside a workspace. The operate layer is also well served: Salesforce Agentforce, Microsoft Copilot Studio and a wave of vertical agents automate real workflows inside real companies. What is thin, almost everywhere, is governance that is structural rather than configurable. EY's own agentic operating-system research names a "Data & Trust Foundation" layer, and Salesforce's Agentic Enterprise architecture treats governance as a control plane sitting over the agents — in both cases, and in most of the commercial tooling built on the same pattern, the brake is a setting an operator turns on, not a seat with its own judgement and its own authority to say no.

That gap is not cosmetic. According to a 2025 Gartner-attributed industry report, more than 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls — and every one of those three causes is a governance failure, not a build or operate one. Teams are shipping agents that work, in the narrow sense of producing correct output, and cancelling the projects anyway because nothing structural was stopping the output from causing damage at scale.

We made the opposite bet on purpose. Govern is not a fourth thing bolted onto Build and Operate; it is one of the three pillars, with its own owners — the CFO brakes spend, the CCO blocks non-compliant launches, and a human sits at the one gate neither of them can waive: the release to production. The CFO and CCO are structured as adversarial roles by design — either can block a launch or a spend regardless of what the team that wants it thinks, and their sign-off routes to a human, not to the seat being checked. That is a materially different shape from a governance dashboard a builder can quietly turn down.

Every cell is the whole model in miniature

The part that makes BOG durable rather than merely well-intentioned is that it is fractal. The three pillars are not just how the company is organised at the top — CTO and the Lead Architect building, the COO and commercial seats operating, the CFO and CCO governing. Every specialist team underneath them is required to be its own self-contained Build-Operate-Govern cell, not a single-pillar unit that only writes code or only runs checks.

The DevOps team is the reference implementation, the one every new team is built to match. It carries a developer who writes and integrates code, an engineer who owns CI, monitoring and incident response, and a pair of first-line governors — a tester who checks feature quality and an analyst who checks delivery health, things like change-failure rate and whether the work matches what was actually asked for — coordinated by a single lead. Four roles, three pillars, one team. When the content team, the QA team and the finance team were each stood up as their own capability owners, they were built to the same shape: they draft, they run, and they check themselves, before any of it reaches a shared, central gate.

The practical effect is that governance is no longer something a central team performs on everyone else's work after the fact. It happens twice: first inside the cell, where the tester and the analyst catch what's wrong with their own team's output while the context is still warm, and second at the centre, where the standards get set and the final release gate lives. A central team checking hundreds of agents' output one by one does not scale; a hundred agents each checking their own team's output against a shared standard does.

A passed review is the authority to proceed — not a human

The mechanism that makes a fractal model actually move fast, rather than just look tidy on a diagram, is what happens between "someone had an idea" and "it shipped." Every piece of work in a BOG cell follows the same five-step arc: a seat designs it, a different seat reviews the design, the work is dispatched to be built, a different seat again reviews the finished build, and only then does it reach the one governance gate a human still holds — the release to production.

The detail that surprises people used to human organisations is the second word in that sentence: a different seat. Not a manager. Not an escalation. A passed review from a peer seat is the authorisation to proceed to the next stage — full stop. The designer does not wait on a human to say "go ahead and build this"; an independent review clears it, and building starts. This only works, and we say so plainly, on two conditions: the reviewer must not be the same seat that did the design work, and the reviewer has to actually verify the work rather than rubber-stamp it, because a rubber-stamp manufactures false confidence to build on, which is worse than skipping the review altogether.

We know why the human gate belongs at the release boundary and not earlier, because we found out the expensive way. A fleet session once shipped work to our staging environment without the review step firing correctly. It was git-reverted within the day, and the database migration attached to it was never applied to production, because the automated build fleet has no credentials to touch the live database — that step requires a separate, explicitly human-triggered release. The worst case of an autonomous cell moving too fast turned out to be a reversible commit on an internal branch, not a live incident. That is the actual argument for where the human gate sits: staging is cheap and reversible, so review-gated autonomy can run all the way up to it; production is not, so a human stays at that one door regardless of how clean everything below it has become.

Autonomy is earned in tiers, never switched on wholesale

A cell being allowed to review its own work is a different question from a cell being allowed to act on that review without a human watching. We keep those two things separate deliberately, because we tried collapsing them and it went badly enough to change the policy.

The default for every new capability is what we call propose-only: an agent can analyse a decision and recommend a verdict, but a human or a more senior interactive session has to actually execute it. Moving a class of work from propose-only to live-execute — where the agent's own review clears it to act, no human in the loop at all — requires clearing three specific bars, not a general sense that things are going well: the review gate has to be mechanically enforced, not just a convention agents are trusted to follow; the class has to show close to zero errors across at least twenty supervised actions; and there has to be a clean, genuine rollback path if something does go wrong. Miss any one of the three and the class stays propose-only, however capable the agents doing the work appear to be.

We set that bar after a single working session showed us exactly what happens without it. In one supervised run, an agent shipped code with type errors that had never been triaged, a coordinating seat asserted a commit hash that did not exist, and an automated co-sign acknowledged a task and then silently died without completing it. Every one of those was caught — not because the agents were reliable, but because a human was watching and a verification step ran. That is precisely the safety net live-execute removes, so we now grant it one tier at a time, worst blast-radius last. Content moves first, because content work is genuinely reversible — nothing it touches involves money, authentication or a live customer transaction — and because a team writing daily accrues a clean twenty-action sample faster than any other class of work. QA and testing tooling comes second, because it is read-heavy and rarely destructive. Engineering work that commits code to a shared repository comes last, because a single bad commit can block every other team working in the same tree, and that class only earns the same trust once the two lower-risk classes have proven the ramp actually holds up in practice.

The two boards that catch what a gate cannot

Mechanical gates are good at catching the thing you already knew to write a check for. They are useless against a genuinely novel architectural call, or a decision that spans more than one team's authority and has no obvious owner. Two standing boards exist for exactly that gap, and neither of them is a rubber stamp either.

The Architecture Review Board, chaired by the Lead Architect, rules on core-architecture and cross-layer changes before they ship rather than auditing them afterwards — every domain solution design passes through it on the way in, not the way out. The Escalation Board, chaired by the AI Co-founder, takes the calls that cross more than one seat's authority and cannot be settled inside either seat's own cell. Neither board's decision counts as final on one signature. A board-level ruling is only recorded as approved once both chairs have logged their agreement on the message bus, which means a single seat's word — or a relayed "the CEO said this was fine" with no traceable source behind it — is never sufficient on its own. That rule exists because it was tested and failed once: an internal audit found a large number of messages across our own bus asserting the CEO had authorised something with no verifiable instruction behind it, including an invented commission rate that briefly reached production before a human caught it. The full story of what we built to close that gap is in How We Stopped AI Agents Inventing the CEO's Decisions.

Why the model gets safer as it gets bigger

Most organisations get harder to govern as they add people, because oversight is a human bandwidth problem and headcount grows faster than any one person's attention. BOG inverts that relationship on purpose. Because every new team is built to the same three-pillar shape, adding a tenth capability does not add a tenth governance burden — it adds one more cell that governs itself first, using the same checks every other cell already runs, with the centre owning only the shared standards and the final gate. Scale, in this model, is measured in how much of the business a handful of humans can actually oversee, not in how many agents are running — a distinction we've written about at more length in The New Economics of the Tiny Team.

The one job that never ratchets away from the human is not enforcing any individual rule — a mechanical gate enforces faster and more consistently than a person ever could. It is owning which guardrails exist in the first place, making sure no cell can quietly weaken the one that is inconvenient to it, and confirming that every gate checks a real, queryable state rather than a claim that merely sounds like one. A perfectly enforced bad rule is worse than an imperfectly enforced good one, and the only seat that can tell the difference is the one that isn't graded on how fast the work ships. That is the actual argument for keeping a human on the release gate long after every cell below it has earned its own autonomy: not because the agents can't be trusted with the work, but because the rules that govern the work still need someone whose job is the rules, not the output.

Frequently asked questions

What does BOG actually stand for, and how is it different from an org chart? Build, Operate, Govern — a repeating three-pillar shape, not a list of departments. The org chart says who exists and who reports to whom; BOG describes what every team, at every level, actually does: it builds its own output, runs and monitors it, and checks itself against a standard before the work ever reaches a central gate.

Who actually holds the authority to approve work moving forward — a human or another AI seat? Both, at different points. A passed review from a different, independent seat is what authorises work to move from design to build, and from build toward release — a human is not consulted at every one of those steps. The human authority is concentrated at one place: the release to production, which stays a human-gated boundary regardless of how much autonomy a team has earned everywhere else.

How does a team earn the right to act without a human watching? By clearing three specific bars, not by general trust: the review gate that clears its work has to be mechanically enforced rather than a convention, its observed error rate has to be close to zero across at least twenty supervised actions, and a genuine rollback path has to exist if something goes wrong. Teams are moved to unsupervised execution one risk class at a time, safest first, never all at once.

What stops a team from weakening its own governance once it has more autonomy? The gates that matter are mechanical, not honour-system, and a human's remaining job is specifically to own which guardrails exist and confirm none of them can be quietly softened by the team they check. Two standing boards also rule on anything a single gate can't anticipate — the Architecture Review Board for architecture calls, the Escalation Board for cross-team decisions — and neither board's ruling counts until both chairs have recorded agreement on the message bus, so no single seat's word is ever enough by itself.