MCP is the path to agentic orchestration — if you have the right control plane

Most agentic AI strategies start in the wrong place. They start with agents: how to build them, where to deploy them, how fast they can take over work. That instinct is understandable because the technology carries genuine transformative potential, and the business pressure to act on it is real. But it skips the harder question: what your enterprise is actually ready to support. And it overlooks what enterprises already have decades of encoded process intelligence that agents need to be worth anything in production.

We’ve been here before. When cloud arrived, the early playbook was lift-and-shift. The organizations that came out ahead paused and asked something different first: “How do our systems need to change to work in this new model?”

Agentic AI demands the same reframe, and the stakes are higher. Enterprises want to move fast on AI. What they don’t want is to find out later that speed came at the cost of control over the processes the business runs on. Getting both requires more than deploying agents.

Cloud gave you a decade to adapt, but agentic AI demands control from day 1

Announcing an agentic AI strategy and being ready for one are two very different things.

With cloud, most enterprises had years to figure it out. There was room to watch early adopters, learn from their mistakes and still close the gap. Agentic AI is unfolding differently and at a pace that makes the old timeline irrelevant. SAP alone has announced more than 200 agents and assistants spanning finance, procurement, supply chain, HCM and customer experience, all in a single product cycle. The window for “wait and see” is compressing in real time.

The market is progressing from co-pilots assisting individual users to agents executing discrete tasks to multi-agent systems operating across end-to-end business processes. Most enterprises are somewhere in the first two stages right now, running pilots, testing where agents can be trusted and working out how they fit into broader workflows.

But the coordination challenges that come next are already visible. As agents start touching the same systems and processes, questions about governance, dependency management and accountability don’t stay theoretical for long. 

Who owns the outcome when agents are working across the same systems simultaneously? 

What happens when one agent’s action invalidates another’s mid-workflow?

Most current strategies don’t have good answers to those questions yet, because the focus has been on getting agents deployed rather than on what governs them once they are.

The path to agentic AI runs through orchestration, not around it.

The real bottleneck? Execution, not intelligence

Every enterprise process an agent touches was built before agents existed, so it was designed for deterministic logic, human oversight and predictable inputs. Layering intelligence on top of that infrastructure adds a new source of complexity that the underlying systems have no way to absorb. 

Agents can decide what to do. That part is getting easier every month. What they can’t do reliably is operate inside the constraints those systems were built around.

Ask an AI assistant to help close the books at month-end. It can summarize status and flag anomalies, but the moment it needs to trigger the intercompany elimination run, check whether the prior step completed successfully, wait on a dependency from a separate system and then kick off consolidation in the right sequence, it hits a wall. The business logic that governs how that process runs lives inside your enterprise systems, and it wasn’t written down last year. It was encoded over years of implementation, audit cycles and hard lessons. The agent has no reliable way to operate within it, and no way to reconstruct it on its own.

The same is true in the supply chain. An agent can analyze demand signals and recommend a replenishment order, but executing that recommendation means touching inventory systems, ERP planning runs, supplier APIs and warehouse management in a specific sequence, with specific dependencies and under specific business rules. One step out of order, and you’re looking at a broken process.

Enterprises run on deterministic, interconnected workflows built for consistency, compliance and predictability. AI models are probabilistic. They explore, reason and adapt, which is exactly what makes them useful. But because enterprise workflows follow defined paths, bringing those two worlds together requires more than giving agents access to your systems.

A model that can see your workflows isn’t the same as one that can reliably execute them. Without a controlled execution layer between the agent and the process, you end up with something that looks capable in a demo and falls apart in production.

What about legacy systems you don’t want to refactor?

For enterprises with mature ERP environments, legacy middleware or on-premises systems built over decades, the calculus is clear: you aren’t going to refactor SAP ECC, Oracle EBS or a 20-year-old mainframe process to “become agent-ready.” Nor should you.

This is where a protocol-based approach changes the equation. A well-designed MCP implementation allows those systems to surface what they know and what they can do to AI agents, without touching the underlying code. The agent doesn’t need to know that it’s talking to a legacy system; it just needs a consistent interface. The hard-won process logic, the business rules, the compliance controls, all of it stays in place. What changes is that agents can now reach it.

Consider what that means. The process logic inside a mature SAP ECC environment or a mainframe-based supply chain isn’t just code. It’s 20 or 30 years of business decisions, regulatory responses, exception handling and operational learning made concrete. That’s not a liability to modernize away. It’s institutional capital. A protocol-based architecture treats it that way: as something to expose and extend, not replace.

This is one of the most underappreciated advantages of a protocol-based architecture for enterprise AI. It doesn’t require you to modernize everything before you can start. It lets you extend agentic capability to the systems you already rely on, at whatever pace your organization can absorb.

Multi-agent systems need more than access 

The moment multiple AI agents start interacting with enterprise systems without a control plane, the questions become very practical, very quickly: 

• Who orchestrates execution across agentic workflows? 
• How are dependencies enforced? 
• What happens when two agents act on the same process simultaneously?
• How do you reconstruct an audit trail when decisions were made at machine speed across multiple systems?

The answers don’t come from the agents themselves. An agent optimizing a procurement workflow doesn’t know (and shouldn’t be expected to know) that another agent just put a hold on the same supplier for a compliance reason. Without orchestration, both actions proceed, and the impact is difficult to untangle.

The same force that makes agentic AI powerful — its ability to act quickly across systems — also makes it a new kind of liability when left ungoverned. Orchestration debt starts with the second agent you deploy. Most teams don’t feel it until the tenth, by which point the untangling is considerably more expensive than building the control layer upfront.

MCP is the right protocol — and the wrong place to stop

Model Context Protocol (MCP) solves a real and longstanding problem: how AI systems connect to enterprise tools and applications. Since Anthropic released it as an open standard in late 2024, adoption has been striking, with every major AI vendor now on board, more than 10,000 active public MCP servers and the protocol donated to the Linux Foundation’s Agentic AI Foundation to ensure it stays open and community-driven.

The breadth of enterprise investment reinforces why MCP matters. SAP has built MCP server support directly into its ABAP development environment, opening its core ERP ecosystem to the full agentic AI ecosystem. AWS has embedded MCP as the connectivity standard inside Amazon Bedrock AgentCore, its production platform for enterprise agent deployment. These aren’t experiments. They are architectural commitments from the largest enterprise software vendors in the world.

But understanding what MCP is and what it deliberately isn’t is critical for enterprise architects.

MCP is a connectivity protocol. It standardizes how agents discover and call tools, read data from systems and receive context. That scope is intentional. MCP was designed to solve the integration layer: the “M × N problem” of every AI model needing bespoke connectors to every enterprise system. It solves that elegantly.

What MCP doesn’t do — and doesn’t try to do — is orchestrate execution, manage dependencies, enforce sequencing or provide the governance layer that enterprise processes require. It gives agents a door into your systems, but it doesn’t control what happens once they walk through it.

It’s worth noting that a second protocol layer, Agent to Agent (A2A), is emerging to address how agents coordinate with each other. Where MCP governs what an agent can reach, such as tools, data and systems, A2A governs who an agent can call on: other specialized agents, orchestrator agents managing broader workflows or entirely external agent services operating outside your own environment. That means an agent handling a procurement exception can delegate to a compliance agent, escalate to a human-in-the-loop workflow or hand off to a third-party agent service, all through a standardized handshake rather than bespoke integrations.

SAP has drawn this distinction clearly in its AI Agent Hub: if an agent needs a resource, it uses MCP; if it needs another agent, it uses A2A. That separation is deliberate and important. Together, the two protocols create an agnostic and extensible fabric for enterprise agentic AI that doesn’t lock you into a single vendor’s orchestration model and accelerates how quickly new agents and capabilities can be added. Neither protocol was designed to govern what happens at the process execution layer underneath, though. Without that layer, connecting agents to your enterprise simply accelerates fragmentation: more actions, across more systems, with less control. That gap remains architectural, and it’s where enterprise implementations succeed or fail. The implications of A2A for enterprise orchestration deserve a longer conversation.

The market is arriving at this conclusion simultaneously

The ambition at SAP Sapphire 2026 was clear. SAP CEO Christian Klein launched the SAP Business AI Platform with a vision of the “Autonomous Enterprise, where agents run the business.” The platform encompasses agent development, agent governance and a reworked application portfolio built to make that vision real.

What Klein also acknowledged is the prerequisite that makes it possible: “No AI agent can compensate for a bad data landscape.” SAP’s own analysis is that agents fail when enterprise data is fragmented, inconsistent or trapped in disconnected systems. The ambitious 200-agent roadmap and the operational challenge are the same problem stated two different ways.

This is a validation of the underlying architecture question. The vendors who are most serious about agentic AI are the ones most clearly articulating that connectivity is necessary but not sufficient. The governance and execution layer is what determines whether agents deliver real business outcomes or just faster ways to create new problems.

The same principle applies one layer down. No AI agent can compensate for ungoverned process execution either. Data quality is the prerequisite for decisions. Process governance is the prerequisite for actions. SAP is right about the first. The second is what most agentic strategies still don’t account for.

RunMyJobs: The execution and control plane for agents

For over 30 years, Redwood Software has been the system of record for how enterprise work gets done. Not just automating tasks but encoding the business logic, dependency maps, exception rules and compliance controls that mission-critical processes run on. That institutional knowledge, accumulated across hundreds of enterprise environments, is what RunMyJobs by Redwood carries into the agentic era.

When an agent initiates an action through MCP, RunMyJobs becomes the execution layer behind it, orchestrating that action across systems, enforcing dependencies, handling exceptions and ensuring every step is observable and traceable. Agent-driven actions operate within enterprise guardrails, including the auditability and control required for SOX and other compliance frameworks.

Importantly, this works with the systems you already have. Existing workflows and business logic become accessible to AI systems through a protocol they already understand, including the legacy environments you don’t intend to refactor. Instead of rebuilding workflows, you expose what already exists, bringing your full automation ecosystem to agents without migration or starting from scratch.

The architecture is straightforward:

Plan for what comes after agent deployment 

The early stages of agent adoption are manageable. A pilot here, a discrete use case there, humans reviewing outputs before anything consequential happens. What’s coming next is not.

As agent adoption scales, the challenge shifts from capability to coordination. Agents that operate independently will begin to duplicate work, contradict each other and create unpredictable outcomes as they interact with the same business processes. Manual oversight won’t scale with them. 

The question is already changing from “Can we build agents?” to “How do we manage hundreds of them across enterprise systems, in production, with accountability for every action?”

Autonomy will evolve in stages, from human oversight to exception-based control to constrained autonomy operating within defined guardrails. Each stage depends on the same thing: a control layer that governs how work gets done. 

The enterprises that will get agentic AI right aren’t starting from scratch. They’re sitting on decades of encoded process intelligence, business logic, compliance controls and exception handling that agents need to act reliably in production. Redwood has been building and maintaining that foundation for 30 years. MCP is what makes it available to the agentic era, without losing a single rule that took years to get right.

Explore the technical details of how RunMyJobs works with MCP, or get a demo today.