The Gen AI Paradox: Why Agentic AI Stalls Before Production
Most agent pilots never scale. The technology works; the pilot dies at the security review. What has to be true before an agent programme reaches production.

TL;DR
The "gen AI paradox" is that most companies have deployed generative AI and most report no effect on earnings. The usual explanation is that they bought horizontal chat tools instead of building agents for specific work. That is half of it. The other half is that the agent pilots that do get built die at the security review, because nobody can say who is allowed to let the agent do what. Fix that and the pilots ship.
The paradox, as McKinsey put it
In June 2025 McKinsey published Seizing the agentic AI advantage. Its opening finding was that nearly eight in ten companies reported deploying generative AI, and roughly the same share reported no material impact on earnings. They called it the gen AI paradox, and their explanation was that companies had spent on horizontal tools (copilots, chat assistants) that spread thin across everyone, while the vertical use cases that would move a specific P&L line rarely left the pilot phase.
Fifteen months on, the diagnosis holds. What I would add, from the conversations I have had with the people running those pilots, is that "rarely left the pilot phase" hides the actual failure mode.
Where the pilot actually dies
The vertical use cases are not hard to build any more. An assistant that reads a credit file from four systems and drafts the memo is a week of work for a team that knows the systems. The model is rarely the constraint. The pilot works, the team is pleased, and then it goes to the security review.
The review asks five questions:
- Who is allowed to use this?
- What exactly may it do, on which records?
- What happens when it tries something it should not?
- Where does the data go?
- Can you prove all of that afterwards?
A pilot built directly on an assistant and a few connectors cannot answer them. Everyone who can reach the connector can call everything it exposes. "Read a customer record" and "read every customer record" are the same tool. Nothing distinguishes the call that should have been approved from the one that was. The review says no, or it says "come back with a governance plan", which is the same thing on a longer timeline. That is the pilot phase most agent programmes never leave.
Why horizontal tools clear the review and vertical ones do not
This also explains the horizontal-versus-vertical split McKinsey observed. A chat assistant that can only read what you paste into it is easy to approve: it touches nothing. The moment an agent reaches a system of record, it has to be governed like a person reaching that system, and the assistant vendors do not provide that. So companies end up with the tool that is approvable and useless for specific work, rather than the one that is useful and unapprovable.
The way out is not to choose between them. It is to make the useful one approvable.
What has to be true before production
Here is what a security team needs to see, in the order they usually ask for it.
- Entitlement follows the person, not the pilot. Who may use which tool is decided by the groups people already hold in the identity provider. A joiner has access on day one; a leaver loses it on their last. No new list to maintain.
- Policy is evaluated on the actual call. This person, this tool, these arguments. A read on one record and a bulk read are different decisions.
- Risky calls wait for a human. Issuing a credit, changing a limit, sending to a customer: the agent proposes, a person approves, and the approval is recorded.
- Every call is logged in a form an auditor accepts. Who, what, when, why, and on whose approval.
- Cost is attributed. To the team whose work it was, so that in month six finance sees a line they can defend rather than a number they will cut.
None of this is exotic. It is what you already require of a person touching the same systems. The gap is that agents arrived through the assistant vendors, who govern the model and not the tools, and through the protocol, which authenticates a client to a server and describes tools, but does not decide which person may use which tool with which arguments.
Where Palma sits in this
We provide that layer. Each person gets one governed connector, assigned through their identity-provider group, carrying every tool and Skill they are entitled to into whichever assistant they already use. Policy, approval, audit and cost sit in that connector. The assistant does not change; the systems do not change; what changes is that the security team gets its five answers and the vertical pilot goes to production.
The earlier version of this article claimed more than that, including agent-to-agent orchestration we do not ship. This one claims what we do.
Three things to do this quarter
- List the pilots that stalled and ask why. If the answer is "security", the technology was fine and the governance was missing. Those are the cheapest wins you have.
- Pick one vertical use case with an owner who will defend a number. Not the most ambitious one. The one whose value per month somebody will put their name to.
- Take the governance plan to the review before you build. Entitlement by group, policy on arguments, approval on writes, an audit trail, cost by team. Get the yes first, then build to it.
If you want help with the first list, book thirty minutes. Bring the stalled pilots; we will tell you which ones are a governance problem and which are not.
Read More

Claude Code Source Leak: What It Reveals About MCP
512,000 lines of leaked TypeScript show how Anthropic builds multi-agent orchestration, plugins and permission-gated tool calling — and what it means for MCP.

ARISE Names the Runtime Layer. Here Is Where Palma Sits, Control by Control.
SACR published a framework for governing AI agents at runtime. We read it against our repo instead of our pitch deck. Sixteen of twenty controls are already ours. Four are not, and we say which — and why they are sequenced last.
Book a demo
See what governed AI agents look like.
A 20-minute demo on your stack. We'll show Palma working with the agents, tools and identity provider you already run.
- Enterprise security
- Role-based access
- Instant integration