Most AI agent pilots don’t fail because the agent is bad. They stall because nobody has decided who approves what the agent does, or what happens when it gets something wrong. The model works, the demo lands, and then the project sits for weeks while three departments find out they each assumed someone else owned the answer.
What follows is a composite. It isn’t one client. It’s the sequence we see repeat, told as a single story about a 150-person professional services firm so you can see where the stall happens and why.
The demo went well, and that was the problem
The firm wanted an agent to handle the paperwork between a signed engagement and the first invoice. It would read the client’s email, draft a statement of work from past templates, create the project in the practice management system, and queue the first billing entry.
The demo ran on a sandbox with sample data. It produced a clean draft in under a minute. The managing partner said “ship it,” the operations director agreed, and everyone left the room believing the remaining work was integration.
Three questions arrived in week two, and none had an owner
To connect the agent to real systems, the IT lead needed a credential. The fastest option was the service account the team had used for the demo, which could read and write across the whole practice management system. Nobody was comfortable with that, but nobody had a better answer ready.
Then finance asked what happens if the agent queues an invoice with the wrong rate. Was that the agent’s error, the template’s, or the person who approved it? Legal asked a related question: if a draft statement of work goes out with a clause nobody reviewed, who signed off?
These weren’t obstructive questions. They were the ones the demo had skipped. The pilot was designed around what the agent could do, not around what it was allowed to do without a person looking.
Weeks of meetings produced a list, not a policy
By week five, the firm had a shared document with forty-odd concerns. Each was reasonable, and none was ranked. Some were really about identity (which account acts, with what permissions). Some were about approval (which actions need a human). Some were about audit (how anyone reconstructs a decision later). They were all treated as one pile called “risk.”
Without an owner, every concern had equal weight and no resolution path. The partner who sponsored the pilot didn’t want to decide approval thresholds alone. Finance wouldn’t approve anything it couldn’t trace. The pilot didn’t fail. It just stopped moving, which is harder to notice and harder to fix.
Unsticking it meant separating the questions, not answering them faster
The way out is to split that pile along the lines that matter. Identity first: the agent gets its own scoped credential, limited to the specific objects and actions its job needs. It can create a project record but can’t edit billing rates or touch other clients’ files.
Governance second: a written policy defines which actions run on their own and which wait for a named approver. Creating a draft project might proceed automatically. Queuing an invoice does not. An approval is attached to a role, not a person’s goodwill, so it still works when that person is on leave. We cover the ownership side in who should own the policy your AI agent enforces.
Audit third: every action is recorded against the policy that permitted it and the reason the agent gave, at the moment it happens. That’s what lets finance answer “why was this rate used” without asking anyone to remember. It’s also different from keeping application output, as we explain in why “we have logs” isn’t the same as an audit trail.
Starting with read-only access also shrinks the argument. If the agent can only draft and propose for the first weeks, the stakes of the first approval policy drop, and the firm can tighten or loosen it using real behavior. That’s the reasoning behind starting AI agents with read-only access.
In our deployments, this work happens before integration, not after the demo. The questions that stalled the pilot get answered on paper first, inside the customer’s own infrastructure, with the people who’ll live with the answers in the room.
Even with the questions separated, judgment is still required
None of this makes the decisions easy. Set the approval gate too loose and it becomes a rubber stamp: a reviewer clicking through fifty queued invoices a day isn’t reviewing anything. Set it too tight and the agent saves so little time that the pilot isn’t worth running.
Scoping is also imperfect. A credential narrow enough to be safe may be too narrow for edge cases, and the first month usually surfaces actions nobody predicted. Expect to revise the policy, and treat each revision as a recorded decision rather than a quiet tweak.
And some tasks should stay with people. If the cost of one wrong output is a damaged client relationship, an agent drafting for human review may be the right permanent design, not a stepping stone.
The question to sit with
If your agent pilot, or the one you’re considering, produced a wrong invoice or an unreviewed contract clause next Tuesday, could you name the person who approves that action, the credential it used, and the record that shows why? If any of those three needs a meeting to answer, that’s where yours will stall. A Book a diagnostic call conversation is a reasonable place to find out before the demo, not after.