Community
Artificial Intelligence Blogs Posts
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Why “domain intelligence” is the missing piece

Foundation models are impressive generalists, but enterprise questions are specific. “Which quotation gives us the best win/win with this customer?” is not answered by general world knowledge. It is answered by your master data, your pricing logic, and the relationships between them.

That is where two capabilities on SAP Business AI Platform come together. First, a Knowledge Graph captures your domain as connected, machine-readable facts with explicit semantics. Second, the A2A protocol lets a custom agent that reasons over that graph plug directly into Joule, so the intelligence shows up where users already work.

The picture below shows how the pieces fit: Joule stays the orchestrator, a pro-code agent does the specialized work, and the SAP HANA Cloud Knowledge Graph engine holds the domain intelligence the agent draws on.

Architecture - Custom Intelligence in Joule.png

Joule orchestrates; the pro-code agent reasons; the Knowledge Graph engine holds your domain intelligence.

Step 1: Capture domain knowledge as an Ontology and Knowledge Graph

A Knowledge Graph is only as smart as the ontology behind it. The ontology is the semantic model: it names your entities, describes their attributes, and, crucially, records how they relate. That semantic layer is what turns raw content into meaning a machine can reason over.

Importantly, your source does not have to be a database. The SAP HANA Cloud Knowledge Graph samples cover two paths. In the first, unstructured documents such as PDFs are turned into a graph: a large language model extracts the entities and the relationships between them from the text and converts them into RDF triples. In the second, tabular data is modeled as an ontology from its schema, keys and joins. Either way, the result is serialized to RDF in Turtle (.ttl), so the same downstream steps apply regardless of where the knowledge came from.

Loading it into SAP HANA Cloud is straightforward. You ingest the triples through the SPARQL_EXECUTE procedure, or stage the file in cloud storage and pull it in with IMPORT FROM RDF FILE from the Database Explorer. Once ingested, the graph is queryable with SPARQL, including from natural language, so business users can ask a question in plain words and get a grounded, relationship-aware answer.

The pipeline looks like this, from your source data on the left to a query-ready graph on the right. The labels are deliberately generic; your entities, documents and agent will be your own:

Flow - From Data to Dialogue.png

Build the graph once, then reuse it across pro-code agents and every Joule conversation.

The important idea for partners: you model the graph once. The same semantic asset can then ground many agents and many conversations, rather than being rebuilt for each use case.

Step 2: Bring your agent into Joule with A2A

Joule acts as the central orchestrator and entry point. When a user makes a request, Joule’s planning and reasoning engine decides how to fulfil it, which can include delegating the task to a custom agent. SAP supports two integration patterns, and the right one depends on how the agent was built.

For low-code agents built with Joule Studio, integration is largely automatic. Deploying the agent generates the required Joule artifacts, including a Joule Scenario and a Dialog Function, and registers the scenario in Joule’s Scenario Catalog. There is no endpoint or protocol to manage by hand.

For pro-code agents, the “Bring Your Own Agent” (BYOA) pattern uses the open A2A protocol, so you can build with any framework that speaks A2A. The flow is clean and decoupled:

  1. Expose your agent as an A2A server with an HTTP endpoint that follows the A2A specification.
  2. Create a Joule Scenario for the agent, and add a Dialog Function with an action of type agent-request.
  3. Point that Dialog Function at your agent’s A2A endpoint.

At runtime, Joule becomes the A2A client. It prepares a request using the message/send method (A2A version 0.3.0), sends the user’s utterance to your agent, waits for the response, and presents the result. Joule handles synchronous replies within a 60 second window; for longer work, the agent uses push notifications to a Joule webhook, and context and task IDs carry state across multi-turn conversations. Secure communication is established through an Identity Authentication Service (IAS) App2App trust relationship between Joule and your agent.

One practical note worth setting expectations on: the Agent Gateway is not yet generally available, so today the architecture supports unidirectional, outbound communication from Joule to the agent. The bidirectional building blocks are expected to follow.

Two building blocks today, one coherent example soon

It is worth being clear about where things stand. Today these are two separate reference assets, not one finished scenario. The Knowledge Graph samples show how to build and query a graph from your documents or tables. The pro-code agent reference, btp-joule-a2a-pro-code-agent, shows the other half: a production-grade agent that plugs into Joule over A2A.

That reference agent is written in TypeScript on CAP, uses LangGraph for its logic, reaches foundation models through the SAP Cloud SDK for AI and Generative AI Hub, and demonstrates the full A2A round trip with Joule, including human-in-the-loop and webhook-based asynchronous updates, with Terraform for the BAIP setup. A companion community walkthrough by Felix Bartler shows the minimal version of the same A2A wiring.

The target pattern joins the two halves: a pro-code agent that treats your HANA Cloud Knowledge Graph as a tool, issuing SPARQL queries to fetch precise, relationship-aware facts, then reasoning with Generative AI Hub before returning a grounded answer through Joule. The graph supplies the trustworthy facts; the model supplies the reasoning; A2A supplies the delivery.

What this unlocks for SAP partners

This is where the partner opportunity is clearest. The pattern lets you help your customers bring their own domain data, knowledge and ontology into SAP, where it becomes a governed, reusable Knowledge Graph that grounds Joule. Instead of standing up a separate AI stack, your customers leverage the SAP platform investments they already have, including SAP HANA Cloud, SAP Business AI Platform (BAIP), Generative AI Hub and Joule, while you supply the domain expertise and the agent on top. Their proprietary knowledge stays in their SAP landscape, under their governance.

The advantages compound. The Knowledge Graph is a reusable asset that encodes domain expertise once and grounds every agent that uses it, which reduces hallucination and makes answers defensible. A2A is an open standard, so you keep framework freedom and avoid lock-in while still landing natively inside the SAP experience. And because the intelligence surfaces through Joule, adoption is frictionless: customers’ users get specialized answers in the assistant they already trust.

The build path is incremental. Start by turning one high-value slice of a customer’s knowledge, a set of documents or a key data model, into an ontology and Knowledge Graph in SAP HANA Cloud. Wrap a pro-code agent around it that queries the graph and reasons with Generative AI Hub. Then expose the agent over A2A and register it as a Joule Scenario. Each step is independently useful, and together they turn generic AI into your customer’s AI.

Further resources to get you started

 

Coming next - Stay tuned!

Coming next.  We are building a coherent, end-to-end example that connects a custom Knowledge Graph to a Joule agent over A2A, and we are preparing a hands-on workshop to walk partners through it.

Share your use cases and questions in the comments. Don't hesitate to reach out as well in case you want some more close support.

Comment
2 Comments
Labels in this area