Frequently Asked Questions on the AI-native North Star
This document compiles questions and answers from a series of interactions with SAP customers and partners, including multiple rounds with DSAG members, about the SAP AI Native North Star architecture. The questions range from clarifying concepts, planned capabilities, and the development roadmap to broader requirements and implications of the new approach. Some answers provide clear guidance. Others remain deliberately high-level, as the SAP AI Native North Star is a vision: it describes target concepts and architectural patterns for the future, and the fully defined end state is still evolving. Many of these concepts are already in development. Others are still being discussed and open. This is intentional. Moving towards an AI-native technology foundation is a broad and significant evolution that requires multiple sequential and parallel iterations. New concepts are developed incrementally and validated with early adopters throughout the process.
See also the disclaimer down below.
Artificial Intelligence in General
Q: The advantage of deterministic applications and workflows compared with agent-based execution: they do not burn any tokens.
A: This is correct. A key advantage of deterministic applications and workflows is that they do not require LLM inference for every execution step; therefore, they do not consume tokens. They provide predictable control flow, reliability, repeatability, and often lower cost for well-defined processes.
The target architecture is not “agents everywhere.” Instead, it calls for a conscious decision and deliberate combination. SAP’s AI Golden Path provides guidance for deciding which approach, agentic AI, generative AI, classical ML, or relational foundation models, best fits a particular business problem and is applicable in general.
A related presentation: “AI or not AI” AI Use Cases and Anti-Patterns (from the DSAG AI Topic Days 2026)
Q: This concept triggers many actions that could be performed without an LLM. This could create substantial LLM load. What costs should be expected, and can LLMs handle this load at scale?
A: LLMs will be involved where interpretation, reasoning, summarization, planning, or natural-language interaction creates value. This is not the case for deterministic operations that conventional application logic, rules, APIs, workflows, or queries can perform more efficiently and reliably. Cost, latency, scalability, quality, and risk must be assessed for each use case. Reuse and caching of intermediate results might become important optimization techniques.
The generative AI hub provides optimization services such as prompt optimization, test-time scaling, and fit-for-purpose model selection. OpenTelemetry-based observability tracks model calls and resource consumption, so AI costs are visible per agent.
Finally, our AI Golden Path offers guidance on which technologies to apply for which use cases or business process steps.
User Experience Layer
Joule Work and Spaces
Q: Joule Work: When changes are made to underlying software or table structures, what information must be provided to Joule Work? How does Joule Work obtain the required business context in such cases?
A: Joule Work should be grounded in governed business context rather than relying only on the pure language model. The SAP Knowledge Graph is intended to be the semantic backbone for semantic metadata, business entities, relationships, and process knowledge.
Q: In Spaces, can a personalized contextual “DNA” be stored so that it is persistently available in the background for all interactions of the user?
A: A memory functionality for spaces as a persistent, personalized context is planned across Joule and its agents, so it is not limited to a single Space. Joule and agents will share knowledge about the user, their preferences, and their working environment. Users will be able to manage this memory in one place, and access can be limited to specific agents. This user-specific memory must remain transparent, privacy-compliant, and under user control.
Q: How would an existing business process, such as incoming invoice processing, work in this UI concept?
A: Initially, the Generative UI should not replace the business process with a single generic chat interaction. Instead, Joule Work is intended to let users express an intent, then assemble relevant information, agents, and tools around that goal. For an invoice-processing scenario, this could combine a “Space” for investigation and analysis, maybe discovering price or quantity mismatches, “Conversations” for questions and instructions, and “Jobs” for traceable, agent-supported routine work within defined guardrails. This might include finding documents, comparing invoices with purchase orders, identifying exceptions, analyzing discrepancies, recommending next actions, and routing cases for approval. The specific degree of automation remains a business-process and application-design decision.
Q: Can generated Spaces be used by other users, or must every user create their own Spaces?
A: This is a known and frequently requested capability. Spaces should support sharing of relevant artifacts and context where collaboration requires it. Still, sharing must respect authorization, ownership, privacy, and the separation of personal and team context.
Q: Can Spaces also be created in SAP SuccessFactors?
A: Joule Work is positioned as a cross-application workspace rather than an application-specific UI. In principle, it can surface authorized data, insights, and actions from SuccessFactors alongside capabilities from other SAP and non-SAP systems, provided that the required integrations, business capabilities, authorizations, and product support are available. It should not be assumed that every SuccessFactors scenario is automatically available in a Space; availability depends on the delivered and configured integrations.
Q: Are Spaces essentially comparable to Anthropic artifacts with a DESIGN.md file behind them? What are the clear differences?
A: There may be a conceptual similarity, both can present generated or context-specific work environments. However, the distinguishing objective of SAP Spaces is enterprise integration: they are intended to operate within a governed business environment and connect authenticated users, authorized data, business semantics, enterprise applications, tools, agents, and process actions.
A Space is therefore not merely a generated interface or document. Unlike a free-form design file, Spaces are composed of a governed catalog of semantically described UI building blocks, constrained by layered design rules to stay on-brand, accessible, and consistent.
Q: If the UI is highly personalized, how can results be shared transparently with colleagues? This seems to conflict with the idea of a single source of truth.
A: Personalization and a single source of truth serve different purposes and can coexist. The single source of truth should remain the governed business data, metadata, calculations, process state of the underlying system of record. Personalization should affect how that trusted information is presented to an individual user.
To share work transparently, Joule Work should make shareable artifacts explicit, and retain source data, calculation logic to make the outcomes reviewable, even when each person’s workspace might look different.
Authorization
Q: Will LLMs adequately respect the authorization concept, or does the AI operate in a separate context with unrestricted access?
A: The LLM (the component that underlies what is commonly referred to as "AI") itself cannot and will not be the authorization enforcement point. Access control will be enforced by the integration of agents and tools into the underlying system of record, which handles the necessary authorization checks.
For agentic collaboration, the Agent Gateway is the central entry component which handles authentication, principal propagation, tenancy, and policy enforcement on agent level. The agent's permission can be configured as subset of the user's permissions.
Q: The established Joule principle is that user authorizations are inherited through PFCG. Does this principle remain unchanged for autonomously acting agents in Joule Work? Under which identity and with which scope of roles does an agent act when it executes proactively without a synchronous user context?
A: For agents acting on behalf of a user, the user context and applicable authorizations are propagated and enforced. For autonomous agents that operate without a triggering user session, the agent can operate with an own identity, permissions, and audit trail.
In either case, autonomy does not mean unrestricted access. The agent’s effective permissions must be explicitly defined and governed. The exact implementation, including how existing PFCG roles map into a specific deployment, depends on the application and identity architecture, but the principle remains that agent actions must be executed under controlled identity and authorization rules.
Q: Will Joule Studio support user-context propagation and authorization-aware access when an agent invokes a custom SAP BTP backend API through an MCP server? In particular, can the MCP-based API execute in the logged-on user’s context and return results according to that user’s authorizations?
A: Yes. The user context is propagated so that the agent can access only the information and operations that the user would be allowed to access directly.
In addition, agent permissions can be more restrictive than the user’s permissions. For example, even if a user is authorized to delete business data, the agent can be prevented from performing delete operations. This implements the principle of least privilege and supports governed agent execution.
Dynamic and Deterministic UI
Q: AI and Trust: From a business perspective, there is a need for a user interface alongside Joule Work that works entirely without AI. Business users must be able to verify what is stored in the underlying systems and ensure that information has not been distorted by AI. There are concerns that established SAP UI technologies, especially Fiori, may be deprioritized in favor of Joule Work.
Consumer AI has produced many implausible or incorrect results. Regardless of whether the concern is objectively justified, enterprises fear that SAP AI could similarly create unreliable or hallucinated information, or that users could receive incorrect results because prompts were not precise enough. To build trust, a stable, deterministic UI is required alongside AI-driven interaction. If SAP advocates the coexistence of Fiori and Joule, this should be reflected clearly in the product strategy.
A: This concern is valid. The AI-native Generative UI direction does not mean that deterministic, application-based user interfaces disappear. SAP business applications remain the systems of record, context and execution, while Joule Work provides an additional, intent-driven layer that can bring together data and insights. The architecture explicitly emphasizes reliability, compliance, transparency, user control, and privacy boundaries.
For repeatable, transactional, regulated, or training-intensive tasks, stable application flows and established UI patterns remain important. AI should guide users to trusted application functions, explain relevant context, and automate only within defined guardrails. It should not replace deterministic backend functionalities.
Q: The coexistence of applications and Joule Work is perceived differently by DSAG members. Resources for application development, for example, Fiori, appear to have been significantly reduced with reference to Joule Work. Organizations now have several incomplete UI technologies, such as SAP GUI, Web Dynpro, and multiple Fiori versions, and are now being told that everything will become “Joule Work.” This does not match how representatives of business applications currently (have to) position themselves toward customers.
A: See also Question. Joule Work should be understood as an experience and orchestration layer above applications, not as an automatic replacement for every existing application UI. The practical product roadmap and investment balance for each application area individually remain essential for customer confidence and adoption. The SAP Fiori design system remains part of SAP's AI Golden Path for application development, alongside CAP and ABAP Cloud.
Q: An analytical reporting capability based on the randomness of an LLM will never be accepted. Data must be definite and reliable. If two colleagues use the same prompt but receive different figures, the solution does not work.
A: This is a core requirement. For figures, KPIs, balances, process status, and other facts that exist in enterprise systems or can be calculated deterministically, Joule Work should retrieve the authoritative values through governed data products and business services. The LLM may help interpret the question, explain the result, identify relevant dimensions, or formulate a narrative, but it should not invent or approximate system facts. The query itself is constructed with grounding in SAP Knowledge Graph, which discovers the right API or data product and filter parameters.
Q: How consistent will dynamic UIs and Spaces be? How can new users be trained if everyone has an individual personalized UI?
A: Dynamic UIs must remain consistent at the level of design language, interaction patterns, terminology, guardrails, and business controls.
Spaces are more suitable for exploratory, goal-oriented, contextual work. For stable, high-frequency, standardized processes, especially those requiring formal training and stable UI, traditional application flows remain appropriate.
For example, a dynamic Space could help a manager assess team availability and prepare a leave request. The formal creation and approval of the leave request might still use the existing deterministic capabilities.
Interoperability
Q: Will it be possible to communicate with Joule from other chatbot environments, such as Microsoft Copilot? If so, will this provide an equivalent user experience?
A: The target architecture supports agent interoperability through the A2A standard. External tools may access SAP capabilities through Joule agents, but they will not necessarily provide the complete Joule Work experience, including its workspace, context, governance, and orchestration.
See also the Reference Architecture on Agentic AI & AI Agents
Documents
Q: Can I provide attachments in Joule Work, for example, to use an appropriate agent to extract data from a purchase-order PDF and automatically create a sales order?
A: Document upload for document grounding is possible and can support question answering based on uploaded documents.
A full end-to-end process, should not depend solely on free-form LLM generation. It should rather involve extraction, validation, matching against business data and an integrated and governed workflow. For this, the agent should use dedicated document-processing tools and APIs to apply business rules, authorization checks, master-data validation, and other controls before creating a business document in the system of record. Document understanding can also be provided as a reusable skill that agents can call.
Process Layer
Q: At present, agent-to-agent (A2A) communication is only supported in one direction (outbound)? When will SAP Agent Gateway become generally available? Source: Agentic AI & AI Agents
A: SAP Agent Gateway is currently under development and is planned to become generally available around SAP TechEd 2026 time. Its purpose is to enable governed interoperability and collaboration between SAP and non-SAP agents through A2A communication.
Q: Is SAP Agent Gateway equivalent to a combination of SAP Destination service and SAP Cloud Connector?
A: No. SAP Agent Gateway is a new component on the SAP Business AI Platform, designed for agent interoperability and governed A2A communication. It is not a replacement for SAP Destination service or SAP Cloud Connector, which address connectivity and secure access to systems and services including Cloud to on-prem systems.
Q: Does SAP Agent Gateway also provide access to MCP endpoints in individual backend systems, or is it limited to A2A communication between agents?
A: SAP Agent Gateway focuses on A2A communication and collaboration between SAP and non-SAP agents. Access to backend capabilities through Model Context Protocol (MCP) can be enabled through SAP Integration Suite, where MCP-based tools can expose SAP APIs in a governed manner.
For more information, see A2A and MCP for AI Agent Interoperability
Q: If an agent running in the managed Joule runtime needs to access an on-premises SAP S/4HANA system, can SAP Cloud Connector still be used?
A: Yes. SAP Cloud Connector continues to be available and is explicitly relevant for securely connecting services and workloads based on SAP Business AI Platform to on-premises systems. It remains an important connectivity option for agentic or AI-enabled solutions that need to invoke capabilities in an on-premises SAP S/4HANA landscape.
See Pro-Code AI Agents on SAP Business AI Platform: Bring Your Own Agent
Q: Will users be able to choose or configure which LLM generates artifacts such as intent definitions, product requirements, specifications, or solution implementations?
A: Agent builders can select the LLM according to their preferences or needs with respect to cost, efficiency and also sovereignty.
See the Availability of Generative AI Models and more on Sovereignty
Q: What technology stack will be used to generate agentic solutions such as applications and workflows? Will established SAP technologies such as CAP, SAP Fiori, and SAP Build Process Automation continue to be used, or will workflows be replaced by n8n?
A: The target is not a complete replacement of established SAP development and workflow technologies. Agentic solutions are intended to combine applications, workflows, integrations, skills, and agents according to the needs of the business process.
At present, support or integration work is planned for technologies such as CAP, SAP Fiori, and React. n8n workflows are being considered for the relevant workflow scenarios. Architecturally, the important point is that applications and workflows remain part of the solution.
Q: How will the decisions, plans, reasoning steps, tool calls, and actions of AI agents be made transparent and auditable for end users, administrators, and auditors?
A: The target is to log agentic activities so that execution is traceable. Actions triggered in backend systems should continue to be handled and logged through the normal controls and audit mechanisms of those backend systems.
Agents will also persist context and reasoning artifacts across interactions as decision lineage: what information was known, what was considered, which option was chosen, and what outcome resulted. Human corrections are intended to become structured decision traces that contribute to a context graph combining semantics, decision history, and operational context.
Q: What about auditability, for example, with respect to audit-proof processing and compliance requirements?
A: Agentic workflows need end-to-end traceability. The target architecture includes governance and observability capabilities, including OpenTelemetry-based traces, logs, and metrics, with agent identifiers and execution traces that connect each action to the agent, the work it performed, and the outcome. SAP Cloud ALM extends to AI-aware operations.
Backend transactions should continue to be handled and logged by the relevant system of record. AI orchestration logs complement the existing application, security, and audit logs.
Foundation Layer
Foundation Models and LLMs
Q: How about SAP-RPT-1? Is it a third-party frontier model that SAP has further trained?
A: No, SAP-RPT-1, SAP-RPT-1.5 and higher are relational foundation models working on structured and tabular data. They are intended for the use cases regression, classification, and recommendation. SAP trains and provides these models as part of its AI capabilities for enterprise data scenarios.
For details, refer to the SAP RPT-1 documentation.
For a complete list of models, including LLMs and SAP-RPT, available through the Generative AI Hub, refer to the Availability of Generative AI Models.
Q: What role do SAP foundation models, especially SAP-RPT-1, play in the SAP AI Native North Star Architecture? Will they be consumable outside SAP AI Core or generative AI hub, and can customers self-host them?
A: SAP-RPT-1 has a specific role as a model for structured, relational business data. It is trained on enterprise data such as financial ledgers, transaction records, and supply-chain tables, enabling predictions without requiring customer-specific model training. It complements the large language models and other machine-learning approaches.
Self-hosting is not the intended productive deployment model. Although certain SAP-RPT models may be technically available through public channels such as Hugging Face, this is for experimental purpose only and not approved for productive customer use. For productive enterprise scenarios, customers should use the SAP-hosted and governed models available through SAP AI Core and the generative AI hub.
See also the SAP-RPT Playground
Q: For in-context learning in SAP-RPT, does the context data need to include all relevant target values? Otherwise, how can the model know the correct value?
A: For a prediction or classification scenario, the context data defines the set of possible output values, the model cannot “invent” values. For regression, the target is a continuous numeric range, predicted values are calculated by regression and do not need to be exactly present as part of the context data.
Knowledge Graph
Q: Can customers inspect and, where appropriate, correct the content of the SAP Knowledge Graph? How are conflicting or contradictory facts resolved, for example, where SAP-delivered metadata and customer-specific extensions describe the same business concept differently?
A: The SAP AI Native North Star architecture describes SAP Knowledge Graph as the semantic backbone that connects API and service metadata, business semantics, data-product metadata, and customer-specific extensions such as custom fields, custom APIs, and tenant-specific configuration.
The long-term target is a customer-specific knowledge graph built on a shared enterprise ontology. Domain-specific knowledge graphs should retain autonomy while being connected through shared concepts, creating one logical view across the SAP landscape. This implies a need for governed maintenance, provenance, ownership, and conflict-resolution mechanisms for customer-specific content.
The SAP BDC Ontology Manager (SAP AI Native North Star 2026 Q4) adds a live ontology on top of SAP Knowledge Graph. It unifies SAP and non-SAP data and is continuously enriched by customer feedback, new data products, and evolving business processes. However, the details are not yet defined for the user interface, governance workflow, or conflict-resolution algorithm through which customers will inspect, amend, approve, or reconcile contradictory graph content.
Q: SAP Knowledge Graph includes authorization rules as data-product metadata. Are these rules descriptive only, or are they actively enforced during semantic traversal across entity and system boundaries? For example, if an agent moves from an S/4HANA supplier entity to an Ariba supplier entity, is authorization enforced at every source-system hop or according to the data product’s authorization model?
A: SAP Knowledge Graph provides semantic relationships and grounding; it does not enforce authorization decisions. Data-product access is governed through Authorization Management Service, and access checks apply when the consumer requests concrete objects or data.
In other words, the graph can help an agent discover that an S/4HANA supplier concept relates to an Ariba supplier concept, but it will not bypass the authorization checks of the relevant data product, API, or underlying access service.
Q: Will process knowledge from SAP LeanIX be incorporated into SAP Knowledge Graph?
A: Process knowledge from SAP Signavio and landscape and architecture data from SAP LeanIX is expected to contribute to SAP Knowledge Graph, but this integration is still work in progress. Conceptually, the process and architecture knowledge will enrich the graph’s cross-domain business semantics and relationships among applications, processes, APIs, and enterprise entities.
Q: Will customer-developed agents be able to access SAP Knowledge Graph directly?
A: This is under discussion. The current working assumption is that agents running in the SAP context, especially Joule and Joule agents, will use SAP Knowledge Graph directly for grounding when accessing APIs and data products and other business entities.
For custom or external agents, the available integration model, direct graph-access APIs, authorization model, and contractual boundaries still need to be confirmed.
Q: How will SAP Knowledge Graph be made available to existing customer-managed LLM platforms, agentic platforms, and AI assistants, not only Joule? Where will the graph reside, and how can SAP-managed and customer-managed agents share or combine context to create a unified enterprise view?
A: The initial focus is on Joule and Joule agents using SAP Knowledge Graph within the SAP environment. The SAP Knowledge Graph will be the semantic backbone that grounds natural-language requests in SAP APIs, data models, business entities, and data products.
For external agents, the currently described direction is indirect use through agent-to-agent (A2A) interaction, rather than unrestricted direct access to the SAP Knowledge Graph. This can allow an external agent to delegate an SAP-specific task to a SAP-side agent that uses SAP Knowledge Graph and governed data products internally.
The long-term architectural vision is a customer-specific knowledge graph connected through a shared enterprise ontology, in which domain-specific graphs remain autonomous but interoperate through shared concepts. That direction shall support a more unified context across SAP and customer-managed domains.
Business Data Cloud
Q: How can a customer expose data from a custom SAP Business AI Platform application, for example, one built with CAP and SAP HANA Cloud, as a governed data product in SAP Business Data Cloud? What is the supported path for creating, publishing, and consuming it?
A: SAP’s BDC recognizes customer-defined data products alongside SAP-managed and partner-defined data products. In the target architecture, a data product is a curated, business-ready dataset with meaningful metadata, including ownership, schema, authorization rules, lineage, freshness, and lifecycle management. It is intended to be discoverable and consumable by analytics, data-science platforms, and AI agents.
See also Implement and Extend SAP-managed Domain Content in SAP BDC
For custom data sources, the currently documented route is to integrate and model the data in SAP Datasphere, using its native connectivity and customer-managed storage and modeling capabilities. See also SAP’s BDC FAQ
A Data Product Creation Agent is work in progress.
Q: Can SAP Business Data Cloud, particularly SAP Datasphere and SAP Analytics Cloud, also be used as a development platform for custom applications and custom analytics where no standard SAP solution exists?
A: Yes, SAP Datasphere and SAP Analytics Cloud can be used for customer-specific data integration, semantic modeling, analytics, planning, and custom analytical content. BDC is intended to combine governed SAP and non-SAP data with analytics, planning, data engineering, and AI/ML capabilities. SAP also positions the broader SAP Business AI platform as the environment for building and operating AI-enabled solutions.
Q: When sensitive S/4HANA cost-center, ledger, or other business data is published as a governed data product in SAP Business Data Cloud, does the original transactional authorization model travel with the data product?
A: A data product has its own defined authorization rules and governed consumption model. Its access controls can be deliberately different from the authorization model of the originating transactional application, provided this is designed and governed appropriately.
A practical implication is that restricting direct access to source-system raw data does not automatically guarantee the same restriction in the data product. The data product’s own authorization design, including who can access which records, attributes, and derived metrics, must be defined, tested, and governed.
Illustration: A user might not be allowed to display individual S/4HANA journal entries in the transactional system, while the user may be allowed to consume an aggregated finance data product in SAC. That can be appropriate, but only if the data product’s authorization policy intentionally permits the aggregate while protecting disallowed record-level detail.
Q: On Data Products: When users query a data product, how can they know whether the returned result set is complete? Are records excluded due to authorization reported separately, for example, as a count of suppressed records?
A: Yes, the expected behavior is analogous to conventional authorization-controlled reporting: users receive only the records they are authorized to access, while unauthorized records are not returned. Unauthorized information is filtered out before it reaches an agent or other consumer.
Q: For an agent that must perform write operations, when should it use BDC data products and when is an MCP server or application API the better approach?
A: Use governed BDC data products primarily for read-oriented, analytical, and cross-domain scenarios, such as aggregations, statistics, planning, trend analysis, or questions that combine data across lines of business. Data products are the curated and governed interfaces for dashboards, data science, and Joule-supported AI agents.
For transactional or write scenarios, application APIs exposed through an MCP server are usually the better fit. Customer-specific MCP servers can be enabled on the basis of public APIs and made available to SAP-side agents. A write action should be processed by the owning application through its established write API, validation logic, business rules, and authorization checks.
See also SAP API Policy
Platform Layer
Q: How can an enterprise manage custom agents centrally? Will there be a consolidated view of agents, their dependencies and access rights, as well as monitoring capabilities?
A: SAP AI Agent Hub is the place for managing and governing custom agents centrally. It manages the full agent lifecycle, from planning and development through discovery and provisioning to observability, governance, and optimization. Agent mining discovers agents that already exist across the enterprise, and skills mapping connects agents to the roles and business processes they serve. The intended operating model also includes lifecycle management of agentic solutions and their dependencies.
The Process Layer describes a solution as more than one isolated agent: it can include applications, workflows, one or more agents, APIs, and related dependencies, managed together as a deployable solution with a shared lifecycle.
For runtime observability, OpenTelemetry-based monitoring of agents and applications, including operational health, agent actions, reasoning context, and invoked services will be used.
Q: How are agents deployed? Are they automatically deployed to SAP BTP or the SAP Business AI Platform?
A: The expected deployment model is deployment to an automatically provisioned SAP Business AI Platform environment and its unified agent runtime.
Both creation paths, pro-code development with an agent SDK and prompt-driven development through Joule Studio, produce the same canonical, code-based artifact and deploy to the same runtime. This supports portability, version control, auditability, and a consistent operational model.
The differentiation between the platforms in this question is referring to a transition time when customers may have both in place.
Q: How will lifecycle management work for agentic solutions? If a change is required, how will the solution be modified, tested, versioned, and redeployed?
A: The objective is to manage agents together with their dependencies, such as APIs, backend services, integrations, skills, applications, and workflows, and to control initial deployment and redeployment accordingly. Details are work in progress. SAP AI Agent Hub will play a significant role here.
Q: The infrastructure layer relies on hyperscale cloud providers. How does the architecture address customers’ sovereignty requirements, for example, where workloads must not run on non-sovereign public-cloud infrastructure or need to remain within a specific jurisdiction?
A: SAP’s multitier cloud deployment model includes public cloud, private cloud, SAP Sovereign Cloud offerings, and SAP Sovereign Cloud On-Site offerings for customer-selected or customer-owned data centers. These options are intended to support control over data, infrastructure, compliance, and the use of compliant large language models in line with local legal and regulatory requirements. Work on sovereign cloud capabilities involves SAP, hyperscalers, and other service providers and is in progress.
See also the section on Sovereignty
Q: How can customers extend or adapt SAP-delivered agents? In particular, will there be an approach comparable to traditional customer-specific enhancements, but without directly modifying SAP-delivered code?
A: An extensibility approach is being designed and developed. Customers and partners customize agents without modifying the underlying code through four patterns: tools through the Model Context Protocol (MCP), skills as reusable building blocks, pre- and post-execution hooks, and instructions that precondition the agent's behavior with domain knowledge and operating guidelines.
Further details will evolve in upcoming iterations and through early-adopter feedback.
Q: What connectivity model will enable CAP applications running in the managed runtime to access other CAP-based services in the managed runtime? More specifically, can declarative deployment and service configuration, for example, through assets.yaml, be used to connect a CAP service to managed-runtime services, beyond simply exposing agent-to-agent connectivity?
A: This is a valid requirement and is technically feasible in principle. The exact connectivity model, supported configuration, and timeline for general availability are still being clarified.
Q: Can Joule Work also interact with on-premises systems? Technically, this should be possible as long as an API is available.
A: In principle, on-premises integration is feasible. The SAP Integration Suite and its MCP Gateway are the mechanisms for governed exposure of SAP and non-SAP APIs, while customer-managed SAP Business AI Platform environments can host integrations and self-managed agents.
Disclaimer
This document is not subject to your license agreement or any other service or subscription agreement with SAP. SAP has no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality mentioned therein. This document, or any related presentation, and SAP’s strategy and possible future developments, products, and platforms, directions, and functionality are all subject to change and may be changed by SAP at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or noninfringement. This document is for informational purposes and may not be incorporated into a contract. SAP assumes no responsibility for errors or omissions in this document, except if such damages were caused by SAP’s willful misconduct or gross negligence. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions. For all recent and planned innovations, potential data protection and privacy features include simplified deletion of personal data, reporting of personal data to an identified data subject, restricted access to personal data, masking of personal data, read access logging to special categories of personal data, change logging of personal data, and consent management mechanisms.