The New Enterprise Capability Layer for AI – Part 2

Av Tomydas Pall, Grupproduktchef

I Part 1 of this blog series, I explored what Modellkontextprotokoll (MCP) standardizes, why it is gaining traction and how it is changing the way AI interacts with enterprise capabilities. The next question is how to make those capabilities available to AI agents at scale without compromising enterprise architecture, security, or governance.

In Part 2, I examine MCP’s role in enterprise integration, its evolution into an infrastructure layer and why a robust control layer will be critical to scaling adoption.

From Applications to Enterprise Capabilities

Integration architecture has traditionally been application-centric:

CRM → ERP

E-commerce → Order Management

Order Management → Fulfillment

Agents introduce a different abstraction.

An agent does not necessarily need to know which application implements a capability. It needs to know what it is allowed to do.

Till exempel:

• check_inventory
• create_order
• generate_quote
• open_support_case
• approve_refund

MCP tools fit naturally into that model. Each tool has a name and schema describing its inputs and outputs, so the model can reason about how and when to use it.

Behind create_order could be a REST API, an integration workflow, several SaaS applications, a database, or a multi-step business process.

The agent interacts with the business capability. The implementation can stay behind it.

This is where I think integration platforms have an advantage that is easy to underestimate. Enterprises already have years of connectivity and business logic embedded in their integration estate:

• Kopplingar
• API:er
• Transformations
• Orchestrations
• Authentication
• Business workflows
• Error handling
• Hybrid connectivity

Rebuilding all of that specifically for AI would just create another silo.

A better path is to reuse what already exists.

An existing workflow can become an MCP tool.

Enterprise data can become an MCP resource.

Reusable business interactions can become MCP prompts.

In that model, integration platforms evolve from systems that connect applications into platforms that: package enterprise capabilities for AI consumption.

That, to me, is one of the most interesting implications of MCP.

MCP Is Becoming Infrastructure, Not Just an Interface

One of the less flashy but more important developments in the 2026 MCP specification is its move toward conventional web infrastructure.

The protocol is now stateless at its core. Requests can be self-contained, capability information can travel with them, list responses can be cached and routing information can be exposed through HTTP.

Those sound like implementation details, but they matter.

They make MCP easier to:

• Scale horizontally
• Route through gateways
• Cache
• Observe
• Authorize
• Operate using established cloud infrastructure

In other words, MCP is starting to fit into the way enterprises already know how to run distributed systems.

Long-running operations are also being addressed through the optional Uppgifter extension, which provides durable handles for asynchronous work rather than requiring every interaction to complete synchronously.

This is the kind of evolution you would expect if MCP is going to move from desktop assistants and developer tools into production enterprise infrastructure.

Enterprise MCP Needs a Control Layer and a Human in the Loop

Once agents can perform real business actions, connectivity is no longer the hard part.

Control is.

A mature enterprise architecture increasingly looks like:

AI Agent → MCP Gateway / Control Layer → MCP Servers → APIs, Integrations, Data & Workflows → Enterprise Systems

The protocol itself is evolving in this direction.

The current HTTP transport supports OAuth-based authorization, while enterprise authorization mechanisms allow organizations to centralize MCP access through identity providers and apply existing roles, groups and policies.

That matters because enterprises are not going to throw away the identity and access models they already have just because the caller happens to be an AI agent.

The same is true for human oversight.

Autonomy does not mean removing humans from every decision. MCP supports elicitation, allowing a server to request additional information or confirmation from a user during an interaction.

That becomes especially important once agents move from reading information to changing systems.

To me, this points to a broader shift: Identity and policy become part of the AI control plane, while the MCP gateway becomes the enforcement point for authorization, auditing, and observability.

There is an obvious parallel with APIs.

API gateways became important because enterprises needed centralized security, policy enforcement, traffic control, analytics and lifecycle management.

I expect MCP to follow a similar path.

The enterprise question is no longer simply: Can the agent call this tool?

The more important question is: Should this agent be able to discover this tool, invoke it in this environment, with this user’s authority, under these policies, and with a complete audit trail?

That is where enterprise MCP stops being just a connectivity problem and becomes an architecture and governance problem.

What Comes Next: MCP and the Future of Enterprise AI

MCP is not yet a universal standard.

Security, tool trust, governance, authorization and large-scale operations are still evolving. Existing APIs, native tool calling, proprietary connectors and agent frameworks will continue to have important roles.

But the architecture is starting to become recognizable.

Over the next few years, I expect enterprises to manage MCP capabilities much the way they manage APIs today:

• Cataloged
• Versioned
• Secured
• Governed
• Observed
• Exposed through controlled gateways

The difference is that these capabilities will increasingly be consumed not only by applications, but by autonomous and semi-autonomous agents.

The underlying question is straightforward: How do we connect rapidly evolving AI systems to relatively stable enterprise capabilities without rebuilding the integration layer for every model and agent platform?

MCP provides a compelling answer.

The next competitive advantage in enterprise AI will not come only from access to the best model.

It will come from how quickly, securely and reliably an organization can make its business capabilities available to AI agents.

APIs connected applications.
Integration platforms connected business processes.
MCP is becoming the interface through which AI accesses both.

The real question for enterprise architects is no longer whether agents will access business systems. It is what control layer will govern that access and whether MCP becomes the standard interface around which that control layer is built.

Redo att börja din agentiska AI-resa?

Se hur Jitterbit kan hjälpa dig att bygga, koppla samman och skala agentbaserade AI-lösningar med AI-assistenter, AI-agenter och den integreringsgrundval som krävs för att kunna konkurrera på en AI-driven marknad.

• Läs: MCP: The New Enterprise Capability Layer for AI – Part 1
• Läs: blog på Jitterbit MCPDen säkra grunden för AI-agenter på företag
• Se: Jitterbit MCP video
• Upptäck: Jitterbit MCP Klient
• Lär dig: Från våra experter får du Jitterbit AI agents se hur det fungerar och upptäcka bästa praxis för att skala utbyggnaden i detta webinar.