Leverage AI Context Hub for reliable agentic operations

Grant a data source only the services and operations its request need, including the value-lookup operations that resolve names to codes. The orchestration engine chooses operations by semantic search over what you grant, so a broad grant gives it more near-duplicate operations to disambiguate, which slows planning and makes the choice less reliable, while too narrow a grant leaves a request potentially unanswerable.

Grant the specific business object a request needs. If an answer resolves to a related but wrong object, for example Company (BUS0014) instead of Company Code (BUS0002), the correct object was most likely not granted or not ingested. See Grant SAP services and operations.

The system instruction is the baseline context the orchestration engine applies to every request, so it is where you settle what a request leaves open, such as what "open" means, which organizational context to assume, and how to present results. A rule stated once there steers planning for every request, whereas a vague instruction leaves more to inference. See Write the system instructions.

The orchestration engine plans by calling tools, so both AI models on the data source must support tool (function) calling. The primary model does the multi-step planning and self-correction, so its capability sets the ceiling for complex queries, while the lightweight model handles simpler turns at lower cost and latency. See Configure the orchestration engine.

Examples for effective primary, multi-step planning and self-correction models include:

Turn on Enhance with AI during ingestion so the orchestration engine writes richer descriptions of the ingested services. Because the orchestration engine finds operations by semantic similarity to their descriptions rather than by their technical names, description quality directly affects whether the right operation is found. Enhancement is a one-time cost at ingestion that pays back on every request. See Prepare and maintain a connected SAP system.

Data access is layered: each model on the data source has its own LLM Data Access setting, as does the agent that consumes the data source. The setting is a trade-off: withholding values keeps business data out of the model, but a request that needs the model to reason over values cannot be answered while they are withheld. Set each layer to the strictest mode its use case allows. Result Retention is a separate control, governing how much of a result a run keeps once stored. Apply the same principle to it: keep the least a later review needs. Retaining the data shape only avoids storing SAP values beyond the run, so choose the full result with values only where auditing or debugging genuinely requires it. See Data security and governance.

Raise Agent Trace Detail and turn on the Run Log File while you are tuning a data source, then lower them/turn them off for production. Each level logs progressively more, and the Full level captures samples of the SAP response data, so treat verbose tracing as a debugging mode rather than a default. What a run retains also depends on Result Retention. See Data security and governance.

Make sure the ingestion user’s API Factory policy and the SAP-side prerequisites for each source kind are in place, or that kind will not ingest. The catalog can hold only what the ingestion user is authorized to see, so that user’s policy sets the ceiling on what any data source and agent can later reach. See Sources you can connect and Prepare and maintain a connected SAP system.

In SAP BTP landscapes, SAP API Management can front the SAP system and propagate the end user’s identity to the backend. Its value is that SAP applies its own authorizations and audit to each end user, rather than every request arriving as one shared technical user. This is an advanced, optional authentication path for the connected system, not a requirement of the AI Context Hub.

A separate guide covering this setup is available from Neptune on request.

Test representative queries in the Playground and iterate on the configuration until the answers are right, before attaching the data source to an agent. The Playground exercises the data source on its own, apart from an agent’s conversation handling, so you can tune one thing at a time before the agent is in the loop. See Test a request in the Playground.

When an answer is wrong, open the run in the Agent Trace tool and read the plan, the steps, and the SAP calls. Most wrong answers originate in the plan, in the operation chosen, or the parameters filled, so reading the plan first tells you whether the fault is in planning or in execution. See Data security and governance.

A request can resolve to the correct business object and method and still return No data found. Some BAPIs declare an optional date parameter with a default of a single space rather than zeros. SAP does not treat a space as initial for a date field, so the parameter is not replaced with a valid date and the call returns nothing.

This is an SAP-side implementation issue, outside the control of the AI Context Hub.

A data source is developed and tested on one system, then promoted to the systems that run it, such as production. Because a data source answers from the catalog of the SAP system behind it, promotion carries the configuration but not the catalog: each target system needs its own remote-system connection and its own ingestion before the data source can answer there. The granted services and operations resolve against whatever the target has ingested, so a target that exposes different or missing metadata can leave some grants unresolved. Review the data source on each target after promotion, and confirm its grants and a representative request before users rely on it. See Prepare and maintain a connected SAP system.

The AI Context Hub answers each request independently. When a model works from metadata only, result values never enter it, so nothing carries from one request to the next. You cannot take the result of one request and refer back to it in the next. Plan for this by making each request self-contained, so it names the entities and criteria it needs rather than relying on an earlier answer. Where a follow-up genuinely must build on previous values, either combine the steps into one richer request, or give the relevant model the data access to read those values, weighed against the governance trade-off. See Data security and governance.