onedevatlas — one atlas for SAP developers

Overview

SAP SHIPS

@cap-js/agents SAP's own CDS plugin for building agents inside a CAP service, wired to audit logging and telemetry through peer dependencies rather than leaving observability to the author.

Java →

com.sap.cds:cds-adapter-agent The A2A agent adapter for CAP Java, turning an @agent-annotated Application Service into a conversational endpoint whose queries and unbound actions become tools for a configured LLM.

Not covered: At the plugin's own harness and at what capire lists as still to come: evals-based agent testing, RAG and knowledge graphs, alternative agent harnesses, custom-coded agents, advanced streaming, sandboxed scripts, push notifications, agent memory across sessions, file I/O, data parts and data privacy. The chat preview in the generic index.html page is marked experimental and for local development, so the screen a user of the application opens is not part of what is served. On Java it stops earlier: bound actions and bound functions are not tools yet, @agent.hitl is not supported, and conversation history sits in volatile memory, so every follow-up has to reach the same server instance. It also stops at the application's own services by SAP's own statement — capire's guide says CAP-level agents are intended only for exposing custom CAP application services and are not an SAP-endorsed pathway for agentic access to SAP Application APIs.

Relationship unassessed: capire states what the plugin ships and what it plans, and no source read here gives the history between the plugin and the independent entries.

SourceCAP-level Agents — capirechecked 2026-10-15

THE COMMUNITY ADDS

An agent built on LangGraph keeps its own loop and state: @mi8y/cds-langgraph-persistence stores one thread's checkpoints in CDS, and its README now points new applications at the checkpointer the core plugin has since added, while @mi8y/cap-agents-memory holds what has to outlive a thread, which the core lists among the features it is still working on. @mi8y/cap-agents-sdm-backend gives a Deep Agents agent file operations over a document repository, which is file I/O, another item on the core's list. cds-agents runs the other way round, as a client library pointed at a service that is already running, so the framework is the host and the CAP service is what gets wrapped as tools. cap-agent-ui5-webui serves the chat screen the core's preview is not meant to be. Beyond the CAP plugin, SAP's own Joule Studio builds agents in a managed environment and registers them with SAP Joule, outside the CAP service.

a2a-plugin cap-agent-ui5-webui @mi8y/cap-agents-memory @mi8y/cap-agents-sdm-backend @mi8y/cds-langgraph-persistence cds-agents @saptarishi/cds-plugin-llm

Policy1

PolicySAP API Policy 4.2026a§ 2.2.2AlwaysAn agent built into an application reaches SAP Application APIs, whether directly or through tools generated from a service that proxies them.

§ 2.2.2 AI call sequences and data extraction. Outside SAP-endorsed architectures, data services or expressly identified pathways, the policy prohibits specified agentic API use and systematic or large-scale extraction.

capire's own guide states that CAP-level agents are intended only for exposing custom CAP application services, and names section 2.2.2 for the agentic-access provisions. Check which endpoints the agent's tools end up calling, and consult SAP's reference architectures for the endorsed routes.

SAP API Policy 4.2026a →

SourceCAP-level Agents, SAP API Policy — capirechecked 2026-10-15SourceSAP API Policy v.4.2026achecked 2026-09-16

Artifacts14

14 of 14 artifacts

ArtifactSignals

CDS plugins6

@cap-js/agentsCDS plugin for building agents inside a CAP service

Signals

Functional boundary

@mi8y/cap-agents-memoryLangGraph Store keeping agent memory as CDS entities

Signals

none

@mi8y/cds-langgraph-persistenceLangGraph checkpointer backed by CDS for CAP agents

Signals

none

@saptarishi/cds-plugin-llmCAP service kind putting eleven model providers behind one API

Signals

none

a2a-pluginExposes an annotated CDS service as an Agent-to-Agent agent

Signals

Functional boundary

cap-agent-ui5-webuiUI5 web interface for an agent built in a CAP service

Signals

Functional boundary

CLI tools2

@sap/joule-studio-cliCLI for Joule digital assistants and Joule Studio solutions

Signals

none

@sap/joule-work-dev-cli-early-adoptersPro-code CLI for building and deploying Joule Studio solutions

Signals

none

Packages3

@mi8y/cap-agents-sdm-backendDeep Agents filesystem over an SAP Document Management repository

Signals

Functional boundary

cds-agentsToolkit turning a CAP service into tools for agent frameworks

Signals

none

com.sap.cds:cds-adapter-agentA2A adapter turning a CAP Java service into an LLM-backed agent

Signals

none

Services2

Joule Studio, classic editionLow-code SAP Build capability for custom Joule skills and agents

Signals

none

SAP JouleSAP's AI engagement layer across SAP applications

Signals

none

Web tools1

Joule StudioSAP's managed environment for building custom agents and workflows

Signals

none

Tasks5Beta

CoversCovers, under conditionsLikely, from its propertiesStated not supportedAssessed, not knownNot assessed

Answer a user's question inside the application2 covers, 1 under conditions, 1 not known

Someone using the application asks in plain words and the application answers from its own services, with the agent running inside the deployed application rather than in the asker's own AI client.

Covers the agent that runs in the application, the tools it gets from the service and the endpoint it is reached at. Reaching a model is LLM integration, exposing the same service to somebody else's agent is MCP servers, who may read a row is authorization, and the screen the conversation happens on is assessed on its own. Which entitlements a subaccount holds is a project question and is not assessed here.

Covers@cap-js/agents@agent on the service definition is the whole setup: the plugin generates MCP tools from that service's entities and actions, runs a ReAct loop over them and serves the result over A2A. capire's own walk shows the two halves of this outcome — asked to list books the agent calls the generated describe and query tools, and asked to order one it calls the service's action through the call tool. An AGENTS.md next to the service definition replaces the generated agent with one built from the directory, which is the route to take when the answer has to follow written instructions rather than whatever the model infers from the model.

Remaining work: Decide which service the agent is put on and what its projection exposes, since the tools come from that model. Configure a model: the development profile reads credentials from a local Claude Code or OpenCode installation, and production and hybrid use the aicore kind against SAP AI Core. Where the answer has to be deterministic, the AGENTS.md and the skill files are the project's to write.

Open artifact →

Coverscom.sap.cds:cds-adapter-agentThe same annotation on an Application Service, with the tools derived differently: one generic query tool that reads across the service's entities with CDS QL, plus one callable tool per unbound action or function. The model comes from a named cds.ai.chat.models configuration the agent picks with @agent.llm, and the endpoint is A2A at /a2a/<service-path> with an agent card beside it.

Remaining work: Add the module to srv/pom.xml and configure a chat model. An operation defined on an entity has to be reachable some other way, since capire states bound actions and bound functions are not tools yet; and because conversation history is held in volatile memory, a question and its follow-up have to land on the same server instance.

Open artifact →

Covers, under conditionscds-agentsComes at the outcome from outside the application. CAPToolkit generates the tools a LangChain or LangGraph agent calls from a CAP service's model, and CAPAgent is a ready-made ReAct agent over them. Because it is a client library pointed at a service that is already running, the service answering the question need not be one the project owns — the README draws that line against @cap-js/mcp, which requires owning the application and redeploying it.

Conditions: A Node.js host installs the library with zod, @langchain/core and a model package, as its install line names. It is pointed at a running OData V4 service: ODataExecutor is the client underneath. The agent loop is the project's own, unless CAPAgent is used, which the README scopes to demos and small apps.

Remaining work: Choose a tool strategy of minimal, crud, actions or full, which is where the README's four-hundred-tool argument bites, and build the loop, the prompt and the conversation's state, none of which this library carries.

Open artifact →

Assessed, not knowna2a-pluginThe entry records that @a2a opts a service in and an agent handler answers, which would place it on this outcome, but nothing was retrieved on 2026-10-15 to say what the handler is given or what runs the loop.

Remaining work: Read the package's own documentation. npm answered 403 to the one address the entry carries and the package declares no public repository, so the README could not be reached in this pass.

Open artifact →

Give the agent a chat screen in the application2 under conditions

A user of the application opens a screen in it and talks to the agent there, instead of reaching it from a separate AI client or over HTTP by hand.

Covers the screen and how it finds and talks to the agent. The agent itself, its tools and its endpoint are the outcome assessed separately; who may open the screen is authorization, and serving the files from an HTML5 repository or an approuter is deployment.

Covers, under conditions@cap-js/agentsThe plugin puts a chat preview in the generic index.html page, next to each A2A endpoint, and capire's walk uses it to ask the bookshop agent to list books and to order one. capire marks it Alpha in the heading and calls it rudimentary and experimental in the sentence under it.

Conditions: Local development: capire states the preview can be used in local development, and marks it experimental.

Remaining work: A screen for anyone other than the developer running cds watch is the project's own, or another option's. Nothing retrieved says the preview is served outside the development profile.

Open artifact →

Covers, under conditionscap-agent-ui5-webuiInstalling the plugin is the whole setup: it serves a freestyle SAPUI5 TypeScript chat client same-origin from the CDS server and discovers the services carrying @agent, with no wiring, no copied files and no approuter change. With one agent the client connects to it directly; with several it renders a picker, and switching there starts a new conversation because each agent owns its own contextId and task history. The README also covers the deployed case, the HTML5 Application Repository wiring and what the plugin does not remove from an MTA, and ships a scripted model for testing an approval gate, because the mock bundled with the core plugin always calls the read tool and can never call an action.

Conditions: [@cap-js/agents](artifact:cap-js-agents) serves the agents: the README pins it to exactly 0.9.1, says that package is pre-1.0, and says this plugin inherits that instability and to expect breakage on upgrade. The agent is reached over A2A: the README states the plugin does not speak anything other than A2A as @cap-js/agents serves it.

Remaining work: Decide how the screen is served and reached in a deployment, which the README's own BTP and MTA sections cover rather than automate, and who may open it. A conversation cannot be carried from one agent to another, by the README's own statement, so a project that wants one thread across several agents has that to solve.

Open artifact →

Keep a conversation after the server restarts1 covers, 1 under conditions, 1 likely, 1 no

A conversation with the agent survives a restart, and a follow-up that lands on another instance carries on where the last one left off instead of starting again.

Covers the state of one conversation between turns. What the agent remembers from an earlier conversation is a separate outcome; which database holds the rows is database connectors, keeping one tenant's rows apart is multitenancy, and how long a conversation may be kept is a data-protection question this record does not assess.

Covers@cap-js/agentsThe harness keeps the conversation's short-term memory in the database the application is already connected to — SQLite in local development, SAP HANA in production — so conversational context and workflow checkpoints are written where the application's own data is. capire states this is what lets an agent resume a session after a server restart, and names clustered environments in the same sentence.

Remaining work: Nothing is installed for it; what remains is the deployment the claim depends on, a database the instances share rather than a local file, and a decision about how long a stored conversation is kept.

Open artifact →

Covers, under conditions@mi8y/cds-langgraph-persistenceAnswers the same outcome for an agent whose loop is LangGraph's rather than the plugin's: checkpoints are thread-scoped state written through CDS, used to resume a workflow, keep the conversation's history and travel back through it.

Conditions: The agent runs on LangGraph, whose checkpointer interface this implements. @sap/cds 10 or higher, which its README states as a requirement. The README now says SAP's own @cap-js/agents includes checkpointer support and to prefer it for new applications, keeping this package available for its existing implementation.

Remaining work: The loop, the graph and the model stay the project's: this is the one piece of a LangGraph agent that the package supplies.

Open artifact →

Likely, from its properties@mi8y/cap-agents-memory

Stated not supportedcom.sap.cds:cds-adapter-agentcapire states that CAP Java has no persistent chat history yet and holds the conversation in volatile memory, and draws the consequence itself: every follow-up prompt has to be sent to the same server instance. The guide for the plugin lists persistent chat history among the features not yet supported there.

Remaining work: A conversation that has to survive anything is the application's own problem here, and nothing retrieved describes a supported place to put it or a way to hand it back to the adapter.

Open artifact →

Recall a user's preference in a later conversation2 under conditions, 1 no

Something the agent was told or worked out in one conversation is available in the next one, so a returning user does not state their preferences again.

Covers what outlives one conversation and how the agent reads it back. Keeping one conversation's state between turns is the outcome assessed separately; finding records by meaning is retrieval-augmented generation, keeping one tenant's rows apart is multitenancy, and what may be kept about a person is a data-protection question this record does not assess.

Covers, under conditions@mi8y/cap-agents-memoryCdsMemoryStore implements LangGraph's Store API against CDS, so the facts and preferences the agent keeps are rows in the application's own database and are shared across threads. Called inside a CAP request handler it inherits the active database and the tenant, and the CDS queries behind it run on CAP's SQLite, SAP HANA and PostgreSQL adapters. Its author describes it as an add-on to the core plugin, which keeps the model, the generated tools, the A2A endpoint and the checkpointing while this contributes the cross-session store and the tools that read it.

Conditions: The agent runs on LangGraph, whose Store interface this implements. @sap/cds 10 or higher and @langchain/core 1 or higher, which its README states as requirements. The store is called inside a CAP request handler, which is how it inherits the active database and tenant context. Finding a memory by meaning rather than by stored value needs a LangChain Embeddings implementation passed in, and the generated Vector(1536) field resized to the chosen model.

Remaining work: Decide what is worth remembering and under which namespace, and write the prompt or the tool call that reads it back; the package supplies the store and its operations, not a policy for what an agent should keep.

Open artifact →

Covers, under conditions@mi8y/cap-agents-sdm-backendWhat the agent worked out in one conversation survives as a file rather than as a memory row. SdmBackend implements the Deep Agents filesystem protocol over an SAP Document Management repository, so the agent writes a document under a configured root folder and a later conversation finds it again with ls, glob or literal grep; its announcement states that a person can review and revise that file in between, and that instructions and skills kept in the repository are loaded when a new chat starts after the team updates them. The unit it keeps is a file under that root, so anything to be read back later has to be written into one and found there.

Conditions: An existing SDM CMIS repository, with the folder exposed as the virtual root already created; the backend neither validates nor provisions them. @sap/cds 10 or higher and deepagents 1 or higher, which its README states as requirements, on CAP Node.js 10 or later. Either a Cloud SDK destination pointing at the SDM API base URL or the Cloud Foundry service binding labelled sdm; the binding route exchanges the current CAP request's bearer JWT and fails without one, so background work needs an explicit trusted destination. Text-based content: the author states that access to a file does not automatically provide native editing of Word documents, spreadsheets or PDFs.

Remaining work: Decide the workspace layout and write the instruction that has the agent save its work there and look for it next time; the package supplies the file operations, not a policy for what is worth keeping.

Open artifact →

Stated not supported@cap-js/agentscapire lists agent memory across sessions among the features it says it is working on and plans to release in the near future, and its persistence section covers short-term memory only: conversational state and checkpoints in the connected primary database, for context across interactions within a session.

Remaining work: What an agent recalls from an earlier conversation is the application's own to model, write and hand back to the agent, or another option's.

Open artifact →

Require a person's approval before the agent acts1 covers, 1 no

Before the agent runs an action that changes something, the task stops and waits for a person to approve or reject it, and carries on from there.

Covers holding the action and resuming the task. Who is allowed to approve is authorization, recording that they did is audit logging, and the screen the approval is given on is assessed on its own. An approval step modelled as a business workflow outside the agent is not this outcome.

Covers@cap-js/agents@agent.hitl on a CDS action is the whole declaration. When the agent decides to call that action the task pauses and moves to A2A's input-required state instead of running it, and the plugin emits an AgentInputRequired audit event when the agent asks and an AgentTaskResumed one when the approval or rejection comes back. The same mechanism carries the execution-time quota: on a timeout the graph interrupts rather than failing and asks through the gate whether to continue, with a summary of the progress so far.

Remaining work: Annotate the actions that need it, and handle the input-required state in whatever talks to the agent — the pause is served over A2A, so the approving client is the project's. Nothing here decides who may approve.

Open artifact →

Stated not supportedcom.sap.cds:cds-adapter-agentcapire states in the section that documents the annotation that CAP Java does not support it yet, and lists content filtering, quotas, telemetry, persistent chat history, audit logging and data privacy in the same position. So an action the Java adapter exposes as a tool runs when the agent calls it.

Remaining work: An approval step has to sit outside the agent — in the action's own implementation, or in a workflow the action starts — and nothing retrieved describes how to resume an A2A task from there.

Open artifact →

Content49

Group by49 of 49 pieces

Agent tooling24

Building Code-Based AI Agents on the BAIP

YouTube — SAP Developers playlists, Wouter Lemaire, Talk

CAP in the age of AI #5 - agents wrap-up

YouTube — SAP Developers playlists, DJ Adams, Johannes Vogt, Simon Engel, Stefan Rudi, Daniel Schlachter, part 5 of 7, Video

What's in Daniel Hutzel's brain?

YouTube — SAP Developers playlists, Daniel Hutzel, DJ Adams, Talk

Show 21 more

CAP: The Road Ahead - Simplicity in an AI Era

YouTube — SAP Developers playlists, SAP Developers, Talk

Meet Joule Studio and Build your First AI Agent

YouTube — SAP Developers playlists, SAP Developers, Talk

CAP in the age of AI #4 - more on agents

YouTube — SAP Developers playlists, DJ Adams, Johannes Vogt, part 4 of 7, Video

CAP in the age of AI #3 - from MCP to A2A

YouTube — SAP Developers playlists, DJ Adams, Johannes Vogt, Stefan Rudi, part 3 of 7, Video

Adapting SAP Joule for Purchase Order Creation from an Existing Purchase Requisition

SAP Community, jonathanvi59, Blog

CAP in the age of AI

YouTube — SAP Developers playlists, DJ Adams, Johannes Vogt, Simon Engel, Stefan Rudi, Daniel Schlachter, Series

Building Durable AI Agents - Announcing the cds-langgraph-persistence Plugin

SAP Community, merbinjanselm, BlogThe reasoningRunnable code

New majors

Banking Sentinel: A Multi-Agent Credit-Risk Copilot on SAP BTP, Built on a Mixed AI Stack

SAP Community, Shahid, BlogThe reasoningA recipeRunnable code

Core changed

Building an LLM Agent in CAP Java with Spring AI

SAP Community, Johannes Vogt, BlogThe reasoningRunnable code

Core changed

Building an LLM Agent using CAP

SAP Community, Johannes Vogt, BlogThe reasoningRunnable code

Core changed

AI-native North Star architecture — Platform Layer

SAP Architecture Center, SAP Architecture Center, Reference architectureThe reasoningA reference

Core changed

Agentic AI on BTP: a Multi‑Agent App with Pydantic AI

SAP Community, Wouter Lemaire, Blog

Agentic AI on BTP: a Single Agent with LangGraph

SAP Community, Wouter Lemaire, Blog

Integrating and Extending Joule

SAP Architecture Center, SAP Architecture Center, Reference architectureThe reasoningA reference

Event Driven SAP CAP on Kyma with Agentic AI and UI Auto Refresh

SAP Community, Shahid, BlogThe reasoning

How Redwood Software and SAP are shaping the next era of automation with Joule Studio

SAP Community, gmblom, Blog

Generate agentic workflows using SAP-managed n8n in Joule Studio

SAP TechEd — session catalogue, TalkA recipe

Connecting AI agents to the ABAP RESTful application programming model

SAP TechEd — session catalogue, TalkThe reasoning

Building agentic applications with SAP HANA Cloud

SAP TechEd — session catalogue, TalkA recipe

Agentic memory: Knowledge graph engine and recall in SAP HANA Cloud

SAP TechEd — session catalogue, Markus Fath, TalkThe reasoning

Knowledge graph and agent memory: Build an agent that remembers

SAP TechEd — session catalogue, Markus Fath, Thomas Hammer, TalkA recipe

@cap-js/agents4

CAP in the age of AI #5 - agents wrap-up

YouTube — SAP Developers playlists, DJ Adams, Johannes Vogt, Simon Engel, Stefan Rudi, Daniel Schlachter, part 5 of 7, Video

CAP in the age of AI #4 - more on agents

YouTube — SAP Developers playlists, DJ Adams, Johannes Vogt, part 4 of 7, Video

CAP in the age of AI #3 - from MCP to A2A

YouTube — SAP Developers playlists, DJ Adams, Johannes Vogt, Stefan Rudi, part 3 of 7, Video

CAP in the age of AI

YouTube — SAP Developers playlists, DJ Adams, Johannes Vogt, Simon Engel, Stefan Rudi, Daniel Schlachter, Series

cap-agent-ui5-webui1

Building Code-Based AI Agents on the BAIP

YouTube — SAP Developers playlists, Wouter Lemaire, Talk

@mi8y/cds-langgraph-persistence1

Building Durable AI Agents - Announcing the cds-langgraph-persistence Plugin

SAP Community, merbinjanselm, BlogThe reasoningRunnable code

New majors

Joule Studio, classic edition6

Adapting SAP Joule for Purchase Order Creation from an Existing Purchase Requisition

SAP Community, jonathanvi59, Blog

Integrating and Extending Joule

SAP Architecture Center, SAP Architecture Center, Reference architectureThe reasoningA reference

Connecting AI agents to the ABAP RESTful application programming model

SAP TechEd — session catalogue, TalkThe reasoning

Show 3 more

Custom Joule Skills

SAP BTP AI Best Practices, SAP, DocThe reasoning

Content-based Agents with SAP Joule Studio Agent Builder

SAP BTP AI Best Practices, SAP, DocThe reasoning

Building enterprise agent extensions with the Joule Studio solution

SAP TechEd — session catalogue, TalkA recipe

Joule Studio6

Meet Joule Studio and Build your First AI Agent

YouTube — SAP Developers playlists, SAP Developers, Talk

How Redwood Software and SAP are shaping the next era of automation with Joule Studio

SAP Community, gmblom, Blog

Building Agentic Workflows with n8n in Joule Studio

YouTube — SAP Developers playlists, SAP Developers, Talk

Show 3 more

From Intent to Arcade: Building Joule*Bert with Joule Studio and AI-Assisted Pro Code

YouTube — SAP Developers playlists, SAP Developers, Talk

Real Pro-Code Development with Joule Studio

YouTube — SAP Developers playlists, SAP Developers, Talk

Achieve Agentic Enterprise Automation with SAP Integration Suite and Joule Studio

YouTube — SAP Developers playlists, SAP Developers, Talk

@sap/joule-work-dev-cli-early-adopters3

From Intent to Arcade: Building Joule*Bert with Joule Studio and AI-Assisted Pro Code

YouTube — SAP Developers playlists, SAP Developers, Talk

Real Pro-Code Development with Joule Studio

YouTube — SAP Developers playlists, SAP Developers, Talk

Build your first agent with Joule Studio in a pro-code way

SAP TechEd — session catalogue, TalkThe reasoning

SAP Joule21

Integrating and Extending Joule

SAP Architecture Center, SAP Architecture Center, Reference architectureThe reasoningA reference

How Redwood Software and SAP are shaping the next era of automation with Joule Studio

SAP Community, gmblom, Blog

Generate agentic workflows using SAP-managed n8n in Joule Studio

SAP TechEd — session catalogue, TalkA recipe

Show 18 more

Building enterprise agent extensions with the Joule Studio solution

SAP TechEd — session catalogue, TalkA recipe

Zero token architecture for Joule Agents

SAP TechEd — session catalogue, TalkThe reasoning

Transform business data into AI-supported insights

SAP TechEd — session catalogue, TalkA recipe

What’s next for agentic analytics and planning in SAP Business Data Cloud

SAP TechEd — session catalogue, TalkThe reasoning

AI-enhanced analytics with SAP Business AI Platform

SAP TechEd — session catalogue, Joaquin Recio Huertas, TalkThe reasoning

Joule without walls: From personal skills to enterprise interoperability

SAP TechEd — session catalogue, TalkThe reasoning

The road map for SAP Joule for Consultants—your go-to SAP consulting tool

SAP TechEd — session catalogue, TalkThe reasoning

Joule and SAP Knowledge Graph: Context-aware AI across SAP solutions

SAP TechEd — session catalogue, TalkThe reasoning

Building custom Joule Agents with SAP Knowledge Graph

SAP TechEd — session catalogue, TalkA recipe

Discover fast-track implementation of SAP Cloud ERP with AI

SAP TechEd — session catalogue, TalkThe reasoning

Discover how SAP Joule for Consultants transforms cloud implementations

SAP TechEd — session catalogue, TalkThe reasoning

Agent-led test management: Hands-on lab with Joule in SAP Cloud ALM

SAP TechEd — session catalogue, TalkA recipe

Experience core foundational capabilities of SAP Cloud ERP

SAP TechEd — session catalogue, TalkA recipe

AI-accelerated RISE with SAP migration with the system transition workbench

SAP TechEd — session catalogue, TalkA recipe

SAP Joule for Consultants: Unified knowledge for requirements and designs

SAP TechEd — session catalogue, TalkA recipe

Inside Joule Studio runtime: Agent deployment and integrations

SAP TechEd — session catalogue, TalkThe reasoning

What’s next for the core platform capabilities of SAP Business AI Platform

SAP TechEd — session catalogue, TalkThe reasoning

Seen working4

ArtifactSignals

Samples4

cap-agent-ui5-webui-sampleWorked example of the cap-agent-ui5-webui plugin

No license

custom-llm-clientLocal chat client for SAP questions with a CAP LangGraph backend

No license

SAP-samples/btp-joule-a2a-pro-code-agentA2A reference letting Joule delegate to a CAP pro-code agent

none

xtravelsCAP travel-booking app built on xflights master data

none

Details

What changed — and what it makes stale1

@cap-js/agents 0.9.12026-08-14, CAP

The core gained a first-party plugin for building an agent into a CAP service. Before it, an agent-callable interface into an application meant reaching for an independent framework such as LangChain or LangGraph, wired up by hand; after it, @agent on a service auto-generates a tool-calling loop from the service's own entities and actions, or a sibling AGENTS.md plus skill files can define the agent's behaviour explicitly, with audit logging and OpenTelemetry export wired in as peer dependencies rather than left to the author.

Makes stale:

Guidance that CAP has no SAP-official building block for an in-app agent and that LangChain or LangGraph wiring is the only route. Since August 2026 there is a sap-official plugin for it, though how it relates to those independent frameworks is not yet assessed here.

Sourcecap-js/agents — READMEchecked 2026-09-08

Coverage

statecore and community, CAP

assessed2026-10-15

relationshipunassessed

domainAI & Agents

also inBTP/BAIP

Designs that place it1

AI-native North Star architecture — Platform Layer

Comparison properties5

These are the questions used to compare what the artifacts do. Values come from their documentation and may apply to a particular ecosystem or runtime. Each recorded value in the comparison opens its statement and sources.

What it bringsAgent frameworkProtocolsWhere state is keptApproval before an action

For your agent

Ref: capability:agent-tooling
JSON: /capabilities/agent-tooling.json
MCP: Connecting an agent