AI Governance Should Buy You Speed

Use evidence to decide where an agent can act with less review.

The delivery-support pilot now has a bottleneck: every internal follow-up task waits for approval. The pilot belongs to the hypothetical B2B technology company used throughout this series. The agent's mandate allows internal follow-up tasks when defined checks pass, but the pilot started more cautiously, with a person approving each one. The same reviewers also approve changes to what the company has promised customers, so a routine request to chase engineering about a dependency waits in the same queue as a decision about a customer's delivery date.

The delivery owner wants to know whether the task approval can come off. Approval on changed commitments stays regardless.

What the approval step is buying

Before removing an approval step, write down what the reviewer catches. Here, a reviewer looking at a proposed task checks that it belongs to the right account, lands in the right project, isn't a duplicate, and has a sensible assignee. If the system reliably performs those checks, the review may be duplicating them. Before removing it, I would check whether reviewers also catch exceptions the automated checks miss.

That turns a vague question about how autonomous the agent should be into a specific question about evidence. Governance saves time here only by showing which checks no longer need a person. Some approvals, like the one on changed commitments, are worth their cost even if they never get faster.

Counting the right things

The agent's message that it created a task is a claim. The evidence is the task itself, in the right project, with the right content. Anthropic's guidance on evaluating agents makes the same distinction between what an agent reports and the state it leaves behind: an agent can say a flight is booked, and the test is whether the reservation exists.

Every eligible attempt belongs in the count. Report verified successes, verified failures, and unverified outcomes as three separate numbers. If a review quotes a success rate among verified cases only, it should show how many cases were left out. Missing verification should never make performance look better.

The test cases that matter are the ones likely to cause trouble: conflicting or stale dates, an account linked to the wrong project, a tool call that fails and creates a duplicate on retry, an instruction hidden in a retrieved document, an unavailable reviewer, and any change to the model, prompt, or tools. A few good demonstrations tell you very little.

What the first review found

In this example, the first review was most useful for what it exposed. One approved task landed in the wrong project. The reviewer approved the proposed task but missed that the account-to-project mapping was stale, a reminder that approval is fallible too. The mandate already required a check that the destination project belongs to the account. The first implementation didn't enforce it correctly, and nobody had tested it. Writing the check into the mandate had not made it work. The team corrected it. A retry after a timeout created a duplicate task, and the retry logic was fixed.

Both fixes changed the system, so the earlier results describe a configuration that no longer runs. Few cases have run on the current one. Some cases still have no verified outcome. The unavailable-reviewer path was exercised once. Nobody has totaled the cost per completed task, including review time. And removing a wrong task isn't a full recovery: the assignee may already have been notified, and a linked automation may already have run.

I would hold. Approval stays on task creation while the team re-runs the test cases on the current configuration, verifies the open outcomes, tests the unavailable-reviewer path properly, and writes down what recovery involves. The team should evaluate the corrected configuration first. To estimate the effect of removing approval, it can then compare cases on that same configuration with and without the approval step, where practical.

Once the corrected controls pass their tests, I would consider a capped trial without per-task approval: named projects, a case limit, sampled review, and explicit stop conditions. Those limits would bound the experiment; they would not replace testing the known failures first.

Holding is a useful result. The review produced a short, specific list of work, and if the re-run holds up, the team can remove the click on the strength of evidence. If a wrong-project task turns up afterward, the approval goes back on. Removing approval from task creation also grants nothing else: the agent's authority over customer communication is unchanged.

Keeping the review proportionate

This could become one more compliance process. The safeguard is to reuse the identity, change, and incident controls the company already runs. Compare the evaluation and monitoring costs with the approval effort they could save over a realistic operating period. If the savings do not justify the work, keep the approval. Required risk and incident reviews still apply.

At the next steering meeting, I would take one approval step at a time and ask what it catches, how long work waits for it, and what evidence would let us retire it. For internal follow-up tasks, that evidence is within reach. For a changed promise to a customer, I would keep a person in place.

For more worked examples like this one, subscribe to Uncharted.