Most agen­tic AI strate­gies 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 under­stand­able because the tech­nol­o­gy car­ries gen­uine trans­for­ma­tive poten­tial, and the busi­ness pres­sure to act on it is real. But it skips the hard­er ques­tion: what your enter­prise is actu­al­ly ready to sup­port. And it over­looks what enter­pris­es already have: decades of encod­ed process intel­li­gence that agents need to be worth any­thing in production.

We’ve been here before. When cloud arrived, the ear­ly play­book was lift-and-shift. The orga­ni­za­tions that came out ahead paused and asked some­thing dif­fer­ent first: ​“How do our sys­tems need to change to work in this new model?”

Agen­tic AI demands the same reframe, and the stakes are high­er. Enter­pris­es want to move fast on AI. What they don’t want is to find out lat­er that speed came at the cost of con­trol over the process­es the busi­ness runs on. Get­ting both requires more than deploy­ing agents.

Cloud Gave You a Decade To Adapt, but Agen­tic AI Demands Con­trol From Day 1

Announc­ing an agen­tic AI strat­e­gy and being ready for one are two very dif­fer­ent things.

With cloud, most enter­pris­es had years to fig­ure it out. There was room to watch ear­ly adopters, learn from their mis­takes, and still close the gap. Agen­tic AI is unfold­ing dif­fer­ent­ly and at a pace that makes the old time­line irrel­e­vant. SAP alone has announced more than 200 agents and assis­tants span­ning finance, pro­cure­ment, sup­ply chain, HCM, and cus­tomer expe­ri­ence, all in a sin­gle prod­uct cycle. The win­dow for ​“wait and see” is com­press­ing in real time.

The mar­ket is pro­gress­ing from co-pilots assist­ing indi­vid­ual users to agents exe­cut­ing dis­crete tasks to mul­ti-agent sys­tems oper­at­ing across end-to-end busi­ness process­es. Most enter­pris­es are some­where in the first two stages right now, run­ning pilots, test­ing where agents can be trust­ed, and work­ing out how they fit into broad­er workflows.

But the coor­di­na­tion chal­lenges that come next are already vis­i­ble. As agents start touch­ing the same sys­tems and process­es, ques­tions about gov­er­nance, depen­den­cy man­age­ment, and account­abil­i­ty don’t stay the­o­ret­i­cal for long. 

Who owns the out­come when agents are work­ing across the same sys­tems simultaneously? 

What hap­pens when one agent’s action inval­i­dates another’s mid-workflow?

Most cur­rent strate­gies don’t have good answers to those ques­tions yet, because the focus has been on get­ting agents deployed rather than on what gov­erns them once they are.

The path to agen­tic AI runs through orches­tra­tion, not around it.

The Real Bot­tle­neck? Exe­cu­tion, Not Intelligence

Every enter­prise process an agent touch­es was built before agents exist­ed, so it was designed for deter­min­is­tic log­ic, human over­sight, and pre­dictable inputs. Lay­er­ing intel­li­gence on top of that infra­struc­ture adds a new source of com­plex­i­ty that the under­ly­ing sys­tems have no way to absorb. 

Agents can decide what to do. That part is get­ting eas­i­er every month. What they can’t do reli­ably is oper­ate inside the con­straints those sys­tems were built around.

Ask an AI assis­tant to help close the books at month-end. It can sum­ma­rize sta­tus and flag anom­alies, but the moment it needs to trig­ger the inter­com­pa­ny elim­i­na­tion run, check whether the pri­or step com­plet­ed suc­cess­ful­ly, wait on a depen­den­cy from a sep­a­rate sys­tem, and then kick off con­sol­i­da­tion in the right sequence, it hits a wall. The busi­ness log­ic that gov­erns how that process runs lives inside your enter­prise sys­tems, and it wasn’t writ­ten down last year. It was encod­ed over years of imple­men­ta­tion, audit cycles, and hard lessons. The agent has no reli­able way to oper­ate with­in it, and no way to recon­struct it on its own.

The same is true in the sup­ply chain. An agent can ana­lyze demand sig­nals and rec­om­mend a replen­ish­ment order, but exe­cut­ing that rec­om­men­da­tion means touch­ing inven­to­ry sys­tems, ERP plan­ning runs, sup­pli­er APIs, and ware­house man­age­ment in a spe­cif­ic sequence, with spe­cif­ic depen­den­cies and under spe­cif­ic busi­ness rules. One step out of order, and you’re look­ing at a bro­ken process.

Enter­pris­es run on deter­min­is­tic, inter­con­nect­ed work­flows built for con­sis­ten­cy, com­pli­ance, and pre­dictabil­i­ty. AI mod­els are prob­a­bilis­tic. They explore, rea­son, and adapt, which is exact­ly what makes them use­ful. But because enter­prise work­flows fol­low defined paths, bring­ing those two worlds togeth­er requires more than giv­ing agents access to your systems.

A mod­el that can see your work­flows isn’t the same as one that can reli­ably exe­cute them. With­out a con­trolled exe­cu­tion lay­er between the agent and the process, you end up with some­thing that looks capa­ble in a demo and falls apart in production.

What About Lega­cy Sys­tems You Don’t Want To Refactor?

For enter­pris­es with mature ERP envi­ron­ments, lega­cy mid­dle­ware, or on-premis­es sys­tems built over decades, the cal­cu­lus is clear: you aren’t going to refac­tor SAP ECC, Ora­cle EBS, or a 20-year-old main­frame process to ​“become agent-ready.” Nor should you.

This is where a pro­to­col-based approach changes the equa­tion. A well-designed Mod­el Con­text Pro­to­col (MCP) imple­men­ta­tion allows those sys­tems to sur­face what they know and what they can do to AI agents, with­out touch­ing the under­ly­ing code. The agent doesn’t need to know that it’s talk­ing to a lega­cy sys­tem; it just needs a con­sis­tent inter­face. The hard-won process log­ic, the busi­ness rules, the com­pli­ance con­trols, all of it stays in place. What changes is that agents can now reach it.

Con­sid­er what that means. The process log­ic inside a mature SAP ECC envi­ron­ment or a main­frame-based sup­ply chain isn’t just code. It’s 20 or 30 years of busi­ness deci­sions, reg­u­la­to­ry respons­es, excep­tion han­dling, and oper­a­tional learn­ing made con­crete. That’s not a lia­bil­i­ty to mod­ern­ize away. It’s insti­tu­tion­al cap­i­tal. A pro­to­col-based archi­tec­ture treats it that way: as some­thing to expose and extend, not replace.

This is one of the most under­ap­pre­ci­at­ed advan­tages of a pro­to­col-based archi­tec­ture for enter­prise AI. It doesn’t require you to mod­ern­ize every­thing before you can start. It lets you extend agen­tic capa­bil­i­ty to the sys­tems you already rely on, at what­ev­er pace your orga­ni­za­tion can absorb.

Mul­ti-Agent Sys­tems Need More Than Access

The moment mul­ti­ple AI agents start inter­act­ing with enter­prise sys­tems with­out a con­trol plane, the ques­tions become very prac­ti­cal, very quickly: 

• Who orches­trates exe­cu­tion across agen­tic workflows?
• How are depen­den­cies enforced?
• What hap­pens when two agents act on the same process simultaneously?
• How do you recon­struct an audit trail when deci­sions were made at machine speed across mul­ti­ple systems?

The answers don’t come from the agents them­selves. An agent opti­miz­ing a pro­cure­ment work­flow doesn’t know (and shouldn’t be expect­ed to know) that anoth­er agent just put a hold on the same sup­pli­er for a com­pli­ance rea­son. With­out orches­tra­tion, both actions pro­ceed, and the impact is dif­fi­cult to untangle.

The same force that makes agen­tic AI pow­er­ful — its abil­i­ty to act quick­ly across sys­tems — also makes it a new kind of lia­bil­i­ty when left ungoverned. Orches­tra­tion debt starts with the sec­ond agent you deploy. Most teams don’t feel it until the tenth, by which point the untan­gling is con­sid­er­ably more expen­sive than build­ing the con­trol lay­er upfront.

MCP Is the Right Pro­to­col — and the Wrong Place To Stop

MCP solves a real and long­stand­ing prob­lem: how AI sys­tems con­nect to enter­prise tools and appli­ca­tions. Since Anthrop­ic released it as an open stan­dard in late 2024, adop­tion has been strik­ing, with every major AI ven­dor now on board, more than 10,000 active pub­lic MCP servers, and the pro­to­col donat­ed to the Lin­ux Foundation’s Agen­tic AI Foun­da­tion to ensure it stays open and community-driven.

The breadth of enter­prise invest­ment rein­forces why MCP mat­ters. SAP has built MCP serv­er sup­port direct­ly into its ABAP devel­op­ment envi­ron­ment, open­ing its core ERP ecosys­tem to the full agen­tic AI ecosys­tem. AWS has embed­ded MCP as the con­nec­tiv­i­ty stan­dard inside Ama­zon Bedrock Agent­Core, its pro­duc­tion plat­form for enter­prise agent deploy­ment. These aren’t exper­i­ments. They are archi­tec­tur­al com­mit­ments from the largest enter­prise soft­ware ven­dors in the world.

But under­stand­ing what MCP is and what it delib­er­ate­ly isn’t is crit­i­cal for enter­prise architects.

MCP is a con­nec­tiv­i­ty pro­to­col. It stan­dard­izes how agents dis­cov­er and call tools, read data from sys­tems, and receive con­text. That scope is inten­tion­al. MCP was designed to solve the inte­gra­tion lay­er: the ​“M × N prob­lem” of every AI mod­el need­ing bespoke con­nec­tors to every enter­prise sys­tem. It solves that elegantly.

What MCP doesn’t do — and doesn’t try to do — is orches­trate exe­cu­tion, man­age depen­den­cies, enforce sequenc­ing, or pro­vide the gov­er­nance lay­er that enter­prise process­es require. It gives agents a door into your sys­tems, but it doesn’t con­trol what hap­pens once they walk through it.

It’s worth not­ing that a sec­ond pro­to­col lay­er, Agent to Agent (A2A), is emerg­ing to address how agents coor­di­nate with each oth­er. Where MCP gov­erns what an agent can reach, such as tools, data, and sys­tems, A2A gov­erns who an agent can call on: oth­er spe­cial­ized agents, orches­tra­tor agents man­ag­ing broad­er work­flows, or entire­ly exter­nal agent ser­vices oper­at­ing out­side your own envi­ron­ment. That means an agent han­dling a pro­cure­ment excep­tion can del­e­gate to a com­pli­ance agent, esca­late to a human-in-the-loop work­flow, or hand off to a third-par­ty agent ser­vice, all through a stan­dard­ized hand­shake rather than bespoke integrations.

SAP has drawn this dis­tinc­tion clear­ly in its AI Agent Hub: if an agent needs a resource, it uses MCP; if it needs anoth­er agent, it uses A2A. That sep­a­ra­tion is delib­er­ate and impor­tant. Togeth­er, the two pro­to­cols cre­ate an agnos­tic and exten­si­ble fab­ric for enter­prise agen­tic AI that doesn’t lock you into a sin­gle vendor’s orches­tra­tion mod­el and accel­er­ates how quick­ly new agents and capa­bil­i­ties can be added. Nei­ther pro­to­col was designed to gov­ern what hap­pens at the process exe­cu­tion lay­er under­neath, though. With­out that lay­er, con­nect­ing agents to your enter­prise sim­ply accel­er­ates frag­men­ta­tion: more actions, across more sys­tems, with less con­trol. That gap remains archi­tec­tur­al, and it’s where enter­prise imple­men­ta­tions suc­ceed or fail. The impli­ca­tions of A2A for enter­prise orches­tra­tion deserve a longer conversation.

The Mar­ket Is Arriv­ing at This Con­clu­sion Simultaneously

The ambi­tion at SAP Sap­phire 2026 was clear. SAP CEO Chris­t­ian Klein launched the SAP Busi­ness AI Plat­form with a vision of the ​“Autonomous Enter­prise, where agents run the busi­ness.” The plat­form encom­pass­es agent devel­op­ment, agent gov­er­nance, and a reworked appli­ca­tion port­fo­lio built to make that vision real.

What Klein also acknowl­edged is the pre­req­ui­site that makes it pos­si­ble: ​“No AI agent can com­pen­sate for a bad data land­scape.” SAP’s own analy­sis is that agents fail when enter­prise data is frag­ment­ed, incon­sis­tent, or trapped in dis­con­nect­ed sys­tems. The ambi­tious 200-agent roadmap and the oper­a­tional chal­lenge are the same prob­lem stat­ed two dif­fer­ent ways.

This is a val­i­da­tion of the under­ly­ing archi­tec­ture ques­tion. The ven­dors who are most seri­ous about agen­tic AI are the ones most clear­ly artic­u­lat­ing that con­nec­tiv­i­ty is nec­es­sary but not suf­fi­cient. The gov­er­nance and exe­cu­tion lay­er is what deter­mines whether agents deliv­er real busi­ness out­comes or just faster ways to cre­ate new problems.

The same prin­ci­ple applies one lay­er down. No AI agent can com­pen­sate for ungoverned process exe­cu­tion either. Data qual­i­ty is the pre­req­ui­site for deci­sions. Process gov­er­nance is the pre­req­ui­site for actions. SAP is right about the first. The sec­ond is what most agen­tic strate­gies still don’t account for.

Run­MyJobs: The Exe­cu­tion and Con­trol Plane for Agents

For over 30 years, Red­wood Soft­ware has been the sys­tem of record for how enter­prise work gets done. Not just automat­ing tasks but encod­ing the busi­ness log­ic, depen­den­cy maps, excep­tion rules, and com­pli­ance con­trols that mis­sion-crit­i­cal process­es run on. That insti­tu­tion­al knowl­edge, accu­mu­lat­ed across hun­dreds of enter­prise envi­ron­ments, is what Run­MyJobs by Red­wood car­ries into the agen­tic era.

When an agent ini­ti­ates an action through MCP, Run­MyJobs becomes the exe­cu­tion lay­er behind it, orches­trat­ing that action across sys­tems, enforc­ing depen­den­cies, han­dling excep­tions, and ensur­ing every step is observ­able and trace­able. Agent-dri­ven actions oper­ate with­in enter­prise guardrails, includ­ing the auditabil­i­ty and con­trol required for SOX and oth­er com­pli­ance frameworks.

Impor­tant­ly, this works with the sys­tems you already have. Exist­ing work­flows and busi­ness log­ic become acces­si­ble to AI sys­tems through a pro­to­col they already under­stand, includ­ing the lega­cy envi­ron­ments you don’t intend to refac­tor. Instead of rebuild­ing work­flows, you expose what already exists, bring­ing your full automa­tion ecosys­tem to agents with­out migra­tion or start­ing from scratch.

The archi­tec­ture is straightforward:

Plan for What Comes After Agent Deployment

The ear­ly stages of agent adop­tion are man­age­able. A pilot here, a dis­crete use case there, humans review­ing out­puts before any­thing con­se­quen­tial hap­pens. What’s com­ing next is not.

As agent adop­tion scales, the chal­lenge shifts from capa­bil­i­ty to coor­di­na­tion. Agents that oper­ate inde­pen­dent­ly will begin to dupli­cate work, con­tra­dict each oth­er, and cre­ate unpre­dictable out­comes as they inter­act with the same busi­ness process­es. Man­u­al over­sight won’t scale with them. 

The ques­tion is already chang­ing from ​“Can we build agents?” to ​“How do we man­age hun­dreds of them across enter­prise sys­tems, in pro­duc­tion, with account­abil­i­ty for every action?”

Auton­o­my will evolve in stages, from human over­sight to excep­tion-based con­trol to con­strained auton­o­my oper­at­ing with­in defined guardrails. Each stage depends on the same thing: a con­trol lay­er that gov­erns how work gets done. 

The enter­pris­es that will get agen­tic AI right aren’t start­ing from scratch. They’re sit­ting on decades of encod­ed process intel­li­gence, busi­ness log­ic, com­pli­ance con­trols, and excep­tion han­dling that agents need to act reli­ably in pro­duc­tion. Red­wood has been build­ing and main­tain­ing that foun­da­tion for 30 years. MCP is what makes it avail­able to the agen­tic era, with­out los­ing a sin­gle rule that took years to get right.

Explore the tech­ni­cal details of how Run­MyJobs works with MCP, or get a demo today.