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.

Patrick Eden
Updated
8 min read
agentic-aienterprise-aimcpgovernanceai-agents
The Gen AI Paradox: Why Agentic AI Stalls Before 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:

  1. Who is allowed to use this?
  2. What exactly may it do, on which records?
  3. What happens when it tries something it should not?
  4. Where does the data go?
  5. 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

  1. 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.
  2. 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.
  3. 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.

Patrick Eden

Patrick Eden

CEO & Co-founder at Palma.ai

Patrick Eden is CEO and co-founder of Palma.ai. He previously co-founded Replex, an infrastructure monitoring company acquired by Cisco in 2021.

Read More

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

Common Questions

Quick answers about Palma.ai's enterprise MCP platform

What is Palma.ai in one sentence?

Palma.ai is the enterprise governance layer for MCP — it gives every person and agent a single governed connector carrying the tools and Skills they're entitled to, enforces policies on the actual arguments of a call, pauses high-risk actions for approval, and records everything in a tamper-evident audit trail.

What does MCP governance mean?

Deciding which person may use which tool, with which arguments, with whose approval — and being able to prove it afterwards. MCP itself covers how a client authenticates to a server and how a tool is described and called; it does not decide which person may use which tool, hold a risky call for a human, or keep the record an auditor asks for. Palma adds that layer: one governed connector per person, assigned by identity-provider group, carrying the tools and Skills they are entitled to into whichever assistant they already use.

Does my team have to set up MCP servers themselves?

No. Connectors are assigned by IdP group through Entra or Okta, so a joiner gets theirs on day one and a leaver loses it the moment the group changes. Every MCP server your team approves arrives through that same connector — no per-user install, no config files, no credentials sitting on a laptop.

What's a Skill, and why does it matter?

A tool is a verb — "send an email". A Skill is the playbook that tells an agent when and how to use the verbs it already has: how your team actually closes the books, runs an incident review, or qualifies a lead. Skills are versioned, scanned before they're served, and scoped like any other piece of enterprise software — so your best operator's process reaches everyone else's agent.

Does it work with the AI clients we already use?

Yes — everything is served over MCP, so the same connector, Skills and policies follow the person into whichever assistant they open, whether that's Claude, ChatGPT, Copilot, Cursor or something else. Switching tools doesn't mean re-approving, re-installing or re-auditing anything.

How do we prove what an agent actually did?

Every tool call is attributed to the person it was done for, the agent that did it, and the application it ran in — with the arguments, result, duration and cost. The audit trail is tamper-evident and verifiable offline with your own key, so your auditor doesn't have to take our word for it, and it streams to the SIEM you already run.

How is Palma.ai deployed — SaaS, on-prem, VPC?

Palma.ai is designed for enterprise environments: typically VPC or on-prem, including fully air-gapped, depending on your regulatory and security needs. The MCP layer and governance plane run on your infrastructure, so sensitive business data doesn't have to move into multi-tenant SaaS. We can also host it for you if you prefer.