EXECUTIVE SUMMARY - Every previous enterprise software era produced a connective standard - SQL for data, APIs for services - and the agentic era is producing its own: Model Context Protocol (MCP), an open standard that lets AI systems discover and use tools across vendors without bespoke integration per pair. The strategic shift it enables is easy to miss inside the technical discussion: integration effort moves from N×M (every model wired to every system) toward N+M (every system exposed once, usable by any agent). This report gives leaders the Agentic Integration Stack - a four-layer model separating hype from architecture - the Agent Readiness Test for deciding whether a workflow deserves an agent at all, and a this-quarter agenda that costs almost nothing and preserves every option.
What actually changed
Enterprises have connected AI to internal systems for two years - as one-off integrations, each a custom marriage between one model and one system, each an orphan when either side changes. A protocol changes the ownership structure: the system team exposes capabilities once, with typed inputs and declared permissions, and any compliant agent can discover and use them. The integration asset stops belonging to an AI project and starts belonging to the enterprise. That is the same move that made APIs an architectural fact rather than a project artifact - and it is why the interesting budget line is not "agents" but layer 2: the tool interface estate.
The four layers, and who owns them
Layer 1 - Systems of record. Unchanged. Their new obligation is to be invocable: clean auth, stable interfaces, meaningful error messages. Owner: existing platform teams.
Layer 2 - Tool interface (MCP servers). Each capability exposed once - "create ticket," "fetch ledger entry," "query inventory" - with schemas and scopes. This is the layer with compounding returns: every server built makes every current and future agent more capable. Owner: platform engineering, with the same review rigor as a public API.
Layer 3 - Orchestration & governance. The layer enterprises skip and regret: which agent may call which tool, with whose identity, under what spend and rate limits, with what human-approval gates for irreversible actions, and - non-negotiably - an audit trail of every call. An agent action without an audit trail is a compliance finding scheduled for later. Owner: security/platform jointly; anchor policies to NIST AI RMF risk tiers.
Layer 4 - Agents. The visible layer, and the most replaceable. Models and agent frameworks will churn annually; workflows built on governed tool interfaces survive that churn, while workflows welded to one vendor's agent runtime re-platform each cycle. Owner: application teams, treated as product, with the operational discipline of the Four Gates.
The Agent Readiness Test
Not every workflow deserves an agent; most deserve a script. A workflow earns agentic treatment only if all four hold:
- Multi-step with tool use - it spans systems and sequences actions, not just answers questions.
- Bounded blast radius - worst-case wrong actions are reversible or gated behind approval.
- Verifiable outcome - success is checkable by rule or by a human at defined points, not vibes.
- Volume or urgency - it happens often enough (or at hours humans don't) to repay the governance overhead.
Fail condition 1 → you want automation or RAG, not an agent. Fail 2 or 3 → you may still proceed, but with approval gates that will dominate your design. Fail 4 → the governance tax exceeds the value; leave it manual. In my consulting work, most proposed "agent use cases" fail at least one condition on first inspection - and that inspection, done early, is where the money is saved.
What leaders should do this quarter
The correct posture is neither wait-and-see nor agent-everything; it is build layer 2, pilot layer 4. Concretely: (1) inventory the ten internal capabilities agents would most plausibly need, and stand up MCP servers for the two safest, read-only ones; (2) write the layer-3 policy skeleton - identity, scopes, audit, approval gates - while the stakes are still low; (3) run exactly one agent pilot that passes all four readiness conditions, instrumented end-to-end; (4) refuse, politely, every agent proposal that arrives without a tool-and-governance plan attached. This agenda costs weeks, not quarters, and every artifact it produces remains valuable regardless of which agent frameworks win.
FAQ
Is MCP mature enough to bet on? The pattern is a safer bet than any implementation. Servers are thin by design; even in a protocol shift, exposed-capability work transfers. The genuinely non-transferable spend is bespoke per-pair integration - the thing the protocol replaces.
Does this obsolete our RPA and iPaaS estate? No - it gives them a front door. Deterministic automations become excellent tools for agents to invoke; see how this composes with the three automation patterns.
Biggest risk? Permission sprawl: agents accumulating scopes the way service accounts always have, minus the scrutiny. Layer 3 exists precisely so that convenience never silently becomes exposure.
Action checklist
- [ ] Inventory the top 10 capabilities agents would need; classify read-only vs. state-changing
- [ ] Stand up 2 read-only MCP servers as the pilot estate
- [ ] Draft the governance skeleton: identity, scopes, audit trail, approval gates
- [ ] Screen agent proposals with the four-condition Readiness Test
- [ ] Run one instrumented agent pilot; publish its audit trail internally as the norm-setter
- [ ] Re-evaluate the protocol landscape quarterly; keep layer 2 vendor-neutral
Related: RAG vs. Fine-Tuning · The Four Gates
Planning your agentic roadmap? I run Agentic Integration Stack assessments - capability inventory, governance skeleton, and the first-pilot selection. → Book a consultation
Working through this in your organization?
I advise enterprise teams on exactly these problems. Start with a free 30-minute consultation.
Discuss Your Challenge