Building an AI agent that looks impressive in a demo is now a weekend project. Building one that an enterprise will actually let touch its CRM, its data warehouse, and its customers is a different discipline entirely — and almost none of the challenges associated with shipping an agent live in the model. The challenge is infrastructure around the model, including who it is allowed to be, what it is allowed to see, what it is allowed to do, how it keeps its place across hours of work, and whether anyone trusts the result. These are system problems, not prompting problems.
In this article, I will introduce the five obstacles that reliably stall enterprise agent projects, and the architectural patterns that solve them. The examples come from a production system: an agent platform called Jean-Paul that runs on SnapLogic’s integration fabric and the Model Context Protocol (MCP). But the lessons are meant to apply broadly. If you are building in this space, you will hit all five walls regardless of your stack.
The authentication wall
While demo agents authenticate with a single god-mode API key, enterprise agents cannot, because security teams need to understand who the agent is acting on behalf of and what it is allowed to access.
