There's a version of the enterprise AI story where the hard part is the technology. You pick the model, you prove it works, and the rest is rollout. Our Chief Customer Officer, Nadia Rieben Gertenbach, has overseen more than 200 production deployments, and in our recent webinar she made the case that this version is almost exactly backwards. The technology is usually the easy part. What decides whether an enterprise AI deployment scales is the organization around it, and the places it goes wrong are predictable enough to name.
Here are three of them
The bottleneck is the organization, not the model.
When a deployment runs slow, the instinct is to look at the technology. Is the model accurate enough? Is retrieval good enough? Almost never, in Nadia's experience, is that the real constraint. Projects stall on stakeholder alignment over what "value" even means, on data-ownership disputes, on governance approvals, on security reviews, and on the plain question of whether people will actually use the thing.
Her summary is blunt: "The biggest blockers we see aren't model accuracy. They're organizational readiness, governance, and decision-making." That reframing matters because it changes who needs to be in the room. Staff an enterprise AI deployment as a purely technical project and you will be surprised, months in, by how little of the delay had anything to do with engineering. The teams that move fast treat alignment, governance, and adoption as the actual work, not as overhead attached to the real work.
A successful pilot is not a successful rollout.
Plenty of organizations run a pilot that works. Far fewer achieve a full rollout across the business, and the gap between those two is where most enterprise AI quietly stops.
The reason is that deployment and adoption are not the same thing, and only one of them creates value. In delivery, the question clients ask most is how quickly an agent can be implemented. The better question, Nadia argues, is how quickly the organization can adopt it, because an unused AI agent provides zero business value, however good the technology behind it. The distance from "it works" to "people rely on it" is covered by change management and trust, not by model performance. Leaders who budget for the build and not for the adoption are funding the half of the deployment that doesn't, on its own, produce a return.
The winners have the most reusable foundation, not the most agents.
This is the one that reframes the whole strategy. The instinct, once AI starts working, is to accumulate: a new tool for each new problem, often from a different vendor each time. It feels like progress. But each of those tools arrives on its own foundation, with its own integrations, its own security review, and its own copy of the data, and none of them talk to each other. What looks like a growing capability is really a growing pile of disconnected point solutions.
Without a shared foundation, every new initiative rebuilds the same things from scratch: the integrations, the security reviews, the governance documentation, the access controls, and the knowledge structures. Nadia calls it an implementation tax, and it recurs with every isolated project. A shared foundation is what stops the meter running. The second deployment reuses the connectors, the approved governance, the established security model, and the organizational trust the first one earned, so it feels less like a new project and more like extending a capability you already have.
The proof shows up across real deployments. One central bank we work with completed a successful proof of concept for a second division, then deliberately put it on hold until the first use case was fully deployed, specifically to inherit those synergies rather than pay the tax twice. At a European industrial manufacturer, the foundation built last year is now about to carry its fourth use case on the same infrastructure. At another, three use cases went live within a single year, with more scoped behind them. As Nadia put it: "The organizations that win won't have the most AI agents. They'll have the most reusable AI foundation."
What this means for your next AI decision
The thread running through all three is the same. Enterprise AI is no longer a question of capability, since the answer to "can AI do this?" is now, reliably, yes. It's a question of operational readiness: can you govern it, adopt it, and scale it without rebuilding the foundation every time? Most organizations are still structured around the old question, and it shows up as stalled pilots and rising costs.
The organizations getting it right start where the business pain is real, prove the value quickly, and build so that the second deployment inherits the first one's foundation instead of starting over. As Nadia's staging puts it, deployment one builds the foundation, deployment two reuses it and feels completely different, and by deployment three you are activating a new business capability rather than running a complex project.
That principle is what shaped our Agent Catalog: a set of proven starting points, each mapped to a specific business problem and each built on the same shared foundation, so that every agent you deploy makes the next one faster to adopt. You start where the value is clearest, and the foundation you build carries forward. You can explore the catalog and the full adoption map at squirro.com/agent-catalog.
This is one thread from a wider conversation. In the full webinar, Nadia goes deeper on what separates a successful pilot from a scaled capability, our CTO Saurabh Jain takes apart the architecture that lets a foundation carry forward, and Domenico Le Pera explains why so many initiatives stall before production.
Watch the full session on demand here.
