SAP Agentic AI Explained: From Copilot to Autonomous Agents

SAP Is Not Adding AI. It Is Replacing How Work Gets Done.

There is a lot of noise around AI in SAP right now. Most of it misses what is actually happening.

SAP is not bolting a chatbot onto your ERP. It is moving toward systems that do not just respond to you. They act on your behalf.

Here is what that looks like in practice. You tell Joule to create a purchase order for 500 units of raw material. In the old model, Joule generates a form for you to fill in, maybe pre-populates some fields. Helpful, but you are still the one doing the work.

In the new model, an agent checks inventory levels across plants, validates the vendor's compliance status and contract terms, creates the PO against the correct contract, triggers the approval workflow based on your organization's rules, and notifies the requester. You supervise. You approve. But the agent does the work.

That is a fundamentally different model. And SAP is building it into the core of their platform, not shipping it as a feature on top.

We covered Joule as a copilot in depth. That post is about what Joule can do for you today: generate ABAP, explain code, create CDS views. This post is about what comes next. Joule is evolving from a copilot that answers your questions into an orchestrator that coordinates autonomous agents to complete your goals.

If you want the strategic case for why AI entrenches SAP rather than replacing it, we covered that too. This post is the tactical and architectural complement: what agentic AI actually is, how SAP is implementing it, and what you need to know to build with it.

Agentic AI vs. AI Agents -- The Distinction That Matters

These two terms get used interchangeably. They should not be.

Agentic AI is the paradigm. It is the idea that AI systems can take a goal, break it into steps, reason about what to do next, execute actions, handle errors, and iterate until the goal is achieved. It is a design philosophy. A way of thinking about what AI should be capable of.

AI Agents are the implementations. They are discrete software components that operate within the agentic paradigm. Each agent has a specific scope, defined tools it can use, guardrails it must respect, and a role within a larger workflow.

Why does this matter? Because the distinction determines how you architect solutions.

If you think of agentic AI as a single monolithic capability ("the AI handles everything"), you will build fragile, ungovernable systems. If you think of it as a coordination layer across specialized agents, each with clear responsibilities and boundaries, you build something that can actually run in a production SAP landscape.

Consider the analogy to SAP's own architecture. SAP does not have a single program that handles all of procurement. It has discrete transactions, BAPIs, workflows, and authorization objects that work together. Agentic AI follows the same principle: specialized components, orchestrated intelligently.

Here is how the models compare:

The copilot model is not going away. You will still ask Joule to generate code, explain a function module, or create a CDS view. But the agentic model layers on top of it. Joule becomes both the assistant you talk to and the orchestrator that dispatches work to specialized agents.

How SAP Is Building Agentic AI Into the Core

This is not an experimental feature in a sandbox. SAP is embedding agentic capabilities into the platform architecture.

If you look at SAP's reference architecture for AI, one thing stands out immediately: Joule sits at the center as the orchestrator. It is not a sidebar assistant anymore. It is the routing layer. It receives requests, determines which agents or skills should handle them, coordinates the execution, and aggregates results back to the user.

This is a deliberate architectural decision that aligns with two other major SAP strategies:

Clean Core. The Clean Core architecture says keep your SAP core standard and push custom logic to the extension layer. Agents fit this model perfectly. Instead of embedding custom automation into the SAP core through modifications and enhancements, you build agents that interact with the core through APIs. The core stays clean. The intelligence lives in the agent layer.

BTP as the Extension Platform. SAP BTP is where agents run. Joule Studio, the SAP Cloud SDK for AI, and the agent runtime all live on BTP. If you have been investing in BTP skills, you are already positioned for the agentic shift. If you have been ignoring BTP, this is another reason to stop.

The technical architecture looks like this:

1. User request comes in through Joule (natural language or structured)
2. Joule classifies intent and determines which agent or agents should handle the request
3. Joule dispatches to one or more specialized agents
4. Agents execute their tasks, potentially calling other agents or SAP APIs
5. Results aggregate back through Joule to the user
6. Human-in-the-loop checkpoints fire where governance rules require approval

This is not theoretical. SAP has been rolling out agent capabilities through Joule throughout 2025 and into 2026. The 2026 releases bring multi-agent orchestration, A2A communication, and the two builder paths (Joule Studio and Cloud SDK for AI) that make this accessible to both functional consultants and developers.

What makes this different from previous SAP AI initiatives (remember Leonardo?) is that it is not a separate product you have to buy and integrate. It is built into the products you are already using. Joule is already in S/4HANA Cloud, BTP, Build Code, SuccessFactors, and Ariba. The agentic capabilities extend what is already there.

The Purchase Order Example -- Anatomy of an Agentic Workflow

Abstract architecture is useful, but let us walk through a concrete example to see what this actually looks like in practice.

A procurement manager needs to create a purchase order for 500 units of a raw material from an approved vendor. Here is how this works today versus how it works with agents.

The Manual Process Today

1. Open ME21N. Select the correct document type, purchasing organization, and purchasing group.
2. Switch to MMBE or MD04 to check available stock across plants. Determine that you actually need the material.
3. Open XK03 or your vendor master report to verify the vendor is still approved and their compliance certificates are current.
4. Go back to ME21N. Enter the vendor, material, quantity, delivery date, and pricing manually. Reference the correct outline agreement if applicable.
5. Save the PO. The system triggers a workflow notification to the approver.
6. Wait. The approver might not see the notification for hours or days.
7. Once approved, manually notify the requester that the PO has been created.

Total elapsed time: 30 to 45 minutes of active work, plus hours or days of wait time for approvals and notifications. This assumes the user knows which transactions to use, which fields matter, and which vendor to select. A new employee might take twice as long or make errors that require correction.

The Agent-Driven Process

1. User tells Joule: "Create a purchase order for 500 units of material 12345 from our standard vendor."
2. Inventory Agent checks ATP across all relevant plants. Confirms the material is needed and not available in sufficient quantity elsewhere.
3. Compliance Agent validates the vendor's status: approved, contracts current, compliance certificates valid.
4. Procurement Agent creates the PO with the correct document type, purchasing org, outline agreement reference, and pricing conditions.
5. Approval Agent routes the PO through the correct approval chain based on value thresholds and organizational rules. If the approver is available, the approval can happen in real time.
6. Notification Agent sends the requester a confirmation with the PO number and expected delivery date.

Total elapsed time: 2 to 5 minutes, mostly automated. Human intervention only at the approval checkpoint.

Where Humans Stay in the Loop

This does not mean full automation with no oversight. The governance model matters. Here is where human checkpoints should exist:

• Value thresholds: POs above a certain amount require human approval. The agent routes it, but a person decides.
• New vendors: First-time vendor selection should involve human review even if the agent recommends one.
• Exception handling: When the agent encounters something outside its rules (unusual material, conflicting contracts, compliance flags), it escalates rather than guessing.
• Audit trail: Every agent action is logged. The procurement manager can review the full chain of what happened and why.

The goal is not to remove humans from procurement. It is to remove the mechanical work so humans can focus on the decisions that actually require judgment.

Joule as Orchestrator -- Not Just a Chatbot Anymore

If you have been using Joule as a copilot, you already know one version of it: you ask a question, it answers. You give it a prompt, it generates code. That version is not going away.

But Joule's role is expanding into something more fundamental. In the agentic architecture, Joule is the orchestration layer that sits between the user and the agents. It decides what needs to happen and who should do it.

How Joule Routes Requests

When you give Joule a complex instruction, it does not try to handle everything itself. It:

1. Classifies your intent: Is this a simple question (copilot mode), a single task (skill execution), or a multi-step goal (agent orchestration)?
2. Selects the right agents: Based on the task, Joule identifies which specialized agents are needed and in what order.
3. Manages the workflow: Joule coordinates execution across agents, handles dependencies (Agent B cannot start until Agent A completes), and manages failures.
4. Aggregates results: Once agents complete their work, Joule compiles the results into a coherent response or status update for the user.

Agent-to-Agent Communication

Here is where it gets interesting. Agents do not just receive instructions from Joule. They can communicate with each other.

In the purchase order example, the Procurement Agent does not wait for the user to confirm the inventory check. The Inventory Agent passes its results directly to the Procurement Agent. The Compliance Agent runs in parallel. Joule orchestrates the timing and dependencies, but the agents communicate the data.

This is what SAP calls the A2A (Agent-to-Agent) protocol, and it enables workflows that would be impossible if every step required a round trip back to the user.

What This Means for the Joule You Know

If you are already using Joule for ABAP generation, CDS views, or debugging (and if you are not, start here), the copilot capabilities remain exactly the same. The agentic layer is additive. Think of it as Joule gaining a new mode:

• Copilot mode: You ask, it answers. Same as today.
• Skill mode: You invoke a pre-built skill (like "create a CDS view"), and Joule executes it.
• Agent mode: You set a goal, and Joule orchestrates multiple agents to achieve it.

You do not have to choose between these. Joule determines the right mode based on the complexity of your request.

Two Paths to Build Agents

SAP has made it clear that they want both functional consultants and developers building agents. To support this, they provide two distinct paths.

Path 1: Joule Studio (Low-Code)

Joule Studio is a visual agent builder designed for people who understand SAP business processes but do not write code for a living.

How it works:

You define what the agent should do through a visual interface. You specify the steps, the data the agent needs, the conditions that determine branching, and the actions it should take. Much of the heavy lifting -- connecting to SAP APIs, handling authentication, managing state -- is handled for you.

Who it is for:

Functional consultants, process owners, citizen developers, and anyone who can map a business process but does not want to write Python to automate it.

What you can build:

• Approval workflow agents that route based on complex business rules
• Data validation agents that check master data quality across modules
• Vendor onboarding agents that orchestrate creation, compliance, and approval steps
• Reporting agents that compile data from multiple sources on a schedule
• Monitoring agents that watch for specific conditions and alert or act

Strengths:

• Fast to build. Days, not weeks.
• No coding required. The visual designer handles the logic.
• Governed by default. SAP's security model, authorization checks, and audit logging are built in.
• Maintained by SAP. As APIs change, the connectors update.

Limitations:

• Constrained to SAP-provided connectors and actions. If the API you need is not available, you cannot call it.
• Complex conditional logic can get unwieldy in a visual designer.
• Limited ability to integrate with non-SAP systems directly.

Path 2: SAP Cloud SDK for AI (Pro-Code)

This is the developer path. Full control, full responsibility.

How it works:

You write agents in Python or TypeScript using the SAP Cloud SDK for AI. You define the agent's goal, its available tools, its reasoning patterns, and its integration points. You can plug in agentic frameworks like LangGraph or CrewAI for more sophisticated orchestration patterns.

Who it is for:

Developers, technical architects, and anyone who needs to build agents that go beyond standard SAP process automation.

What you can build:

• Agents that integrate SAP with external systems (CRM, logistics, banking APIs)
• Multi-model agents that use different LLMs for different tasks
• Complex reasoning agents that handle edge cases with custom logic
• Agents that interact with non-SAP data sources (data lakes, third-party APIs, legacy systems)
• Custom orchestration patterns that go beyond what Joule Studio supports

Example -- agent definition in TypeScript:

import { Agent, Tool } from '@sap-ai-sdk/agents';

const inventoryCheckTool = new Tool({
  name: 'check_inventory',
  description: 'Check available stock for a material across plants',
  execute: async ({ materialId, plant }) => {
    return await s4Client.getAvailableStock(materialId, plant);
  }
});

const vendorValidationTool = new Tool({
  name: 'validate_vendor',
  description: 'Validate vendor compliance and contract status',
  execute: async ({ vendorId }) => {
    return await s4Client.getVendorComplianceStatus(vendorId);
  }
});

const procurementAgent = new Agent({
  name: 'procurement-agent',
  goal: 'Create purchase orders based on material requirements',
  tools: [inventoryCheckTool, vendorValidationTool, poCreationTool],
  orchestrator: 'joule',
  approvalRequired: true,
  maxRetries: 3
});

This is simplified, but it shows the pattern. You define tools (the actions the agent can take), wire them into an agent with a stated goal, and register the agent with Joule as the orchestrator. The approvalRequired flag ensures human-in-the-loop governance.

Strengths:

• Full flexibility. If you can code it, you can build it.
• Use any LLM. Not locked into SAP's model choices.
• Integrates with open-source frameworks (LangGraph, CrewAI, LangChain).
• Can handle non-SAP systems and complex integration patterns.

Limitations:

• Requires development expertise. This is not a citizen developer tool.
• More governance overhead. You own the security, testing, and monitoring.
• Longer development cycles compared to Joule Studio.

Which Path Should You Choose?

The honest answer for most organizations: start with Joule Studio. If you hit a wall where you need more flexibility, move to the Cloud SDK. The two paths are not mutually exclusive. You can build some agents visually and others in code, and they all register with Joule as the orchestrator.

A2A Protocol -- How Agents Talk to Each Other

Agents are only useful if they can work together. A procurement agent that cannot check inventory is just a form filler. An approval agent that cannot read the PO details is useless. This is where A2A comes in.

A2A (Agent-to-Agent) is a standardized protocol for inter-agent communication. SAP has aligned with Google's open A2A protocol, which is quickly becoming an industry standard. This is not an SAP-only thing. It is an interoperability standard that allows agents from different vendors and platforms to communicate.

What A2A Enables

• Capability discovery: An agent can discover what other agents exist and what they can do. The procurement agent knows that an inventory agent exists and can be called for stock checks.
• Standardized message format: Agents communicate through structured messages, not free-form text. This makes interactions predictable and debuggable.
• Task delegation: One agent can delegate a subtask to another agent and receive structured results back.
• Cross-system communication: An SAP agent can communicate with an agent running in a completely different system, a logistics platform, a banking API, a third-party compliance service.

Why This Matters Practically

Without A2A, every agent integration is a custom point-to-point connection. With 5 agents, that is 10 possible connections. With 20 agents, that is 190. This does not scale.

A2A gives you a standardized communication layer. Agents publish their capabilities. Other agents discover and invoke them through a common protocol. You add a new agent, and existing agents can immediately work with it.

For SAP specifically, A2A means:

• Internal orchestration: SAP agents within your landscape can coordinate through Joule without custom integration code.
• Partner ecosystem: Third-party vendors can build agents that plug into your SAP-orchestrated workflows through A2A.
• Hybrid architectures: You can build an agent in CrewAI running on your own infrastructure that communicates with SAP Joule-orchestrated agents through A2A. This is critical for organizations that need to integrate SAP with non-SAP AI capabilities.

The protocol is still maturing, but the direction is clear. Agent interoperability is not optional. It is the foundation that makes the agentic paradigm work at scale.

What This Means for SAP Consultants and Admins

The biggest shift here is not technical. It is how you think about building in SAP.

The old mental model: "Which app should I build? Which transaction should I create? Which Fiori tile should I configure?"

The new mental model: "What agent should handle this?"

Every repetitive business process is a candidate for an agent. Every manual workflow that follows predictable rules. Every monitoring task that someone does by checking the same dashboards every morning. These are all agent opportunities.

Skills to Develop Now

For functional consultants:

• Learn Joule Studio. Build a simple agent in a sandbox. The barrier to entry is low, and the experience of thinking in agent terms (goals, tools, guardrails) is more valuable than any specific technical skill.
• Map one client process end-to-end as an agent workflow, even on paper. The exercise of decomposing a business process into agent-sized components is the critical skill.
• Understand the governance model. Who approves what? Where do humans stay in the loop? These are the questions clients will ask you.

For developers and technical architects:

• Read the SAP Cloud SDK for AI documentation. Even if you do not build an agent today, understand the programming model.
• Experiment with LangGraph or CrewAI independently. The patterns transfer directly to SAP's pro-code path.
• Learn the A2A protocol basics. Agent interoperability will become a standard architecture concern.

For Basis admins:

• Agent monitoring and governance will become part of your scope. Agents generate logs, consume resources, and need performance tuning just like any other workload.
• Understand BTP resource management. Agents run on BTP, and the operational model for agent workloads differs from traditional application hosting.
• Security model: agents execute with specific authorizations. Managing agent identity and permissions will be a Basis responsibility.

Your Action Checklist for This Quarter

1. Build your first agent in Joule Studio using a sandbox environment. Start simple: a data validation or notification agent.
2. Map one process end-to-end as an agent workflow. Pick something repetitive that your clients complain about.
3. Read the Cloud SDK for AI docs, even if you are not a developer. Understanding the pro-code path makes you a better architect.
4. Understand A2A basics. This will become table stakes for anyone designing SAP integration architectures.
5. Revisit your Joule copilot skills. The copilot is the foundation. If you have not used Joule for ABAP generation, CDS views, or debugging, start there first.

The Bigger Picture -- Agentic SAP Is Not Optional

SAP is not experimenting with agents. They are rebuilding the interaction layer of their entire platform around them.

This timing is not accidental. The 2027 end-of-support deadline for ECC is driving the largest migration wave in SAP's history. Companies migrating to S/4HANA Cloud right now will land on a platform where agents are first-class citizens. The agentic capabilities are not a future roadmap item for these companies. They are part of the platform they are migrating to.

As we argued in our piece on why AI makes SAP more entrenched: AI wraps SAP, it does not replace it. Agents are the mechanism through which that wrapping happens. They sit between users and the SAP core, handling the complexity so users do not have to navigate 12 transactions to complete a procurement workflow.

The question is not whether agentic AI will reshape SAP. It already is. The question is whether you are positioned to build with it or scrambling to understand it when your clients start asking.

Joule copilot skills get you through the next year. Agentic architecture skills position you for the next decade.

AI in SAP is no longer just about helping users. It is about getting work done.

If you are planning an SAP migration and want to understand how agentic AI fits into your architecture, start with an assessment. We will map your agent opportunities against your landscape. No RFP required, proposal delivered within 48 hours.