Reviewing a Business-Built Mission Before It Goes Live

When the people who understand the work can build the automation themselves, the old approval queue disappears — and something has to take its place that protects quality without becoming the bottleneck it replaced.

A revenue operations manager spends three afternoons building something that, two years ago, would have been a quarter-long project with a ticket number and a waiting list. She has assembled a mission that watches the deal desk, reads incoming contract redlines, checks them against the approved pricing guardrails, drafts a response for the account team, and escalates anything unusual to a director. She knows this process better than anyone in the building, because she has run it by hand for six years, and the thing she has built works — it worked in the test account, it worked on last month's replayed deals, it did exactly what she meant it to do. Now it is Friday, and on Monday it is supposed to go live against real customers, real contracts, and real money. And the honest question, the one that should be asked before that switch is flipped, is not whether she is capable of building it. She plainly is. The question is whether anyone other than her has looked at what it is allowed to do when she is not watching.

That question used to answer itself, because the person who built the automation and the person who vetted it were different by definition. Engineering built it; a review process — sometimes heavy, sometimes ceremonial, always present — stood between the build and production. The whole appeal of letting domain experts build their own autonomous missions is that it collapses that separation, puts the tool in the hands of the person who actually understands the work, and stops routing every process change through a team that has to learn the domain before it can help. But collapsing the separation also removes the thing that separation quietly provided, which was a second set of eyes before something with real authority started acting on its own. The task now is to put those eyes back without putting the queue back — to keep the review and lose the bottleneck.

The gate is not the old approval queue wearing a new badge

It is tempting, the first time a business-built mission does something it shouldn't, to reach for the familiar remedy and route everything back through a central team. That instinct is understandable and almost always wrong, because it throws away the entire gain. The reason the domain expert could build the mission in an afternoon is that she did not have to translate her knowledge into a specification, hand it to someone who lacked it, and wait for them to build back an approximation of what she meant. Reinstating a gatekeeper who has to understand the pricing rules before they can approve the pricing mission simply recreates the translation tax in the review seat instead of the build seat. The waiting list comes back, the domain knowledge bottleneck comes back, and the organization has learned the wrong lesson from a single bad afternoon.

What the situation actually calls for is a different kind of review, one aimed not at whether the mission is built correctly — the builder is the domain authority on that — but at how it behaves at its edges, where domain expertise runs out and a different kind of judgment begins. A revenue operations manager knows precisely what a good contract response looks like. She may not have thought carefully about what the mission should do when the pricing system times out, or how much customer data it should be able to read to make its decision, or what happens the day someone points it at a customer segment it was never designed for. Those are not domain questions. They are questions about authority, exposure, and failure, and they are exactly the questions a lightweight review exists to ask. The point of the gate is not to re-verify the expert's expertise. It is to check the small number of things that expertise does not automatically cover, and then to get out of the way.

This distinction matters more as autonomous work spreads, because the failure mode the analysts keep flagging is not incompetent building — it is inadequate control around competent building. Gartner has predicted that over forty percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear value, and inadequate risk controls among the reasons. Inadequate risk controls is the one that bears directly here. An organization that lets a hundred domain experts build a hundred missions and puts no review between the build and production is not democratizing automation; it is distributing unreviewed authority across the business and hoping none of it misfires. A review gate is the risk control, and its absence is precisely the gap that turns a promising program into a canceled one.

Three things worth checking, and none of them is the code

A useful review of a business-built mission turns on three questions, and the discipline is in asking exactly those and resisting the urge to expand the checklist until it becomes the old approval process again. The first is authority scope: what is this mission actually permitted to do on its own, and where does its permission end? A mission that drafts a contract response for a human to send is operating under a very different grant of authority than one that sends the response itself, and a mission that can adjust a price is different again from one that can only flag a price for adjustment. The review does not need to second-guess the builder's logic; it needs to confirm that the boundary between what the mission decides and what a human decides sits in the right place, and that the decisions touching money, legal exposure, or a customer relationship land on the human side of that boundary through a genuine Human-in-the-Loop gate rather than a nominal one.

The second question is data access, and it is the one domain experts most reliably under-think, not from carelessness but because in their own work they have always had broad access and never had to reason about it. When a person reads a customer record to resolve a redline, their access is bounded by their attention and their working memory; they see one account at a time and forget most of it. A mission granted the same access is bounded by nothing — it can read everything it is permitted to read, retain it, and act on it at machine scale, which means the access grant that felt invisible for a human becomes a real question for the mission. The review asks what Enterprise Knowledge and which systems this mission actually needs to touch to do its job, and whether it has been given more than that. The correct scope is almost always narrower than the builder first reached for, not because they were reckless, but because they were thinking about the task and not about the blast radius.

The third question is failure handling, and it is the one that separates a mission that is safe to run unattended from one that merely looks finished. Every builder tests the path where things go right, because that is the path they are trying to create; far fewer think carefully about what the mission does when a system it depends on is unavailable, when the input is malformed, when it encounters a case outside anything it was designed for, or when it is simply uncertain. The review's job is to probe those edges — to ask what happens at 3 a.m. when the pricing service is down, whether the mission fails loudly and stops or fails quietly and guesses, whether an unfamiliar input triggers an escalation or a confident wrong answer. A mission that halts and asks for help when it hits the edge of its competence is safe to run unattended precisely because it knows where that edge is. One that plows ahead is dangerous in proportion to how much authority it was granted in the first question, which is why the three checks are really one check viewed from three angles.

Reviewing behavior, not building

The mental shift that makes all of this work is to stop thinking of the review as an inspection of an artifact and start thinking of it as an interrogation of a behavior. You are not reading the mission the way you would read code, line by line, looking for defects in construction; the domain expert who built it is a better judge of its construction than any reviewer could be. You are instead asking how this thing will act in the world once it has authority and no one is watching — how far its permission extends, how much it can see, and how it behaves when it meets something it does not understand. Those three properties are legible to a reviewer who knows nothing about the specific domain, which is exactly what makes the review lightweight and exactly what keeps it from recreating the bottleneck. A reviewer does not need to understand pricing to ask whether the pricing mission can send money without a human, and that is the whole trick: the questions that matter most are the ones a non-expert can ask.

An organization that internalizes this stops treating the review gate as a tax on citizen-building and starts treating it as the thing that makes citizen-building survivable at scale. The measure of a mature autonomous program is not how many missions the business has built, nor how few, but how reliably each one passed through a short, sharp check of its authority, its access, and its failure behavior before it touched anything real — a check fast enough that no one is tempted to skip it and pointed enough that it actually catches the things that turn a helpful mission into an incident. The right frame is not build versus approve, the old adversarial handoff between the people who make things and the people who guard the gate. It is builders who own the domain and reviewers who own the edges, meeting for the few minutes it takes to confirm that a mission built by someone who understands the work will behave itself in the moments no one is there to correct it. Keep that meeting short, keep it about the edges, and the gate stops being the bottleneck and becomes the reason the whole thing can be trusted to run.