HowAIAgentsActuallyConnecttoSAP:APIs,RFC,ADT,MCPandBeyond

Connecting an AI agent to SAP is not one problem

“Connect an AI agent to SAP” sounds simple.

It is not.

An agent that checks the status of a sales order has very different technical requirements from an agent that investigates a production incident.

And both are fundamentally different from an engineering agent expected to:

• understand custom ABAP,
• inspect dependencies,
• find the cause of an error,
• modify a class,
• execute tests,
• analyze ATC results,
• and prepare a change for transport.

All of these scenarios can be described as:

AI connected to SAP.

But architecturally, they are completely different.

For enterprises evaluating AI agents around SAP, the first question therefore should not be:

Which LLM should we use?

It should be:

What exactly should the agent be able to see and do inside SAP?

Once this is defined, the integration architecture becomes much clearer.

Start with capabilities, not protocols

Before choosing OData, RFC, MCP or any other technology, define the capabilities required by the agent.

We can roughly divide SAP agent interaction into five levels.

This distinction is important.

Traditional SAP integrations are primarily designed for Levels 1 and 2.

AI engineering agents increasingly require Levels 3, 4 and 5.

That changes which interfaces become interesting.

1. OData and REST APIs

For many business scenarios, APIs are the most natural integration layer.

SAP S/4HANA exposes business capabilities through APIs that can be consumed by external applications and agents.

An agent could use an API to:

• retrieve a Business Partner,
• check an order,
• create or update business objects,
• query master data,
• initiate a defined business operation.

The architecture is straightforward.

This is a strong architecture when the agent should operate on clearly defined business capabilities.

The API creates an important boundary.

The agent does not receive unrestricted access to the SAP system. It receives a defined operation with defined parameters.

For enterprise agent architectures, that is often exactly what we want.

Where APIs work particularly well

APIs are well suited to agents performing business operations.

For example:

Find Business Partner 10000421 and summarize its current status.

or:

Retrieve all open sales orders for customer X.

or:

Create a service request using the information from this email.

The agent reasons about the task.

The tool executes a deterministic API operation.

This separation is powerful:

LLM
decides what should happen

↓

Tool
defines what is allowed to happen

↓

SAP API
executes the business operation

The LLM does not need to understand the technical implementation of SAP.

It only needs to understand the contract of the tool.

But APIs do not expose the whole SAP system

The limitation becomes visible when the question changes.

Imagine asking:

Why does this custom billing process fail for this specific contract?

The answer might require inspecting:

• a custom ABAP class,
• a BAdI implementation,
• customizing,
• a CDS view,
• application logs,
• AIF messages,
• a transport from six months ago,
• and the Jira ticket that introduced the change.

A business API will not necessarily expose this information.

This is where technical agents require a different integration layer.

2. RFC and BAPI

RFC remains deeply embedded in SAP landscapes.

Many ECC and S/4HANA environments already expose functionality through:

• RFC-enabled function modules,
• BAPIs,
• custom remote-enabled functions.

This makes RFC especially relevant when introducing agents into existing SAP landscapes.

A controlled tool might expose something like:

get_customer_account(customer_id)

get_open_items(contract_account)

get_aif_messages(interface, status)

execute_business_operation(parameters)

The agent does not need generic RFC access.

Instead, selected SAP capabilities are wrapped as agent tools.

This is especially valuable for legacy ECC environments where modern APIs may not cover everything required.

3. SAP BTP as the connectivity layer

In many enterprise landscapes, the AI runtime should not connect directly to every SAP system.

SAP BTP can provide an intermediary connectivity layer.

A typical architecture can look like this:

This architecture has several advantages.

Connectivity can be managed centrally.

Credentials do not need to be distributed across individual agents.

The agent runtime can use predefined destinations rather than maintaining system-specific connection configuration.

For on-premise systems, the existing BTP connectivity architecture can become the bridge between the agent platform and the SAP landscape.

But BTP is not mandatory

Not every SAP customer uses BTP.

This is particularly important in existing ECC environments.

An enterprise agent architecture therefore should not assume that every SAP system is accessible through SAP BTP.

A second deployment model is direct controlled connectivity.

The gateway can expose only explicitly allowed operations.

This provides a useful architecture for customers who:

• operate primarily on-premise,
• do not use BTP,
• cannot expose SAP externally,
• or require the agent runtime to remain inside their corporate network.

The important design principle is not whether BTP exists.

It is whether the agent reaches SAP through a controlled execution boundary.

4. ADT: when the agent needs to understand ABAP

For an SAP development agent, business APIs are not enough.

The agent needs access to the development environment.

This is where the interfaces behind ABAP Development Tools - ADT become particularly interesting.

ADT provides structured access to the ABAP development environment.

Instead of treating ABAP simply as text files, an engineering agent can potentially work with actual SAP repository objects.

Conceptually:

This is a fundamentally different capability from calling an OData API.

The agent can start operating in the same technical environment used by SAP developers.

Depending on the available tooling and permissions, the agent may be able to work with repository objects such as:

• classes,
• interfaces,
• programs,
• CDS objects,
• dictionary definitions,
• packages,
• development objects,
• syntax checks,
• activation,
• and development metadata.

Now the agent is no longer only consuming SAP.

It is starting to engineer SAP.

From source code access to system understanding

Simply giving an LLM thousands of ABAP files is not enough.

A useful SAP engineering agent needs to understand relationships.

Consider a custom class:

ZCL_BILLING_PROCESS

The interesting questions are not only:

What does this code do?

But also:

• Who calls it?
• Which interface does it implement?
• Which DDIC structures does it use?
• Which CDS views provide its data?
• Is it part of a BAdI implementation?
• Which custom tables does it update?
• Which tests cover it?
• Which transport introduced the last change?
• Which incident or requirement explains why this logic exists?

This is where structured development access becomes far more valuable than simply copying source code into an LLM context window.

5. Git and abapGit

Git introduces another interesting integration model.

If ABAP source code is synchronized with a Git repository, an AI coding agent can operate using the same tools already common in modern software engineering.

This gives agents excellent access to:

• source code,
• version history,
• diffs,
• branches,
• pull requests,
• reviews.

It also enables established software engineering workflows around AI-generated changes.

However, Git represents only part of the SAP environment.

A repository does not automatically provide complete runtime information about:

• customizing,
• system configuration,
• production data,
• application logs,
• runtime errors,
• active dependencies,
• transport state.

For advanced SAP agents, Git therefore works best as one source among several.

6. MCP: turning SAP capabilities into agent tools

One of the most important developments in agent architecture is the emergence of tool protocols such as the Model Context Protocol (MCP).

The architectural idea is simple.

Instead of building custom integration logic for every combination of agent and enterprise system, capabilities can be exposed through a standardized tool interface.

Conceptually:

The agent might see tools such as:

search_abap_objects()

read_abap_class()

find_references()

read_table_metadata()

run_atc_check()

get_application_log()

get_aif_message()

activate_object()

From the agent’s perspective, these are capabilities.

The MCP server handles communication with the underlying SAP interfaces.

Why MCP matters

MCP can create a separation between three layers:

AI Agent
Reasoning

↓

MCP / Tool Layer
Capabilities

↓

SAP Integration Layer
ADT / APIs / RFC / other interfaces

↓

SAP System
Execution

This is important because the agent does not need to understand every low-level communication mechanism.

The tool can hide that complexity.

The same agent could potentially work with:

• SAP,
• GitHub,
• Jira,
• ServiceNow,
• documentation systems,

through a consistent tool-oriented model.

MCP does not automatically solve security

There is an important caveat.

Making SAP functionality available through MCP does not automatically make the architecture enterprise-safe.

An MCP server exposing:

execute_arbitrary_function()

is very different from one exposing:

read_abap_object()

and:

request_transport_creation()

The quality of the security architecture depends on how capabilities are designed.

This leads to a critical principle:

Do not expose SAP connectivity to the agent. Expose controlled SAP capabilities.

The distinction is subtle but fundamental.

Which channel for which job

No single technology replaces the others. Advanced SAP agents will often combine several of them.

7. Combining multiple channels

The most capable SAP agents will probably not use a single integration mechanism.

They will combine several.

Consider an incident:

Billing documents fail for customers migrated last weekend.

The agent may need to:

1. retrieve the incident from ServiceNow,
2. inspect related deployment information,
3. query AIF errors,
4. inspect relevant ABAP code,
5. find recent Git changes,
6. inspect configuration,
7. identify the likely defect,
8. propose a code change,
9. run tests,
10. prepare the change for human approval.

No single SAP API is likely to provide all of this.

The architecture becomes multi-tool.

This is much closer to how a human SAP consultant actually works.

A consultant does not solve a complex production problem by looking at one API response.

They move between systems, code, documentation, tickets and runtime information.

An effective agent needs similar reach.

Read access and write access should be separate

Another important architectural principle is to distinguish analysis from execution.

An agent may receive broad read access while write operations remain heavily restricted.

For example:

This allows agents to perform extensive autonomous analysis without automatically giving them autonomous execution authority.

For enterprise SAP environments, this distinction can significantly reduce risk.

Production should be treated differently

An agent working in DEV is not the same as an agent operating in PROD.

The runtime should understand the target system.

For example:

Environment	Agent capability
DEV	Read + controlled development
QA	Read + testing
PRE-PROD	Read + validation
PROD	Primarily read / diagnostics
PROD sensitive actions	Explicit approval or prohibited

The important point is that these rules should be enforced by infrastructure.

They should not depend only on the agent deciding to behave correctly.

The SAP Agent Architecture

Putting everything together produces an architecture that looks less like a chatbot integration and more like an enterprise development platform.

This is the architecture we find particularly interesting at Codemine.

The LLM is only one component.

The real platform consists of:

reasoning + enterprise knowledge + tools + SAP connectivity + policies + approvals + audit.

Example: an ABAP incident handled by an agent

Imagine a production incident:

Provider Contract creation fails after the latest deployment.

The agent receives the incident.

Step 1 - Understand the context

It retrieves:

• incident description,
• previous related incidents,
• architecture documentation,
• deployment history.

Step 2 - Inspect SAP

Through controlled SAP tools it retrieves:

• error messages,
• application logs,
• AIF messages,
• relevant object metadata.

Step 3 - Analyze custom code

Using development tooling, it:

• identifies the relevant ABAP implementation,
• follows dependencies,
• finds a recent change,
• compares it with the failing scenario.

Step 4 - Build a hypothesis

The agent determines that a new mapping condition does not handle a specific contract type.

Step 5 - Prepare the change

It creates a proposed modification.

Step 6 - Validate

It executes:

• syntax validation,
• ATC,
• unit tests,
• relevant scenario tests.

Step 7 - Request approval

The engineer receives:

Incident:
INC-4821

Root cause:
Missing handling of contract type X
introduced by change Y.

Objects affected:
ZCL_PROVIDER_CONTRACT
ZIF_CONTRACT_MAPPING

Proposed change:
2 objects

Validation:
Syntax: PASS
ATC: PASS
Tests: 18/18 PASS

Risk:
Medium

[Review Diff]
[Approve]
[Reject]

The agent did most of the investigation.

The human still controls the critical decision.

That is very different from simply placing a chatbot next to SAP.

AgentOS and SAP connectivity

At Codemine, we are developing AgentOS around this architectural model.

AgentOS does not assume there is one universal SAP connector.

Different customers have different landscapes.

One customer may operate modern S/4HANA and BTP.

Another may operate a heavily customized ECC system inside a restricted corporate network.

Another may use ABAP Cloud together with Git-based development workflows.

Therefore the architecture needs to support multiple controlled paths between agents and SAP.

The integration technology is selected according to the task and customer landscape.

The governance model remains consistent.

The important distinction: accessing SAP vs understanding SAP

This is perhaps the most important distinction.

Giving an AI agent an API does not mean the agent understands the SAP system.

Enterprise SAP landscapes may contain:

• millions of lines of custom ABAP,
• thousands of repository objects,
• decades of transports,
• custom interfaces,
• customer-specific configuration,
• undocumented dependencies,
• historical business decisions.

The next generation of SAP agents needs to move beyond:

“I can call SAP.”

toward:

“I understand how this SAP system works.”

Connectivity is only the first layer.

System understanding is the real challenge.

And once an agent combines that understanding with controlled execution, something much more interesting becomes possible:

an AI engineer that can work with an existing SAP landscape rather than only talk about SAP.

What comes next

The next architectural question is therefore not how to connect an LLM to SAP.

We already have multiple ways to do that.

The harder problem is:

How do we give an agent enough access to understand a complex SAP landscape while keeping its actions controlled, auditable and reversible?

That is where SAP engineering, enterprise AI architecture and agent governance begin to converge.

And it is where we believe the most interesting evolution of SAP development will happen.