There's a stat making the rounds: 80% of enterprises now have at least one AI agent running in production. Sounds impressive until you read the fine print. Only 31% have an agent that's actually scaled beyond a pilot. And 88% of AI agent projects never make it to production at all.
That gap between "we have a demo" and "this runs in production at scale" is exactly the kind of problem I spend my days on as a TPM. The technology works. The deployment doesn't. It's a coordination, governance, and integration problem dressed up as a technology one.
Why agents stall at pilot
The number one blocker, cited by 46% of orgs in a recent survey, is integration with existing systems. That tracks with what I've seen. An AI agent that can answer customer questions in a sandbox is impressive. An AI agent that needs to authenticate against your identity provider, pull data from three internal APIs with different auth models, write back to a system of record, and handle failures gracefully without losing state - that's a different beast entirely.
The second blocker is governance. Only one in five companies has a mature model for governing autonomous AI agents. Who's responsible when the agent makes a bad decision? What's the rollback path? How do you audit what it did? These aren't hypothetical concerns. In regulated industries like finance and healthcare - which are exactly the industries Citrix DaaS serves - you can't deploy an autonomous agent without answers to all of these.
Third is the trust problem. Agents that work 95% of the time sound great until you realize that 5% failure rate, spread across thousands of daily actions, means dozens of bad outcomes per day. For enterprise use cases, you need the failure mode to be "ask a human" rather than "do the wrong thing confidently."
What the winners do differently
The orgs that get agents to production share a few patterns:
They scope brutally. Instead of building a general-purpose agent, they pick one narrow workflow and make it bulletproof. Ticket routing. Refund processing. Infrastructure provisioning requests. One thing, done well, with clear boundaries.
They treat it like any other service. SLOs, error budgets, on-call rotations, runbooks. The agent gets the same operational rigor as a production microservice. Because that's what it is.
They build the human-in-the-loop path first. Before the agent can act autonomously, it goes through a phase where it recommends actions and a human approves. This builds confidence in the system and catches edge cases the training data missed. Only after the approval rate hits a threshold do they remove the human from the loop - and even then, only for low-risk actions.
The TPM angle
From where I sit, AI agent deployment is a program management problem. You have multiple teams that need to coordinate: the ML team building the agent, the platform team providing the runtime, the security team reviewing the access model, the product team defining the scope, and the ops team that will own it once it's running. Each has different timelines, different risk tolerances, and different definitions of "done."
It's dependency management all over again. The agent can't launch until security signs off. Security can't sign off until they understand the data flows. Data flows can't be documented until the integration work is done. The integration work depends on API access from a team that has other priorities.
Sound familiar? It should. The tools are new. The coordination challenges are exactly the same ones TPMs have always dealt with. The difference is that the stakes of getting it wrong are higher - an agent that goes off the rails can do damage at machine speed.
Where I think this goes at Citrix
DaaS is ripe for AI agents. Capacity provisioning, incident triage, session troubleshooting, image management - there's a ton of operational work that follows patterns an agent could learn. We're already using ML for predictive scaling. The next step is agents that can execute remediation, not just predict problems.
But I'm not rushing it. The "88% never make it to production" stat exists for a reason. Better to ship one agent that reliably handles tier-1 support tickets than to demo five agents that fall apart under real-world conditions.