SAP AI Agents: What They Are and How Developers Use Them

SAP AI agents are programs that use large language models to get SAP work done end to end: they take a goal, plan the steps, call SAP systems, APIs, and tools along the way, check their own results, and adapt when something fails. That behavior — goal-driven, tool-using, self-correcting — is what "agentic AI" means. In the SAP ecosystem it shows up as Joule inside SAP applications and development tools, agents assembled in SAP Build and Joule Studio, custom agents developers build on BTP with SAP AI Core, and coding agents that work across entire repositories.

This article maps that landscape from a developer's point of view: what makes an agent an agent, where you will meet agents in SAP tooling, and the part that decides whether an agent helps or hurts you — context.

Assistant vs Agent: What Actually Changes

The word "agent" gets used for everything from a chat window to a fully autonomous worker. The practical difference is simple:

• A chat assistant answers questions. You ask, it responds, you decide what to do next.
• An agent pursues a goal. You describe an outcome, it plans steps, invokes tools (APIs, CLIs, browsers, databases), inspects results, and retries or adjusts when a step fails.

That last row is why agents deserve respect. A wrong answer costs you a reread; a wrong action — a changed configuration, a released transport, an API call with side effects — costs real cleanup. Autonomy is a dial, not a switch. Mature teams turn it up gradually: read-only first, write operations behind human approval, bulk changes last.

SAP's Agent Landscape

SAP's portfolio covers three layers worth telling apart.

Joule: SAP's AI assistant

Joule is SAP's AI assistant, embedded across SAP's cloud applications and development tools. For developers, the relevant slice is Joule for Developers inside SAP Build Code and ABAP development tooling — code completion, code explanation, unit-test generation, and chat that knows about the workspace it runs in. Joule today behaves mostly like a well-grounded assistant rather than an autonomous worker; the agent-building story lives one layer up. For a side-by-side with a terminal-native agent workflow, see Joule for Developers + Claude Code.

Agent building: SAP Build and Joule Studio

Joule Studio is SAP's environment for assembling agents, apps, and workflows. SAP describes support for MCP and A2A connections — the two protocols that let an agent call external tools (MCP) and cooperate with other agents (A2A) — and positions it as working alongside the tools developers already use. The honest developer take: this is where SAP-built, business-facing agents get composed, and it is evolving quickly. Before you commit to a specific integration, check the SAP Help Portal for what is generally available in your release.

Custom agents on BTP with SAP AI Core

When the out-of-the-box agents do not fit, you build your own on BTP. The usual ingredients:

• SAP AI Core runs AI workloads and, through the generative AI hub, provides access to large language models behind a consistent API. That is the model layer.
• Orchestration — the loop that plans, calls tools, and evaluates results — is what you assemble, using either the orchestration capabilities of the generative AI hub or your own code on top.
• SAP Cloud SDK for AI wraps generative AI hub access for application developers, so a CAP or Java service can call models without reimplementing authentication and routing.
• Grounding and tool access: retrieval over your own documents, destinations to backend systems, and increasingly MCP servers as the standard tool interface.

The sap-ai-core and sap-cloud-sdk-ai skill pages hold curated references for the model layer and the SDK, and the SAP MCP server guide covers the tool-access pattern in depth. The SAP AI category collects the AI-relevant plugins in one place.

Where Developers Meet Agents

In practice, you will run into agents in four places:

1. SAP Build and SAP Build Code. Joule is embedded here, and Joule Studio extends the same environment toward agent assembly. Low-code and ABAP developers feel this first.
2. Cloud operations tooling. SAP's cloud management tooling — including the Service Center landscape — increasingly ships AI-assisted operations such as health checks, incident summaries, and recommended actions. Treat these as assistants until you have verified what they can change on their own; the SAP Help Portal documents the current scope.
3. Your own code on BTP. SAP AI Core, the generative AI hub, and the SAP Cloud SDK for AI are the building blocks when you embed agent behavior into your own applications and services.
4. The terminal. Coding agents — Claude Code with SAP skills, or any MCP-capable assistant — now plan and execute multi-file changes in SAP repositories. The Claude Code for SAP page describes that workflow end to end.

The Context Problem

Here is the failure mode that dominates real-world SAP agent projects: the model is fine, the orchestration is fine, and the output is confidently wrong about SAP.

Typical symptoms:

• Invented OData service paths and entity set names that look plausible and resolve nowhere.
• CDS view fields and annotations guessed from generic SQL habits, which compile in no system you own.
• btp CLI invocations with the right verbs and invented option names.
• Destination and authorization properties that mix up OAuth grant types and scope names.
• Confident blending of cloud and on-premise APIs that behave differently in practice.

None of this is the model being lazy. SAP's surface area is enormous, much of it is documented behind logins, and your system's exact objects — your CDS views, your API prefixes, your authorizations — were never in any training set. An agent without curated context does what it must: it pattern-matches and fills the gaps with plausible fiction.

Giving SAP Agents Context

There are three levers, and serious setups use all of them:

• Rules — instructions that set boundaries and conventions: which environments exist, which naming conventions apply, what the agent must never do. Cheap and always on, but limited in depth.
• Retrieval (RAG) — index your documentation, API specs, and metadata, and let the agent pull the relevant chunks at run time. Essential for system-specific facts that change often.
• Skills — curated, task-shaped playbooks loaded on demand. A skill bundles verified API references, working code patterns, and step-by-step procedures, so the agent reads the right material before it acts.

For coding assistants, skills are the fastest lever, because they put curated SAP knowledge directly into the agent's working context. The SAP Skills plugin collection does exactly that for tools like Claude Code:

# add the full SAP skills collection
npx skills add secondsky/sap-skills

# or just the AI plugins relevant to agent work
npx skills add secondsky/sap-skills --skill sap-ai-core
npx skills add secondsky/sap-skills --skill sap-cloud-sdk-ai

With those loaded, an agent stops guessing: it gets the real generative AI hub orchestration shapes, the actual Cloud SDK for AI module structure, and working deployment patterns for AI Core. The same logic applies to agents that drive SAP's web UIs — plugins like the browser automation skill teach an agent to interact with SAP front ends reliably instead of improvising selectors.

The combination to aim for: curated skills for stable knowledge, RAG for system-specific facts, rules for guardrails. An agent with all three turns from a plausible storyteller into a useful colleague.

Where to Go From Here

SAP AI agents are not a single product — they are a pattern appearing across Joule, Joule Studio, custom builds on SAP AI Core, and the coding agents you already use. The differentiator is rarely the model. It is the context you give the agent before it acts.

Start small: pick one workflow, ground it properly, verify every action, and expand from there. Browse the SAP AI category for the AI-relevant skill plugins, or explore the full skills catalog for ABAP, CAP, Fiori, HANA, and BTP coverage.