A standing AI governance body built before the first failure invents work everyone routes around. Wait for the same failure twice, name it, then decide if a structure is the fix.
By JP LeBlanc
No, not yet, and probably not in the form you're picturing. The standing AI enablement team, the Head of AI, the governance council that reviews every agent rollout: almost none of these should exist until the same failure has happened two or three times and you can name it out loud. Most of them get built before the first failure, on the theory that risk this new deserves a structure ahead of time. That instinct is backwards. A structure built ahead of the failure it exists to prevent invents work, and the work it invents is exactly the process everyone downstream learns to route around.
Nothing about AI is exempt from the same test that decides whether anything else in the org gets a new structure: has the same failure happened twice. Career ladders wait for the same fairness argument to surface two or three times before anyone writes one down. New process waits for the same failure to repeat before it gets codified. Process, generally, accumulates the way code does and gets removed far less often, which means the bar for adding a new piece of it should be higher than it feels in the room where someone's proposing it, not lower just because the subject is unfamiliar.
An AI council proposed in the abstract, before any specific incident, is a structure with no failure to point to. Ask the person proposing it what it would have caught last quarter. If the honest answer is nothing, because nothing had gone wrong yet, you don't have a case for a council. You have anxiety about a category of risk, which is a real thing to feel and not the same thing as a mechanism.
A body created ahead of the failure it exists to prevent doesn't sit idle waiting for a problem to arrive. It generates review, because that's what committees do to justify their own existence, and the review it generates attaches to whatever's easiest to require rather than whatever's actually risky. Every agent deployment needs council sign-off, regardless of whether the change is a documentation fix or a schema migration. The council can't tell the difference at the volume agents produce, so it either rubber-stamps everything, which makes it theater, or it becomes a queue, which makes it the new bottleneck, in a different building than the one you already have.
The case for the council is always that the risk is too high to leave ungoverned, and that some standing body has to hold the line while the tooling matures. At CircleCI, when agents earned the right to merge to main without human approval, the call on when a class of change could move up a tier sat with the principal and senior staff engineers who owned that piece of the platform. Not a council. Not an AI governance body. Not me. The risk was never that nobody was watching. It was that a body built to watch in the abstract can't tell a routine change from a dangerous one any better than the org chart it's sitting on top of already could, and it adds a queue on top of an org chart that didn't need one.
Every rule of thumb about who owns a decision already exists in the org chart: the person or team accountable for a system is the person or team who should decide how much autonomy an agent gets touching it. That's not a new principle invented for AI. It's the same one that already governs who signs off on a schema change, who's on call for a service, who gets asked before a breaking API change ships. Agent governance isn't a new category of decision. It's the same decision, made about a new kind of author, and routing it through a new body is how you end up with two decision paths for the same question and no way to tell which one actually holds.
A platform team justified by a recurring, named pain earns its headcount the same way any structure should: the pain existed first, twice, and the team was the answer to it. An AI council built preemptively skips that test entirely, and skipping it is the whole problem. It isn't that governance is unnecessary. It's that governance already has an owner, and building a parallel one dilutes the real one instead of reinforcing it.
None of this means never build anything. It means wait for the failure, then build the smallest thing that answers it. If two teams independently ship agents with autonomy that turns out to be wrong for the same underlying reason, that's worth a shared standard, written down, owned by whoever's closest to the actual mechanism, not a rotating committee. If the same kind of incident recurs across teams that don't talk to each other, that's a case for a shared review checkpoint, not a permanent council with a headcount line.
The test is identical to the one that governs a hard conversation: the second occurrence is a pattern, the first is an incident, and building for the fifth before you've had the second is cowardice with a process attached. Name the failure. If you can't, you don't have the case yet, no matter how uncomfortable the uncertainty feels in the meantime.
Most AI councils don't exist to solve a problem. They exist to make a room feel like it's done something about a risk nobody can fully describe yet. That's a real need, and I'm not dismissing the discomfort that produces it. But a structure built to manage a feeling doesn't hold up the first time it meets an actual incident, because it was never designed against one.
Wait for the failure. Name it. Then decide whether a structure is the fix, or whether the fix was routing the decision to the owner you already had.