Agents and A2A
A data source does not interface directly to users. An agent does, and it uses the data source to answer the SAP part of a conversation. That conversation can start inside Neptune DXP - Open Edition or from an external system.
The request path
Every request passes through the same layers, each with one job:
- Caller
-
A person in a Neptune DXP - Open Edition chat, or an external orchestrator such as SAP Joule.
- Agent
-
Owns the conversation and its history. It decides when to access the data source and how to present the answer. You build it in Naia Agent Studio.
- Data source
-
Governs and answers one SAP request. It plans the request, runs it as the user, and returns the result.
- SAP system
-
Runs the operations and applies its own authorizations.
Wherever the caller is, the data source is the point where SAP access is governed. See Data security and governance.
How the agent reaches the data source
You attach a data source on the agent’s Connectivity tab, in its SAP data sources
panel. The agent reaches it over A2A, exposed as the access_sap tool, and calls
it like any other tool in a conversation. See
Attach the data source to an agent.
For a request that takes a long time, switch on Run tasks in background for the data source so the user can keep chatting while it runs. This uses the agent background-tasks feature.
The agent’s own model has a data-access setting of its own, separate from the data source’s, so set both. See Data security and governance.
Write agent instructions for a data source
The data source instruction describes what the data source holds. The agent’s instruction decides when the agent accesses the data source, what it asks, and in which order. Define the sequence of calls here, not in the data source instruction. For agent instructions in general, see Agent instructions.
Send precise requests
Each request the agent sends to a data source should cover a single purpose and include the keys it needs, such as a purchase order number, vendor number, or purchasing organization. A request that is vague, contains pasted text, or combines several questions can cause the data source to reply with its list of capabilities instead of data.
The data source answers each request on its own, so a request must not rely on an earlier result. See Answering one request at a time.
Scope lookups over hierarchies
For questions over hierarchical data, such as purchase orders with their items and schedule lines, or bills of material, state which objects the agent expands and where it stops. For example:
Read schedule lines only for open purchase order items, which are items with a
quantity still to be delivered. Do not request schedule lines for items that are
fully delivered.
Without a scope, the agent may request the schedule lines of every item, including completed items that do not affect the answer.
Ground answers in data
The agent’s instruction decides when the agent uses a data source and when it
answers from general knowledge. Avoid blanket rules in either direction. A rule
such as Always access SAP leads to unnecessary or failing calls for questions the
data source cannot answer. With no rule at all, the agent may answer from general
knowledge and invent identifiers or values. Asked Which vendors have the largest
open purchase orders, by value?, an ungrounded agent may name well-known suppliers
instead of the vendors in your SAP system.
Define grounding by type of information instead:
| Type of information | Source |
|---|---|
Identifiers, such as purchase order, vendor, or material numbers. Amounts, quantities, dates, and statuses. |
A data source or tool result only, never inferred. If a call fails or returns nothing, the agent says so. |
Explanations, recommendations, and suggested next steps |
General knowledge is allowed, based on the retrieved data where available. |
For questions that need both, instruct the agent to retrieve data first and reason on it afterwards, and list the lookups expected for each type of question the agent handles. For example:
When asked why a purchase order is overdue, first read the order, its items, and
the schedule lines of each open item. Base your explanation on these results. Never
state a purchase order number, vendor number, amount, or date that did not come
from a data source or tool result.
Without this instruction, an agent asked why a purchase order is overdue may describe common causes of late deliveries in general terms without reading the order, and may mention order or vendor numbers that do not exist. With it, the agent reads the order, finds an open item whose delivery date has passed, and explains the delay from that result.
A2A and external callers
The caller does not have to be inside Neptune DXP - Open Edition. An agent can be exposed over the agent-to-agent (A2A) protocol, so other agents and orchestrators can call it, including SAP Joule. A request that arrives over A2A follows the same path: the agent accesses its data source, and the data source governs the SAP access exactly as it does for a local chat.
Exposing an agent over A2A, and registering an external agent to call, are set up in Naia Agent Studio, not in the AI Context Hub: on the agent’s Connectivity tab, and as an external (A2A) agent. Inbound callers authenticate with the methods the agent card advertises, including OAuth 2.0 client credentials.
| Connecting SAP Joule to an agent is an agent-level setup, comprising a BTP destination, the Joule Studio CLI, and a capability definition, and does not touch the AI Context Hub. A separate guide covering it is available from Neptune on request. When the Joule-facing agent has a data source attached, Joule reaches SAP through it, governed by the data source. |