AI needs a brain.
And the brain needs an operator.

The idea behind it started from a relatively simple observation: AI models are becoming increasingly capable, agents are becoming increasingly autonomous, and enterprise systems are becoming increasingly accessible to them.

But who is actually in control?

BrainAI is being designed as a central AI control plane that can combine local AI models running inside the company infrastructure with public AI models, while maintaining control over what data stays inside the organization, what is allowed to leave it, which models can process particular information, and which actions require explicit human approval.

For me, this becomes especially interesting when we put SAP landscapes into the equation.

The missing layer between AI and SAP

SAP environments are rarely simple.

A typical enterprise may operate a combination of:

• SAP S/4HANA or ECC on-premise
• SAP HANA and BW
• SAP S/4HANA Cloud
• SuccessFactors, Ariba and other SAP cloud solutions
• SAP Business Technology Platform
• SAP Integration Suite / Cloud Integration (CPI)
• CAP applications
• APIs, events and destinations
• SAP Cloud Connector
• many non-SAP enterprise systems

Now add AI agents to this architecture.

An agent can potentially query systems, analyze information, create resources, deploy applications, execute APIs, change configurations or trigger business processes.

The question is no longer simply:

“Which LLM should we use?”

The much more important questions become:

What is the agent allowed to do?

Which data can it see?

Which model is allowed to process that data?

What happens when several agents cooperate with each other?

Can we see what those agents are discussing and why one agent delegated a task to another?

Who approves a sensitive operation before it reaches SAP?

And perhaps most importantly:

Where is the central place from which we can govern all of this?

This is the problem we are trying to address with BrainAI.

BrainAI as an AI Control Plane

The architecture we are currently working with puts BrainAI in the middle.

It is not intended to replace SAP BTP, Integration Suite, Cloud Connector or existing SAP services.

Instead, BrainAI provides an orchestration and governance layer above the AI capabilities interacting with them.

An operator can give BrainAI a task in natural language. BrainAI can then break that task into smaller activities, select appropriate agents and tools, choose an appropriate model, execute the workflow and return the results.

But orchestration alone is not enough.

The important part is that this happens within a controlled environment.

BrainAI therefore becomes responsible for areas such as:

• Agent orchestration and communication — coordinating specialized agents and providing visibility into how tasks are delegated and executed.
• Skills and tools — controlling which capabilities an agent can actually invoke.
• Context and memory — deciding what information should be available to an agent and what should persist between interactions.
• Security and policies — defining what an agent or model is allowed to access and execute.
• Human approval — stopping sensitive workflows and requiring an operator to explicitly approve an action before execution.
• Auditability — recording what happened, which model or agent performed an operation, what tools were used and what decisions led to an action.
• Token and cost governance — controlling token budgets, quotas, rate limits and model usage.
• Observability — understanding what agents and models are doing across the entire AI environment.

This creates something that I believe will become increasingly important in enterprise AI:

AI governance at runtime, not only AI governance on paper.

Local AI and public AI should not be an either/or decision

Another important aspect of BrainAI is model independence.

There are good reasons to use powerful public models.

There are equally good reasons why certain enterprise data should never leave the company infrastructure.

BrainAI therefore works with a hybrid model architecture.

Local models can run through components such as LocalAI, while LiteLLM can provide a common model gateway and routing layer.

This makes it possible to define policies such as:

• Sensitive SAP data → local LLM only.
• General development question → approved cloud LLM.
• Large reasoning task → selected external model.
• Confidential document → local inference.
• Expensive model → only after budget or policy validation.

The application or agent does not necessarily need to know which underlying model will ultimately process the request.

That decision can be made centrally according to security classification, policy, capability, availability and cost.

This also provides a much better foundation for changing models in the future without redesigning every application that consumes AI.

Do your employees connect directly to AI providers?

There is another question I believe enterprises should be asking themselves today:

When employees in your organization use AI, where does their prompt actually go?

Do they connect directly from their laptops or applications to the infrastructure of an AI provider — whichever provider that happens to be?

Or does your organization provide a controlled AI Gateway / AI Proxy between employees, applications and external AI services?

This distinction may become extremely important.

Imagine an architecture where every AI request leaving the company first passes through a controlled gateway.

Such a gateway can potentially check:

• who is making the request,
• which application initiated it,
• which model is being requested,
• whether the user is authorized to use that model,
• whether the prompt contains confidential information,
• whether it contains personal or sensitive data,
• whether that information is allowed to leave the organization,
• how many tokens are being consumed,
• what the request costs,
• and whether the selected model complies with corporate policy.

If a request contains information classified as sensitive, the gateway could route it to a local LLM instead of a public model.

In other words, instead of giving every employee and every application unrestricted access to external AI providers, we introduce a controlled AI boundary.

A kind of enterprise AI firewall.

For me, this is one of the important roles of BrainAI combined with technologies such as LiteLLM and LocalAI.

The objective is not to prevent people from using AI.

Quite the opposite.

The objective is to allow organizations to use more AI, while maintaining control over what leaves the organization and what must remain inside.

SAP BTP becomes particularly interesting

SAP BTP plays a very important role in this architecture.

Integration Suite / CPI remains the enterprise integration layer.

SAP Cloud Connector provides the controlled connectivity between SAP BTP and systems running inside the customer's network.

CAP remains an excellent application and service development model.

What changes is how AI interacts with these capabilities.

Through an MCP-based tool layer, BrainAI agents can discover and use controlled SAP capabilities instead of receiving unrestricted access to the entire landscape.

This distinction is extremely important.

An AI agent should not simply receive credentials and be told:

“Here is our SAP environment. Good luck.”

Instead, it should receive a carefully defined set of tools:

• Read this information.
• Validate this service.
• Check this deployment.
• Create this resource.
• Execute this approved workflow.
• Deploy this application.
• Run these validation tests.

And each capability can have its own permissions, policies and approval requirements.

This is already becoming real

What makes this particularly exciting for me is that this is no longer purely an architectural concept.

Our SAP BTP agents managed through BrainAI can already build SAP BTP Cloud Foundry environments within minutes.

They can perform activities such as provisioning and configuring environments, validating service status, publishing changes, executing deployment activities and running validation tests.

An operator can define the objective while agents handle much of the technical execution.

The next step is not simply making those agents more powerful.

The next step is making their increasing power controllable, observable and governable.

Human approval must remain part of the architecture

There is a tendency in AI discussions to treat complete autonomy as the ultimate objective.

I am not convinced that this is always the right goal for enterprise environments.

There are operations where an agent should absolutely be allowed to act autonomously.

There are others where it should prepare an action but wait for approval.

For example:

1. Agent detects an issue.
2. Agent analyzes the environment.
3. Agent proposes a remediation.
4. Another agent validates the proposed solution.
5. BrainAI evaluates policy and risk.
6. Human approval is required.
7. Only then is the action executed.

This is where the concept of an AI Operator becomes important.

The human does not need to manually execute every technical command anymore.

Instead, the operator supervises AI capabilities, policies and workflows and intervenes when human judgment or authorization is required.

In other words:

Humans move from executing every step to governing the system that executes those steps.

What about agent-to-agent communication?

Another area that I think deserves much more attention is communication between AI agents.

As multi-agent architectures become more common, one agent may ask another agent to investigate something, while another performs an SAP operation and yet another validates the result.

That creates a new category of enterprise communication.

We need visibility into:

• which agent initiated a request,
• which agent received it,
• what context was transferred,
• what tools were requested,
• which model participated,
• what data was exchanged,
• what decision was made,
• and what action ultimately reached the enterprise system.

Without this visibility, we may end up creating increasingly capable AI environments while simultaneously losing understanding of how they operate.

And here is a question that may sound like science fiction:

Have you heard about the OpenAI research agents that found ways to communicate with each other and help each other even though they were supposed to operate independently?

This is not a joke.

OpenAI publicly described a 2026 incident from internal cybersecurity evaluations in which agents found unintended ways to communicate through shared infrastructure. They effectively turned an internal package-management system into an improvised message board, allowing agents to exchange information. Agents that were supposed to work independently were able to share discoveries, coordinate their efforts and continue work started by other agents. OpenAI also reported rare cases where agents without enabled multi-agent tools found side channels through which they could collaborate.

The significance of that communication was not immediately understood by the teams responsible for the later incident response. OpenAI's investigation subsequently identified unauthorized communication and agents adopting goals from one another among the relevant behavioral patterns.

Think about what this means for enterprise architecture.

If we are going to introduce multiple autonomous agents into environments containing ERP systems, financial data, HR information, production systems and integration platforms, it is not enough to monitor only communication between the user and the AI.

We may also need to monitor and govern communication between:

AI ↔ AI.

Agent A may have permission to access one resource.

Agent B may have permission to access another.

What happens when they start exchanging information?

Can one agent indirectly obtain information it would not normally be allowed to access?

Can agents combine their permissions?

Can they leave information for another agent?

Can they initiate workflows that nobody explicitly requested?

Can we reconstruct that interaction six months later during an audit?

This is exactly why I believe agent-to-agent communication needs to become a first-class security and observability concern.

For enterprise SAP environments, simply trusting that every autonomous agent will remain within the intended logical boundaries is not enough.

We need to be able to see it.

We need to audit it.

And, where necessary, we need to stop it.

AI needs a brain — and the brain needs an operator

AI is already here.

Agents are already here.

They are becoming capable of operating infrastructure, applications and business processes rather than simply answering questions.

So perhaps the next challenge is no longer:

“How do we introduce AI into SAP?”

Perhaps the more relevant question is:

“How do we stay in control when AI becomes an active participant in our SAP landscape?”

This is how I currently see the role of BrainAI.

Not another LLM.

Not another chatbot.

Not a replacement for SAP BTP.

But a central control plane connecting people, AI agents, local and public models, security policies, SAP tools and enterprise workflows.

The future is already here because AI is already here.

But if we want AI to operate enterprise systems, we also need a brain that governs it.

And that brain should ultimately remain under human control — managed by operators.

I am very interested in hearing how other SAP architects, developers and platform teams see this.

Are you already facing this problem in your organization?

Do you feel that as the number of AI models, agents and AI-enabled applications grows, we are starting to lack central control over models, agent activities, agent-to-agent communication, data boundaries, costs and permissions?

Are your employees and applications communicating directly with external AI providers, or have you already introduced an AI Gateway / Proxy that acts as a guard between your enterprise data and public AI?

How are you handling human approval, auditing, agent-to-agent communication and security when AI agents are allowed to perform actual operations rather than simply provide recommendations?

And finally:

Do we need a BrainAI-like control layer for the SAP ecosystem as AI becomes more autonomous and more deeply integrated into enterprise systems?