{"slug": "the-five-walls-standing-between-a-demo-agent-and-a-deployed-one", "title": "The five walls standing between a demo agent and a deployed one", "summary": "SnapLogic's agent platform Jean-Paul, running on its integration fabric and the Model Context Protocol (MCP), faces five infrastructure challenges that stall enterprise agent deployments, according to a production system analysis. The obstacles include identity propagation, where agents must not self-assert identity but rely on trusted infrastructure to inject the human's canonical user ID, and physical data limits, where enterprise data exceeds context windows, requiring on-demand fetching rather than preloading. The article emphasizes that these are system problems, not prompting problems, and that access control is enforced at the MCP server boundary with group-based permissions and per-tool filtering.", "body_md": "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.\n\nIn 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](https://jean-paul.snaplogic.com/index.html) that runs on SnapLogic’s integration fabric and the [Model Context Protocol](https://www.infoworld.com/article/4029634/what-is-model-context-protocol-how-mcp-bridges-ai-and-external-services.html) (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.\n\nWhile 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.\n\nMCP gives you the right primitive to answer this. In the protocol, the agent is always the client, and every capability it has is exposed by an MCP server. That separation matters because it decouples what the model can do from what the model is. The agent never holds raw credentials to Salesforce or BigQuery. It holds a connection to a server that fronts those systems, and that server is where identity and authorization get enforced.\n\nThe key control point is when an agent’s tool access is assembled. In a well-designed system, this serves as a single enforcement point for each session: access starts at zero, and only the tools permitted by the user’s role are granted. The agent determines server access through group-based permissions, with each user’s available servers defined by the union of grants across their assigned groups. Users without group membership receive no access by default. A second control layer filters individual tools, removing unauthorized capabilities from the model’s context before the session starts. This strengthens security and improves efficiency, as models perform better when selecting from a smaller, role-appropriate toolset.\n\nThe hard part is identity propagation. The agent must never be allowed to self-assert its identity. Instead, trusted infrastructure injects the human’s canonical user ID as a transport header that the agent cannot forge, and privileged servers re-check authorization against that header on every call, ensuring that access to a server is necessary but never sufficient. This is also where the integration platform earns its place as the system security layer. The vendor serves as the trust layer, securing credentials, enforcing authorization policies, and propagating user identity so downstream actions execute with the user’s permissions rather than a shared service identity. In practice, most deployments begin with a governed shared service identity at the agent’s MCP boundary and move toward per-user impersonation as the integration layer matures, but the boundary is in the right place from day one.\n\nThe second wall is physical. Enterprise data dwarfs any context window. You cannot paste a two-thousand-table warehouse schema into a prompt, and an agent that tries will exhaust its context before it answers anything.\n\nBigger models help, but do not solve it. A million-token context buys headroom, not infinity. The real answer is architectural: never preload, always fetch on demand**.** MCP is well-suited to this because the tools return only the requested slice.\n\nThe pattern that makes it scale is an index-and-leaf design. A one-time discovery pass introspects a system and writes a queryable metadata index — one entry per table, object, or routine — into a context library. At query time, the agent browses the index (cheap, a line per object), fetches the full schema for only the handful of objects in play, and then queries the live data. The context window holds index lines plus a few schemas, never the warehouse. The addressable surface is bounded by the database, not by the model.\n\nTwo more techniques help to carry the load. First, work that exceeds a single context is fanned out: a job over 10,000 records is split across many bounded-context sub-processes or a batch API and reassembled, rather than forced through one window. Second, large files are handled out-of-band, generated by code through ordinary libraries, written to disk, and delivered as a hosted URL, so the bytes never enter the model’s context at all. To be precise, the conversation-level mechanics of context compaction and prompt caching come from the model runtime, not the application. The platform’s job is to instrument them for cost accounting and to architect the workload so the window is rarely the binding constraint.\n\nReading data is reversible. Taking action is not. This is where most teams either over-restrict the agent into uselessness or quietly accept unacceptable risk. The key point is that you cannot enforce safety in the prompt. “Please ask before deleting anything” is a suggestion a sufficiently confused model can be argued out of. Safety has to live in a deterministic infrastructure that the model cannot reason its way past.\n\nA permission prompt that protects a human at a terminal is unusable in a Slack bot; something deterministic must replace it. An agent should layer four such gates. A visibility layer means the agent can’t invoke what it can’t see. A hard deny list embedded in the image and enforced regardless of interactive permissions creates a model-agnostic blacklist: no reading secrets, no destructive shell commands, and no editing the very files that define its own guardrails. An invocation policy cascade resolves each tool call to allow or deny by scope and specificity. And a set of independent preconditions can require, for instance, that the agent has read the relevant schema before it is allowed to write.\n\nThe human-in-the-loop gate is the clearest illustration of enforcement at the tool layer. A pre-execution hook intercepts a sensitive call before it runs, writes a pending-approval row, posts an interactive card to the user’s Slack or Teams channel, and then blocks — polling a database latch until a human clicks Approve or Reject. The tool call is physically suspended until the hook’s exit code returns the verdict. The model is not being asked nicely to wait. It is gated. This same mechanism enforces softer policies as hard rules: an agent can be made unable to publish a document until it has demonstrably read the brand guidelines, by requiring a prior read of that file as a precondition for the publish tool.\n\nThese gates are tuned to fail open on their own internal errors (an availability choice that keeps a hook bug from bricking the whole agent) while failing closed against the loss of their policy store. Where you set that dial is a real decision, and pretending the gates are infallible is exactly the kind of overclaim that erodes the trust the gates are meant to build.\n\nReal enterprise work is multi-step, multi-turn, and long-running. Chat channels are effectively stateless. A new message in Slack carries little reliable context about whether it represents a new request or a continuation of prior work. An agent that treats every message as a fresh start is amnesiac.\n\nA solution to this can be smart routing: put a small, fast, cheap model in front of the expensive agent purely as a dispatcher. For a fraction of a cent per message, it decides whether an incoming message should resume an existing session or start a new one, and which prior session is the relevant one, converting stateless chat into resumable, stateful work. A concurrency guard prevents two processes from writing to the same session at once. A useful discipline when building this is to be conservative. When the router is unsure, start fresh, because a clean context is cheaper to recover from than a corrupted one.\n\nComplexity is managed by delegation. The agent runtime lets the main agent spawn sub-agents with isolated contexts. The platform’s contribution is not the isolation itself but the judgment of when to delegate, which is encoded in the platform’s skills. This keeps the coordinating agent’s context focused on the plan while bulk or parallelizable work happens in separate windows.\n\nThose skills are the agent’s standard operating procedures. A skill is a versioned, reviewable document that encodes a repeatable procedure. It tells the agent what references to review, which tools it can use, how the output should be structured, and how to verify its own work before returning a result. Skills load progressively (only a short description is always in context; the full procedure is read when triggered), and they move through a submit-review-approve life cycle. This is what turns agent behavior from improvisation into something repeatable and auditable. Underneath, a durable substrate ties the pieces together: a session identifier is the join key across the model’s transcript and the orchestration ledger, and an unfinished job left marked “running” after a crash becomes a recovery queue that the system drains on restart.\n\nThe last wall is the tallest, and not technical. Industry surveys indicate that the large majority of generative AI pilots deliver no measurable return and only a small fraction at scale. People will not delegate real work to a black box, and leadership will not sanction one.\n\nExplainability has to be a built-in primitive, and not a debugging afterthought. Every tool call an agent performs (its name, the system hit, its inputs, its response, success or failure) should be logged. Your agent must do this and then close the loop in the conversation itself: when a session ends, a hook automatically posts a “here’s what I did, and here are the sources” summary back into the same thread, with a deep link to the full transcript, and configuration changes are captured in a separate before-and-after audit. Attribution must be mechanical rather than a matter of trust. Output honesty — the agent not inventing a number — must be enforced by explicit guardrails in the system prompt plus the after-the-fact audit trail, not by an automatic citation-checker that blocks unsourced claims. The audit log is what lets you verify, which is the point.\n\nTwo softer factors matter more than engineers like to admit. First, a distinct agent personality measurably drives engagement — provided the persona governs *how* the agent communicates and never *what* it communicates, with factual honesty fenced off as non-negotiable. Second, adoption hinges on a single, low-friction surface: people talk to the agent in the tools they already use, while one dashboard unifies history, skills, hosted deliverables, personalization, cost, and governance. Each tool is labeled by its risk, so personalization itself communicates consequence.\n\nThe deepest issue is structural, and it predates AI. [Eric von Hippel](https://en.wikipedia.org/wiki/Eric_von_Hippel)’s decades of research on user-driven innovation describes sticky information — knowledge about how work actually gets done that does not survive translation into a requirements document. Most enterprise AI stalls because the people who hold that context are not the people allowed to build. The durable pattern is to invert that: let the people with the context author the workflows, governed end-to-end. AI is the means; governance is the foundation, not a wrapper bolted on afterward.\n\nNone of these obstacles is a model capability problem, so simply throwing a bigger model at them does not help. They are problems of authorization, scale, safety, state, and trust, and each is solved the same way: keep control in deterministic infrastructure around the model, bind every action to a real human identity through an integration layer that holds the credentials, make everything auditable by default, and put authoring in the hands of the people who understand the work. The model is the easy part. The enterprise is the hard part.\n\n*—*\n\n*New Tech Forum*** provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all ****inquiries to *** doug_dineley@foundryco.com***.**", "url": "https://wpnews.pro/news/the-five-walls-standing-between-a-demo-agent-and-a-deployed-one", "canonical_source": "https://www.infoworld.com/article/4209927/the-five-walls-standing-between-a-demo-agent-and-a-deployed-one.html", "published_at": "2026-08-20 09:00:00+00:00", "updated_at": "2026-08-20 09:14:12.755037+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "ai-safety", "ai-policy"], "entities": ["SnapLogic", "Jean-Paul", "Model Context Protocol", "Salesforce", "BigQuery"], "alternates": {"html": "https://wpnews.pro/news/the-five-walls-standing-between-a-demo-agent-and-a-deployed-one", "markdown": "https://wpnews.pro/news/the-five-walls-standing-between-a-demo-agent-and-a-deployed-one.md", "text": "https://wpnews.pro/news/the-five-walls-standing-between-a-demo-agent-and-a-deployed-one.txt", "jsonld": "https://wpnews.pro/news/the-five-walls-standing-between-a-demo-agent-and-a-deployed-one.jsonld"}}