The shape of enterprise software is changing. Teams are only seeing half of it.

There's an assumption embedded in how enterprises are thinking about AI right now: that the goal is to connect your existing software to AI agents so those agents can use your tools more effectively.

That assumption is half right. And the half that's missing will matter more than most teams expect.

What MCP actually is and what it isn't

Model Context Protocol deserves the attention it's getting. It's a clean, standardised way for AI agents to discover and invoke tools across different software systems. Think of MCP servers as raw building blocks with enough context that an AI agent can figure out what they do, when to use them, and how to chain them together.

The mental model here is important. When you connect a Gmail MCP server and a Slack MCP server to Claude Desktop, you're handing the agent a set of primitives. The agent, with the help of an LLM, figures out which tools to call, in what order, to answer the question in front of it.

This works. And a significant amount of engineering energy is rightly going into making it work better with sharper tool descriptions, cleaner schemas, smarter routing. For enterprises starting their MCP journey, this is where the efforts are going. Rightly so.

But there's a ceiling to this model that isn't talked about enough.

The classic email agent paradigm

Here's a task that looks simple on the surface:

Summarise my unread emails since yesterday. Categorise and prioritise them. Draft responses to the important ones. Send a summary to Slack.

In today's MCP world, you'd connect Gmail and Slack MCP servers, and Claude Desktop would figure out how to chain the tools together to get this done. This works reasonably well for a technically sophisticated user who has set everything up correctly.

But here's the question worth sitting with: Why is every agent solving this from scratch?

Every instance of Claude Desktop, every Cursor user, every enterprise deployment is independently re-solving the same routing problem. Which tools. What order. How to handle edge cases. The logic is reconstructed on every invocation, with no accumulated expertise, no institutional memory of what "good" looks like for this specific workflow.

Now imagine instead that there's an Email Summariser Agent, a specialised agent that has already encoded this workflow. It knows how to read inboxes, apply prioritisation logic, draft contextually appropriate responses, and format a Slack summary. When Claude Desktop encounters this task, it doesn't reason through the primitives. It delegates to the specialist.

This, I think, is the shift that's coming.

Agents as the new unit of software

The best way to understand what's emerging is to think about what APIs did to software a decade ago.

Before the API economy, software was monolithic. You bought a product; the product did a thing. Then companies started exposing their capabilities as APIs as raw building blocks that developers could compose into new products.

Think about it: Stripe didn't just process payments. It packaged the capability of accepting money in a way that any developer could drop into their product without understanding the underlying banking infrastructure. You didn't need to know how card networks work. You called the API and Stripe handled it. That's what made it composable and that's what made it worth billions.

Agents are about to do the same thing to workflows. You won't need to know how an email triage workflow is orchestrated internally. You'll delegate to an agent that already knows, and it will return you a result.

Instead of exposing raw API endpoints, companies will expose specialised agents — units of work that already know how to solve a specific job. These agents internally may use MCPs, APIs, or other agents. But what they expose is not a tool. It's a capability. A packaged, repeatable, delegatable solution to a real problem.

MCPs are the API layer of this world. Agents are the product layer.

Both matter. But they play fundamentally very different roles.

Recommended Read: If you're weighing whether to build MCP-first or stick with your existing API layer, this is worth 5 minutes: MCP or API — which should you build first? walks through the real architectural tradeoffs and when each approach earns its place.

Why this matters for enterprise infrastructure decisions today

Here's the part that should concern enterprise architecture teams right now.

Agent-to-agent communication (A2A) is not a distant future concept. It's the natural next step once agent ecosystems mature. Google has already published an A2A protocol spec. The problem it's solving is real: how do agents discover other agents, negotiate capabilities, delegate tasks, and communicate results in a standardised way?

The infrastructure questions this raises are not small.

When an email summariser agent is acting on behalf of a user inside your enterprise, you need to know: Which agent was authorised to do this? What permissions did it have? What did it access, and when? If the agent was compromised or decommissioned, can you revoke its access across every system it touched?

These are the same questions MCP raised and the enterprises that built rigorous authentication and authorization infrastructure for their MCP deployments will find they're already halfway to being A2A-ready. The ones that cut corners, shipping with API keys or weak auth because the demos worked, will face a painful re-architecture.

Recommended Read: This is exactly the gap that Migrating from API keys to OAuth 2.1 for MCP servers addresses. If your current MCP setup relies on static API keys, here's a practical guide to modernising with short-lived, scoped tokens — without rebuilding everything from scratch.

The decisions made about MCP infrastructure today are not just MCP decisions. They're the foundation for everything that comes next.

What to watch out for

A2A as a protocol is early. It may evolve significantly or be superseded by something that solves the same problem differently. But the underlying dynamic of specialised agents being discovered, delegated to, and composed by orchestrator agents is the logical endpoint of where this is all heading.

For enterprises, the practical posture is this: don't wait for A2A to mature before taking infrastructure seriously. The companies building production-grade MCP deployments today with proper OAuth flows, audit logs, identity, and access controls are the ones who will be able to extend those foundations when A2A arrives.

The shape of enterprise software is changing. It will no longer look like apps you log into. Instead, it will look like agents you delegate to.

The only question is, whether the infrastructure you're building today can carry the weight of what's coming.

Recommended Read: For a ground-level view of what production-grade agent auth actually looks like end to end — token vaults, delegated consent, scoped credentials across Slack, Salesforce, and beyond — Tool calling authentication for AI agents is the most practical deep-dive we've published on the subject.

At Scalekit, we're building the authentication and authorization infrastructure for this transition, handling both the inbound flows that secure your MCP servers today and the outbound flows that will govern agent-to-agent communication tomorrow. If you're building on either side of that workflow, we should talk.