MCP is becoming the default answer to every enterprise-agent architecture question. Access internal data? MCP. Call company APIs? MCP. Two agents need to communicate? MCP. Build the internal AI platform? Put an MCP server in front of everything.
An MCP server is not an AI platform.
It does not decide which source is authoritative. It does not preserve business transactions. It does not establish whether an employee may authorize a payment. It does not execute a process that waits three days for human approval. It does not determine whether an agent selected the right tool or produced the correct outcome.
MCP standardizes one boundary: the connection between an AI application and a capability. An enterprise agent platform must handle several others.
Who built what, and why it matters
These protocols arrived within eighteen months of each other. Four vendors, four open protocols, four different problems:
MCP (Anthropic, open-sourced November 2024) standardizes how AI clients discover and invoke tools. JSON-RPC based, with lifecycle negotiation. Adopted by Claude, Cursor, VS Code, and dozens of agent frameworks. Strong fit: multiple AI clients sharing one capability interface.
A2A (Google, April 2025; v1.0 January 2026) standardizes how independently operated agents delegate work to each other. Built for cross-organization, cross-vendor agent collaboration, and now governed by the Linux Foundation. Strong fit: "investigate this supplier and produce a report" where the remote agent owns the outcome.
AG-UI (CopilotKit, open-source 2025) standardizes the streaming connection between agent backends and frontends. Strong fit: real-time state, interactive UIs, human-in-the-loop beyond chat.
AgentCore (AWS, 2025) provides managed infrastructure for agent identity, capability gateways, and runtime. Strong fit: credential management, workload identity, and gateway routing in AWS environments.
All open. All solving different problems. None alone is sufficient for a production enterprise platform.
The seven boundaries
The architecture becomes clear when you stop treating "agent communication" as one problem:
| Boundary | Technology | What it solves |
|---|---|---|
| Agent → tool | MCP, function calling | Discover and invoke bounded capabilities |
| Agent → business service | REST, gRPC, GraphQL | Deterministic domain operations with existing guarantees |
| Agent → agent | A2A | Delegate goals to independently operated agents |
| Agent → user | AG-UI, A2UI, MCP Apps | Stream state, render interactive experiences |
| Service → service | APIs, events, queues | Reliable system integration (already solved) |
| Agent → durable process | Workflow engines | Persistence, retries, approvals, compensation |
| Identity → resource | OAuth, OIDC, IAM | Establish and enforce authority |
These overlap but are not interchangeable. MCP can invoke a tool that starts a workflow. It does not need to become the workflow engine. A2A can delegate work to a procurement agent. It does not need to expose every database operation.
As models improve, what disappears?
Models are getting better at selecting tools, planning multi-step work, writing temporary orchestration code, and recovering from errors. Hard-coded routing will shrink:
# This disappears
if request_type == "support":
call_support_agent()
elif request_type == "billing":
call_billing_agent()
The model will assemble execution paths dynamically. But stronger models do not remove the need for identity, authorization, transactions, durable state, audit, or evaluation. A more capable agent can attempt more actions, which makes the control layer more important, not less.
Direction: less custom orchestration, stronger capability and trust infrastructure.
The platform as six planes
Cross-cutting: identity, authorization, policy, secrets,
audit, observability, evaluation, cost, lifecycle
How it works: one business scenario through all six planes
Customer contacts support about an incorrect €847 charge.
Experience: Support portal shows AI-surfaced customer context.
Runtime: Model reads conversation, retrieves history, interprets refund policy, determines this is an exception refund requiring manager approval.
Capability: Agent calls create_refund_proposal(order_id, amount: 847, reason: "incorrect_charge", evidence: [...]) through MCP gateway → order-management service.
Context: Agent retrieves current policy (v4.2), customer history (3 years, zero disputes), return status from governed data products.
Execution: Step Functions starts durable workflow, sends approval to manager, waits up to 72 hours. Manager approves via mobile notification.
Systems of record: Workflow executes refund in SAP, publishes CRM event, triggers customer notification. Audit trail records every identity, decision, timestamp.
The agent handled interpretation and evidence gathering. Deterministic systems handled everything with consequences.
Five trends shaping the next two years
MCP becomes the common agent-tool connector, coexisting with APIs. Enterprise services keep their REST/gRPC interfaces. MCP provides agent-oriented adapters.
Capability discovery is now harder than capability connection. Finding the right trusted tool among thousands, filtering by policy, presenting a relevant subset: that is the real platform challenge.
Code replaces static orchestration. Models generate temporary code inside sandboxes. Fewer rigid sequences, more safe execution environments.
Agent identity turns into a security discipline. Organizations manage agent principals with the same rigor as workloads and users.
Enterprise context becomes the durable advantage. Models improve and become interchangeable. The hard assets: authoritative data, business semantics, high-quality tools, and permission models.
What to do Monday morning
Map your seven boundaries. Which exist today? Where are you using MCP as a substitute for a workflow engine?
Identify where the model makes decisions that should be deterministic. The failure we see most often is an agent that reasons its way into executing a refund because no workflow gate ever forced it to stop. If the agent can do that, you have a control gap.
Build one traced example end-to-end. Pick a real process, trace it through all six planes, identify where trust is assumed rather than enforced.
The governed enterprise layer gets thicker as models get more capable. That is where platform investment pays off.
Next in this series: MCP in Production: Tool Design, Catalogs, and the Gateway Problem — the practitioner's guide to making MCP work at scale.
Top comments (5)
Good map, and separating agent to durable process from the other six is the boundary I see teams collapse most often. The trap is implementing that one in-context: the agent calls the tool and then waits for the multi-day approval by polling or holding the conversation open, which does not survive a process restart, a deploy, or a crash, so a human decision that lands on day three resumes nothing. The durable-process boundary only holds if the pending state and the approval live outside the agent, in a queue or store the agent re-reads, so a day-three approval resumes a cold process rather than a hung one. That is also what keeps the authority envelope Mads mentioned intact across the wait, since the state carries who approved what rather than a trace that already ended. I put the persistent-state-outside-the-agent piece into an MCP server over a task manager here: github.com/renezander030/agentic-t...
Useful boundary map. The failure mode I see between the seven is loss of intent and authority when each layer starts a new trace. I would carry one correlatable execution envelope through MCP → service → workflow → system of record: initiating user/agent principal, delegated scopes, policy version, capability version, business idempotency key, evidence references, approval ID, and trace/workflow ID. Each boundary may narrow authority, never widen it. Compensation should attach to the business operation rather than a model retry. Then audit can answer why a refund happened end to end, instead of producing seven individually correct but disconnected logs.
Spot on. The "seven individually correct but disconnected logs" failure is the most common symptom of missing envelope correlation.
One addition: the envelope also needs decision provenance. When the agent decides "exception refund," the reasoning (which policy clause, which evidence, which model version) should travel with it. Without that, audit reconstructs "what happened" but not "why the agent thought it should".
The narrowing-only authority rule becomes more critical as models get more capable and attempt more creative paths through the capability layer.
Have you seen this pattern formalized anywhere beyond custom implementations?
The boundary framing is important. MCP can standardize how tools are exposed, but it does not decide trust, identity, tenancy, data policy, evaluation, or rollback. Enterprise platforms need those layers to be explicit, not implied by the protocol.
The Identity→resource row and the Agent→agent row seem to assume a single trust domain. OAuth/OIDC/IAM gives you authority semantics only where you control, or at least federate with, the identity provider. Once A2A delegates to an agent run by another organization on the open web, there may be no shared IdP, so “the remote agent owns the outcome” becomes a liability label without enforcement. You cannot revoke a credential you never issued, and you cannot reliably attribute a counterpart’s past behavior unless its claims are portable across interactions. In systems with signed, append-only event logs across mutually untrusted agents, the useful primitive is the counterpart signing assertions with a key you can pin and re-verify later. I would split the agent→agent boundary into transport/delegation, which A2A covers, and cross-domain accountability, which still needs portable verifiable identity.