If you've been around long enough to remember when iPaaS was the answer to everything, you know the pattern. New paradigms arrive. Someone realizes that wiring it into existing infrastructure is harder than the demos suggested. An integration layer gets built. That layer slowly becomes load-bearing. Eventually, the integration layer becomes the bottleneck.
We're at that moment again — except this time, the new paradigm is agentic AI, and the bottleneck is forming faster than usual.
iPaaS — Integration Platform as a Service — was built for a world of deterministic applications. The mental model is simple: you have systems, they have APIs, and iPaaS connects them. Data flows from point A to point B according to rules you define. If the invoice system updates, notify the CRM. If a customer signs up, trigger the onboarding workflow.
That model is elegant, and it works. For applications.
Applications are deterministic. They do what you programmed them to do. They expect specific inputs, produce specific outputs, and fail loudly when something unexpected arrives. iPaaS is designed around that contract.
Agents are not deterministic. They reason. They explore. They choose their own path through a problem space. They don't know in advance what data they'll need, in what sequence, at what point in their reasoning chain. They may need to pull context from five different sources mid-thought, then discard most of it and start over.
The integration pattern that works for an invoice workflow is exactly wrong for an agent.
**1. Batch orientation vs. real-time context requirements.**
Most iPaaS workflows run on schedules. Every hour, every night, every week — data gets extracted, transformed, and loaded somewhere else. The latency is acceptable when the consumer is a dashboard someone checks in the morning.
Agents don't check dashboards in the morning. They reason against the data they have at the moment they need it. A two-hour-old record isn't approximately right — it's a confident hallucination waiting to happen. Agents don't know when their data was last refreshed. They'll reason clearly from stale premises and deliver wrong answers with full grammatical confidence.
**2. Rigid schema contracts vs. adaptive data consumption.**
iPaaS enforces structure. Data arrives in a defined shape, transforms according to a defined mapping, and exits in another defined shape. Break the contract anywhere in the chain, and the integration fails.
Agents don't consume data according to fixed contracts. They interpret it. A change in field naming, a new optional attribute, a slightly different response structure — these are things an agent can reason through. But if a brittle iPaaS layer breaks before the data ever reaches the agent, the agent never gets the chance.
**3. Latency stacking vs. decision loop requirements.**
Agents work in tight reasoning loops. Perceive, think, act, observe, repeat — and the loop needs to be fast. Every integration hop adds latency. While small delays are barely noticeable in traditional applications, they severely impact an agent's reasoning loop, which is the difference between a functional workflow and a broken one. Furthermore, constant loops in reasoning might impact rate limiting, increase costs, and extend processing time. iPaaS wasn't designed for the low-latency context retrieval required at reasoning speed; it was designed for reliable eventual delivery. Those are different things.
Gartner identifies the emerging successor to iPaaS as the **Context Mesh**. The name is deliberate: it's not a pipeline, it's a fabric.
Where iPaaS moves payloads between endpoints, a Context Mesh makes context continuously available. The distinction matters more than it sounds.
In an iPaaS model, data flows in response to events: something triggers a workflow, data moves. In a Context Mesh, data and state are *ambient* — always present, always current, always queryable by any agent that has permission to access them.
**Real-time event streaming** replaces batch processing. Instead of running a sync every hour, state changes propagate immediately — through Kafka, Pub/Sub, or similar event infrastructure. The agent's view of the world is always current.
**Hybrid connectivity** pairs two protocols: the Model Context Protocol (MCP) for dynamic data discovery, and traditional REST/gRPC APIs for taking definitive actions. MCP lets agents explore available context at runtime — they can ask what data exists and how to get it, without hardcoded knowledge of every endpoint. Traditional APIs handle the actions: create this record, trigger this workflow, send this message.
**Outside-in design** replaces inside-out. The old way: look at the database, expose an endpoint, hope the consumer figures it out. The new way: start with the agent's goal. What context does it need to succeed? At what latency? In what format? Build the integration layer around the agent's requirements, not your database's structure.
**Semantic caching** reduces redundant retrieval. Agents ask the same kinds of questions repeatedly. A Context Mesh is semantic aware and can recognize semantically similar requests and serve cached context rather than hitting upstream services on every reasoning cycle.
If you're familiar with Backend for Frontend (BFF), you already understand the underlying discipline.
BFF says: don't let your frontend call raw microservices. Build an intermediary that aggregates, transforms, and tailors data to what the frontend actually needs. The frontend gets a cleaner API. The microservices are protected. Security and transformation logic lives in one place.
The **Backend for Agents** (BFA) applies the same discipline to AI. Don't let your agents query raw microservices, raw event streams, or raw databases directly. It's a security nightmare — agents can't be trusted to enforce access controls — and it's a formatting disaster, because raw microservice APIs weren't designed for LLM consumption.
The BFA layer sits between agents and everything else. It aggregates context from multiple sources. It translates payloads into formats agents can reason over effectively. It enforces zero-trust security — agents only see what they're allowed to see. And it provides the governance surface you need when auditors ask what your agent did with that customer data.
The good news: you don't have to tear anything down.
A Context Mesh is an additive layer, not a replacement. Your existing microservices, your Kafka clusters, your databases — they all stay. The Context Mesh sits above them and makes them agent-ready.
The practical question is: what sits at the center of that Context Mesh, acting as the control plane?
You need something that can handle API gateway traffic, event stream governance, and AI-specific concerns (prompt routing, model selection, token metering, PII masking) in a unified way. Something that gives platform teams a single surface for policy enforcement across all three traffic types that agents rely on.
That's the missing piece that most architecture diagrams skip. The Context Mesh pattern is well-described. The control plane that makes it governable at scale is where most implementations get stuck.
New tools won't fix an inside-out design culture.
Platform teams need to change the question they ask when building integrations. The old question was: "What does this system expose?" The new question is: "What does this agent need?"
Those sound similar. They produce completely different architectures.
An endpoint optimized for what the database contains is not the same as a context endpoint optimized for what an agent needs to make a decision. The fields are different. The latency requirements are different. The update frequency is different. The access control model is different.
The teams that will make agentic AI work aren't the ones with the best models. They're the ones who applied the same rigor to their context layer that they previously applied to their API layer.
If you're evaluating your current integration architecture against agentic AI requirements, here are the questions worth asking:
If your current answers to those questions involve a lot of "it depends" and "we're working on it" — that's where the work is.
The Context Mesh isn't just a product you buy. It's an architecture you build. But you need the right foundation to build it on.
Your infrastructure already has the raw materials: compute (VMs, containers, serverless), event streaming (Kafka, Kinesis, Pub/Sub, RabbitMQ), data stores (warehouses, databases, object storage), and AI endpoints (any hosted or self-hosted LLM). Tho
Over the last few years, enterprises have made a genuinely impressive leap. They moved from rule-based automation to large language models capable of reasoning, planning, and acting. The intelligence layer is dramatically better. But the integration
An AI control layer is the governance and observability infrastructure that sits between AI agents and enterprise applications, handling authentication, routing, rate limiting, and auditability to ensure secure, managed access. Unlike traditional in
Built on top of Kong API Gateway, the Kong AI Gateway is designed to address key challenges in enterprise AI adoption. Modern AI applications rarely rely on a single model; instead, they orchestrate multiple GenAI providers, agent frameworks, Age
You can see this visualized in the diagram below. As you move to the right, you get smaller and smaller circles — more services, deployed faster, in a more distributed manner to add resiliency and features. As you move to the right, your control and
The Anatomy of Architectural Complexity Modern architectures now juggle three distinct traffic patterns. Each brings unique demands. Traditional approaches treat them separately. This separation creates unnecessary complexity. North-South API Traf
Executive Summary AI adoption has moved past the "honeymoon phase" and into the "operational chaos" phase. As enterprises juggle multiple LLM providers, skyrocketing token costs, and "Shadow AI" usage, the need for a centralized control plane has be