Which process should your first AI agent pilot actually test?

Not the process. The team's ability to see what the agent did, catch it when it's wrong, and say who signed off on trusting it more. Pick a bounded, low-stakes process — one where a bad output is visible and cheap to reverse — and use it to build the three things that actually decide whether you can scale: traceability, review checkpoints that flex with the stakes, and a named owner for the promotion decision. Get those working on something boring first. The close and the regulatory filings can wait for pilot two.

Why does the first pilot matter more than the tenth?

Because it's the only one you'll build with nothing riding on the outcome. By the time you're picking the fifth or sixth process, you already have habits — a review cadence, an escalation path, an assumption about how much to trust the model's confidence score. Those habits get set on whatever you happened to build first, whether or not it was the right thing to learn from.

Gartner made this explicit for CFOs on August 20: the recommendation isn't "run a pilot to prove ROI," it's "use the first agent to test your governance framework before you scale it into higher-stakes work." The trade press covering it in the days after landed on the same read from different angles — a set of four governance frameworks finance teams are actually running, a piece on why the accountability question, not the technology, is what keeps agents stuck at pilot stage. The framing is converging: the pilot's job is not the automation, it's proving you can supervise one.

What makes a process a good first pilot?

Four properties, all checkable before you write a line of code:

• Clear boundaries. The agent's inputs and the systems it can touch are enumerable, not open-ended.
• Repeatable steps. The same shape of decision recurs often enough that a review sample means something after two weeks, not two quarters.
• Verifiable outputs. A person can confirm the agent got it right by checking it against a source document — an invoice, a PO, a bank statement — not by trusting the model's own explanation.
• Reversible errors. If it's wrong, the fix is a correction, not a restatement, a regulatory filing, or a call to legal.

Invoice matching, AP exception routing, and intercompany reconciliation all clear this bar. The close doesn't — not because AI can't touch it eventually, but because it's the wrong place to discover that your review process has a gap.

What does "governance" actually mean, in something you can point to?

Three artifacts, not a binder:

Traceability. For any run, you can reconstruct what the agent accessed, what it decided, and why — not "the model said so," but the specific inputs and rule that produced the output. This is the piece teams skip first, because it doesn't show up in a demo. It's also the piece an auditor, or a CFO six months later asking "why did we approve this," will actually ask for.

Review that scales with stakes. A routine case clears with one reviewer glancing at a summary. An unusual one — a new vendor, an amount outside the normal range, a mismatch the agent flagged as uncertain — gets two, and a documented reason. The point isn't reviewing everything; it's that the depth of review is a decision you made on purpose, not whatever the tool defaulted to.

A named owner for the promotion decision. Someone specific decides when the pilot moves from "every output reviewed" to "spot-checked" to "runs on its own for this class of case." Not a committee, not "the vendor recommends." If nobody with real authority is willing to put their name on that decision, the agent stays parked at pilot stage indefinitely — which is exactly the failure mode Gartner is describing, and it isn't a technology problem.

How do you actually build those three things, not just decide you want them?

This is where the pilot stops being a decision and becomes an engineering problem, and it's the part most governance write-ups stop short of. In practice it looks like running the agent in shadow mode first — real inputs, no output reaching production — then human-in-the-loop, where every action needs a click before it lands, before anything runs on its own. Each stage produces the traceability and the review record as a side effect of how it operates, not as a separate compliance task bolted on afterward. We've written the mechanics of that staged rollout — and the three numbers that tell you when to move to the next stage — for automation generally; the governance question CFOs are being asked this month is really the finance-specific version of the same discipline, applied to the process you pick first.

What's the mistake to avoid?

Picking the first pilot by expected savings instead of by how safely it lets you fail. The process with the biggest dollar number attached is usually not the boring, bounded, reversible one — which means optimising for ROI on pilot one is exactly how you end up building your governance habits on a process where a mistake is expensive to have made. Save that process for pilot three, once the review cadence, the traceability, and the sign-off owner are already working somewhere it didn't matter if they weren't, yet.

If you want help picking which of your own processes clears this bar before you commit an engineering quarter to it, the free AI Audit maps your processes and flags which ones are actually bounded, repeatable and reversible — the traits that make a first pilot worth running. Prefer to talk it through? Book a call.