WhoControlstheAIAgents?WhyEnterprisesNeedaCorporateAgentRuntime

AI adoption has moved faster than enterprise control

The first wave of enterprise generative AI was relatively simple.

An employee opened a chatbot, asked a question, received an answer and decided what to do with it.

That model is changing rapidly.

AI is moving from conversation to execution.

Developers use coding agents that can inspect repositories and modify code. Consultants give agents access to documentation and tickets. Operations teams connect AI to internal tools. New protocols such as MCP make it increasingly easy to expose enterprise systems directly to agents.

An AI assistant might only tell an employee what to do.

An AI agent can actually do it.

That creates a fundamentally different enterprise architecture problem.

The important question is no longer:

Which AI model are our employees allowed to use?

The more important question becomes:

Which agents are operating inside our company, what do they know, which systems can they access, and who controls what they are allowed to do?

The important question is no longer which AI model employees use. The question is which agents operate inside the company, what they know, what they can access, and who controls what they can do.

For enterprises running SAP, this question becomes especially important.

SAP systems contain some of the organization’s most critical business processes, data and custom logic. An agent capable of interacting with SAP is potentially extremely valuable.

It is also something that needs to be governed as infrastructure - not treated as another productivity application.

The emerging problem: Shadow Agents

Enterprises have spent years building governance around users, applications and APIs.

AI agents introduce a new execution layer.

Consider a SAP developer working on an incident.

Today, that developer might use an AI coding agent locally. The agent receives access to:

• an ABAP repository,
• an incident description,
• architecture documentation,
• internal APIs,
• SAP development tools,
• Git repositories,
• perhaps Jira or ServiceNow.

The developer becomes dramatically more productive.

But from the enterprise perspective, several questions immediately appear.

• Who created the agent?
• Which model is it using?
• Which information was provided to it?
• Which repositories did it access?
• Which SAP systems can it reach?
• Which tools can it execute?
• What changes did it propose?
• What changes did it actually execute?
• Was human approval required?
• Where is the history of its work stored?

And what happens to everything the agent learned when the employee closes the session?

Without an enterprise architecture around agents, organizations may unintentionally create a new category of shadow IT:

Shadow Agents.

Architecture today: agents around the enterprise

A typical decentralized setup may look like this:

Each individual setup can be useful.

The problem appears at organizational scale.

The enterprise does not have one agent architecture.

It has hundreds of independent agent environments.

Each one may have different models, prompts, tools, permissions, knowledge and security assumptions.

The real governance problem is not the LLM

A common enterprise response is to focus governance primarily on model providers.

Questions typically include:

• Which LLM can employees use?
• Where is data processed?
• Is enterprise data used for training?
• Where is the model hosted?

These questions matter.

But they address only one part of the architecture.

The LLM is the reasoning engine.

The more important governance boundary is increasingly the agent runtime surrounding the model.

That runtime determines:

• what context enters the model,
• which knowledge the agent can retrieve,
• which tools the agent can call,
• which credentials it can use,
• which systems it can access,
• which actions require approval,
• what gets logged,
• and what can actually be executed.

Enterprise AI governance therefore needs to move from model governance toward agent execution governance.

A corporate agent runtime

Instead of allowing every employee to create an isolated execution environment, enterprises can introduce a controlled agent runtime.

The architecture changes significantly.

Now the employee still receives the productivity benefits of an AI agent.

But execution happens inside a corporate control plane.

The enterprise owns the environment.

Identity becomes part of agent execution

Traditional enterprise systems already understand users.

AI agents complicate this model.

An action may now involve:

User → Agent → Tool → Enterprise System

The enterprise needs to understand the entire chain.

For example:

This is fundamentally different from simply recording:

API user XYZ called SAP.

A governed runtime should preserve the relationship between the human, the agent, the tools and the resulting actions.

Agents should not receive unlimited tools

One of the most important architectural concepts for enterprise agents is controlled tool exposure.

An SAP analysis agent may need permission to:

• read ABAP source code,
• inspect DDIC objects,
• search application logs,
• retrieve dumps,
• analyze CDS views.

It does not necessarily need permission to modify production.

A development agent may additionally receive:

• code modification capabilities,
• Git commit access,
• ATC execution,
• test execution.

Transport or production actions can require another permission level entirely.

Instead of giving the agent generic system access, capabilities can be exposed as controlled tools.

This provides a much stronger security model than giving an autonomous process broad credentials.

Human approval becomes an architectural primitive

Human-in-the-loop should not be implemented only as a prompt telling the agent:

Ask the user before making important changes.

That is behavioral guidance.

Enterprise governance requires technical enforcement.

For sensitive operations, the runtime should stop execution and create an approval request.

For example:

Agent requests:
Modify ABAP class ZCL_BILLING_PROCESS

System:
DEV

Reason:
INC-4821

Files affected:
3

Tests:
12 passed

Risk:
Medium

Action:
[Approve] [Reject] [Review Changes]

Only after approval should the runtime expose the execution capability.

This turns approval from a conversational convention into a security boundary.

The second problem: corporate knowledge is leaking into conversations

Agent governance is only half of the problem.

The other half is knowledge ownership.

Enterprise employees constantly teach AI systems about their organization.

They explain:

• why a particular SAP enhancement exists,
• why a strange piece of ABAP code cannot be removed,
• which integration failed three years ago,
• which customer-specific exception is intentional,
• how a particular billing process works,
• what was decided during an implementation,
• why a workaround was introduced.

This information is enormously valuable.

But today it often lives inside individual AI conversations.

That means an employee may spend several hours teaching an agent how a system works.

The session becomes highly valuable.

Then the session ends.

The next employee starts again.

Enterprise AI needs institutional memory

Imagine an SAP landscape that has been developed for 15 years.

Its real architecture is not contained in a single document.

It exists across:

• ABAP custom code,
• customizing,
• functional specifications,
• Jira tickets,
• ServiceNow incidents,
• Confluence,
• SharePoint,
• Git history,
• architecture decisions,
• emails,
• and the experience of senior consultants.

AI agents can potentially connect these sources.

But only if knowledge becomes an enterprise asset rather than temporary chat context.

A corporate agent platform therefore needs a persistent knowledge layer.

The objective is not to dump all corporate data into an LLM.

The objective is to provide the right knowledge to the right agent for the right task.

Knowledge needs boundaries too

Enterprise knowledge cannot become one enormous shared vector database.

Access boundaries still matter.

A consultant working for Customer A should not automatically expose Customer A’s information to an agent operating for Customer B.

A production support agent may require different context than a development agent.

Sensitive projects may require isolated knowledge stores.

Therefore enterprise agent knowledge should inherit organizational boundaries such as:

• company,
• customer,
• project,
• system,
• team,
• role,
• data classification.

The same principles enterprises already apply to identity and data need to be applied to AI context.

Agent sessions themselves become corporate assets

There is another interesting consequence.

Some agent sessions will become valuable work products.

Imagine an agent working for five hours on a complex SAP incident.

During that time it:

• analyzes the ticket,
• explores custom ABAP code,
• identifies relevant customizing,
• traces integrations,
• discovers historical changes,
• runs tests,
• develops several hypotheses,
• eliminates incorrect ones,
• and prepares a solution.

Then the employee goes home.

Should another engineer start from zero?

Probably not.

In a corporate runtime, the session can belong to the organization rather than to an individual laptop.

Another authorized employee can continue the investigation.

This changes AI from a personal productivity tool into organizational infrastructure.

From AI assistants to digital enterprise workers

The transition can be summarized in three stages.

Stage 1 - AI Assistant

The AI answers questions.
Human executes the work.

Stage 2 - AI Agent

The AI can use tools and execute tasks.
Human supervises the work.

Stage 3 - Corporate Agent Runtime

Agents operate inside enterprise policies, identity, knowledge, approvals and audit infrastructure.
The organization supervises the system.

This third stage is where enterprise architecture becomes critical.

Where AgentOS fits

At Codemine, this is the architectural problem we are exploring with AgentOS.

AgentOS is designed around the idea that enterprise agents should not operate as isolated black boxes on employee laptops.

Instead, organizations need a controlled environment connecting:

People
   ↓
Agents
   ↓
Corporate Knowledge
   ↓
Policies & Approvals
   ↓
Tools
   ↓
SAP and enterprise systems

For SAP environments in particular, this creates the foundation for agents that can understand custom code, investigate incidents, implement changes and interact with enterprise systems - while remaining inside a governed execution architecture.

The objective is not to remove humans from SAP engineering.

It is to give engineers increasingly capable autonomous systems without giving up enterprise control.

The strategic question for CIOs

Enterprises are currently asking:

Which AI tools should we give our employees?

That is an important question.

But it may not be the question that matters most over the next few years.

A more important question could be:

What is the architecture through which AI agents will operate inside our company?

Because once agents can read corporate knowledge, access SAP, modify code and execute business processes, they become part of the enterprise technology landscape.

And infrastructure this powerful should belong to the enterprise - not to an individual AI session.

---

We are currently developing AgentOS - an enterprise runtime designed to connect AI agents with SAP systems, corporate knowledge and governed execution. Stay tuned.