Across our recent discussions with SAP leaders, one pattern is clear: AI demand is no longer generic – it is highly specific and operational.

We consistently see the same expectations:

Agents that answer based on internal, legacy knowledge – without hallucination
Agents that propose solutions grounded in company documentation (SharePoint, Wikis, internal shares)
Agents that can take action – send emails, create Jira issues, trigger workflows, make decisions
Agents that behave like a domain-aware product architect, not just a chatbot

Our goal is to build a fully automated agentic interface monitoring solution – one that detects issues, reasons about root causes, and acts without waiting for human initiation. This implementation is the first step in that direction: we initiated the process manually, and we are actively improving it toward full autonomy – using SAP Joule, SAP AI Core, SAP AI SDK, Document Grounding and a multi-agent architecture.

1. Why This Is Exciting

S/4HANA interfaces can produce hundreds of errors daily
Traditional ops are reactive: issues are discovered manually, too late
This project turns monitoring into a proactive, in-context issue decision engine

Outcome: quicker root cause elimination, less reconciliation effort, faster finance close.

But this is just the beginning. The bigger vision is an agent that acts as a fully specialized interface architect – one that automatically monitors and provides deep insight across all interface types in the system: EDI, OData, Proxy, and beyond. Not just error counts, but architectural awareness: interface dependencies, throughput patterns, configuration risks, and compliance gaps.

Such an agent would not wait to be asked. It would continuously observe the integration landscape, surface anomalies, explain root causes in architectural context, and recommend or execute corrective actions (as system-triggered) – combining the knowledge of an experienced integration consultant with the tireless availability of an automated system.

2. What We Built

We built a content-based AI agent orchestrated by SAP Joule that transforms SAP interface monitoring into a structured, actionable process.

This agent:

Reads interface errors (AIF) via OData (exposed as MCP server or single endpoints)
Identifies patterns and highest-impact issues
Retrieves resolution guidance using SAP AI Core document grounding (knowledge from Microsoft SharePoint)
Uses OpenAI for reasoning and structured output
Presents results as: Markdown reports or UI Cards
Enables immediate actions, for example: send email (CAP service), create Jira issue (MCP server)

Agent Architecture concern: content-based vs procode-based

SAP Joule supports two agent paradigms:

	Content-Based Agents	Procode-Based Agents
Approach	YAML declarative – no custom code	SAP AI SDK + LangChain / LangGraph
Best for	Fast rollout, workflows, HITL	100+ tool discovery, complex orchestration
Tooling	Joule Studio / Joule Editor	SAP AI SDK, multi-agent coordination
Protocol	Local agents	Remote agents via A2A

We chose Content-Based agents for this solution – defined entirely in YAML capability artifacts, running locally within Joule. This gave us:

Rapid iteration without deploying custom microservices
Native human-in-the-loop support built into the framework
Full compatibility with SAP AI Core grounding and OData tools

For scenarios requiring dynamic tool discovery across 100+ APIs or cross-domain agent coordination, Procode-based agents (LangGraph + SAP AI SDK) over the A2A protocol are the right next step – and exactly where we are heading.

3. How It Works

The solution is based on a multi-agent architecture on SAP BTP, using a content-based agent approach where agents are defined declaratively in YAML – no custom code required.

What is a YAML file? YAML (Yet Another Markup Language) is a human-readable configuration format. Instead of writing code, you describe the agent’s behavior, tools, and instructions in plain structured text – similar to a recipe. In SAP Joule, each agent is defined as a YAML capability artifact that specifies its name, skills, available tools, and prompt instructions.

Agents

Agent	Responsibility
`interface_analysis_agent`	Analyzes AIF errors, grounds findings in SharePoint knowledge
`notification_agent`	Prepares and sends HTML email notifications
`jira_agent`	Creates structured Jira tickets from the analysis

Tools

Each agent operates through dedicated tools, enabling clear separation of responsibilities and controlled access to external systems:

Tool	Integration	Purpose
OData API	S/4HANA AIF	Interface error data
AI Core	SAP Document Grounding	Grounded document retrieval from SharePoint
CAP Service	SMTP	Email notifications
MCP Server	Jira REST API	Issue creation

Orchestration Flow

User ask question (Joule)
    │
    ▼
[Scenario: Interface Analysis]  ← slots: timePeriod
    │
    ▼
[interface_analysis_agent]  ←── OData: AIF error data
    │                       ←── AI Core: document grounding (SharePoint)
    │
    ├──▶ Markdown report  OR  UI Cards
    ├──▶ [notification_agent]  →  draft email generated  →  human approval  →  send email
    └──▶ [jira_agent]          →  draft Jira ticket generated  →  human approval  →  create Jira issue

Architecture diagram

The diagram below shows the overall Joule-centered architecture and routing between orchestration agents, specialist agents, and external tools.

In this structure, Joule routes user intents to scenario-level assistants, delegates technical analysis to domain specialists, and connects communication channels and Confluence/Jira-style tooling through MCP and backend services.

Agent in Action: Step-by-Step Walkthrough

The following screenshots show the actual agent process running end-to-end inside SAP Joule.

Step 1 – User initiates the analysis

The user sends a single message: “generate interface summary?”. Joule collects the required slot (timePeriod) and immediately begins processing. Within seconds the agent returns a structured markdown report.

Step 2 – Structured report with grounded resolution

The agent returns a full Error Summary table ranked by affected interfaces and message class. Critically, the resolution guidance – root cause explanation and ordered fix steps – is sourced exclusively from the enterprise knowledge catalog via document grounding, not generated by the LLM from memory.

Step 3 – Grounding source transparency + action selection

After the analysis, Joule surfaces the exact Grounding Source used: document title, file path, and the SharePoint URL. This makes the agent’s reasoning fully auditable. The user then selects the next action – draft an email or create a Jira issue.

Step 4 – Email draft for human review (HITL)

The notification_agent prepares a structured HTML email – recipient, subject, interface table, key findings, and recommended actions – and presents it as a draft inside Joule. The user reviews and explicitly approves before anything is sent.

Step 5 – Jira issue creation confirmation (HITL)

The jira_agent prepares a full Jira ticket (project, summary, assignee, description with grounding reference) and requires explicit user confirmation before creating it. No ticket is created without approval.

The diagram specifically demonstrates three core Joule capabilities in action:

MCP Server – defined as a toolkit under the agent definition in Joule, alongside subagents; this makes external tools (Jira, email) available to the agent as first-class capabilities without custom middleware
Subagent Call – also registered as part of the agent’s toolkit definition, enabling the orchestrator to delegate specialized tasks to dedicated sub-agents (notification_agent, jira_agent) natively within Joule
Document Grounding – implemented as an API-request dialog function in Joule, allowing the analysis agent to retrieve resolution guidance directly from SharePoint via SAP AI Core, ensuring responses are anchored in enterprise knowledge

4. The “Secret Sauce” – Useful Design Patterns

Grounded AI: No Guessing

The agent never hallucinates resolution steps. All guidance comes exclusively from:

SharePoint-hosted, controlled knowledge catalog (e.g. sap_error_codes_dataset.txt)
Metadata-filtered access – controlling which agent can access which knowledge folder

AI should explain based on enterprise knowledge – not invent.

Content-Based Agent (No Code)

We intentionally used a YAML-driven, content-based agent approach in Joule. Compared to code-based agents (still needed for complex scenarios), content-based agents enable rapid rollout with minimal coding – and are fully supported by the A2A protocol. This gives a powerful option for Joule, making it capable of communicating with any agent (including non-SAP agents).

That said, we are already exploring a pro-code alternative leveraging Joule A2A integration (LangGraph + SAP AI SDK). Early signals suggest this approach may unlock better performance, finer control over agent coordination, and tighter cross-domain integration – areas where declarative YAML has natural limits. We will share results from that experiment in a follow-up.

Structured Output First

LLMs generate non-deterministic output by default. To make agent responses reliably consumable by downstream systems, we designed a strict output JSON schema:

Schema Field	Type	Used For
`interfaceSummary`	string	High-level narrative summary of the analysis
`errorResolution`	string	Overall resolution guidance text
`summaryTable`	array	UI card rendering – one entry per interface (name, type, error count, criticality)
`keyFindings`	object	Critical / Warning / Healthy interface lists, most frequent error, affected source systems
`errorSummary`	array	All unique errors ranked by occurrence – no resolution content, used for triage view
`errorResolutionDetail`	object	Root cause + ordered resolution steps for top error – from document grounding only
`groundingSource`	object	Document title, file path, SharePoint URL of the grounding source used

Each summaryTable entry carries: interface name, description, type, version, error/warning counts, criticality (Critical / Warning / Healthy), and the specific message class and text. The errorResolutionDetail is intentionally populated only from grounding – the agent is not allowed to invent resolution steps.

{
  "summaryTable": [
    {
      "ifname": "ORDERS05_INBOUND",
      "type": "IDoc",
      "totalErrors": 12,
      "criticality": "Critical",
      "msgtx": "Partner profile not found"
    }
  ],
  "keyFindings": {
    "criticalInterfaces": ["ORDERS05_INBOUND"],
    "warningInterfaces": ["DESADV_OUT"],
    "healthyInterfaces": ["INVOIC02_IN"],
    "mostFrequentError": {
      "msgid": "B1", "msgno": "012", "occurrences": 12
    }
  },
  "errorResolutionDetail": {
    "msgid": "B1", "msgno": "012",
    "rootCause": "Partner profile missing for logical system",
    "resolutionSteps": ["Check WE20", "Create missing partner profile", "Reprocess IDocs"]
  },
  "groundingSource": {
    "title": "SAP Error Code Catalog",
    "filePath": "/sites/integration/sap_error_codes_dataset.txt",
    "webUrl": "https://company.sharepoint.com/..."
  }
}

By enforcing a fixed output schema, we fully control what the agent responds with – the summary structure is deterministic and predictable, regardless of the underlying LLM output. This enables: UI rendering (Joule cards), automation (email, Jira), and future analytics pipelines.

The same principle applies to every agent in the solution. The notification_agent has its own strict output schema – controlling exactly what gets returned after an email operation:

Schema Field	Type	Used For
`message`	string	User-facing message shown in Joule (e.g. email preview with subject)
`emailStatus`	string	Delivery status – e.g. `sent` / `not sent`
`emailTitle`	string	Email subject line
`emailBody`	string	Full HTML email body
`recipient`	string	Target email address
`apiResponse`	string	Raw response from the email sending API
`dataJson`	string	JSON payload sent in the API request body

{
  "emailStatus": "sent",
  "emailTitle": "AIF Interface Monitoring Report - 2024-01-15",
  "emailBody": "<h2>Interface Monitoring Summary</h2><p>Critical: 2 interfaces...</p>",
  "recipient": "integration-ops@company.com",
  "message": "Email 'AIF Interface Monitoring Report - 2024-01-15' has been sent to integration-ops@company.com"
}

This schema drives the human-in-the-loop preview shown in Joule before the user approves sending – the message field is rendered as the confirmation card, and emailBody is the draft the user reviews.

SAP Joule System-Triggered Agent (Upcoming)

One of the highest-value upcoming extensions is a system-triggered agent. This part of the solution is not yet published, but the business impact is already clear.

Instead of waiting for a user to start the analysis manually, the agent can be scheduled (for example every hour, every 12h, or before finance close) and run automatically in the background.

Value for operations teams:

No manual kickoff for recurring monitoring runs
Faster detection of high-impact interface failures
Consistent reporting cadence across teams and time zones
Lower dependency on individual availability for routine checks

In short: orchestration becomes proactive by default. Human users stay focused on approvals and exceptions, while the monitoring cycle itself can run on schedule.

Human-in-the-Loop (HITL) by Design

Human-in-the-loop enables agents to act autonomously where safe, while enforcing explicit user approval for irreversible actions:

Action	Flow
Email	Preview → Approval → Send
Jira	Preview → Approval → Create

This ensures: compliance, auditability, and safe automation.

5. Example: Daily Ops Hook

“Every day at 10:00, run interface analysis for the last 12h and send a compressed operational report to integration-ops@company.com. Critical errors create Jira tickets with Priority=Highest automatically, pending manual confirmation. No more night shifts chasing random integration inconsistencies.”

6. When to Use SAP Joule

SAP Joule can be applied across a spectrum of use cases – from simple lookups to complex agentic workflows:

Use Case	Description	Agent Needed
Informational	Answer questions from structured or unstructured data – e.g. “What is the status of interface X?” Simple capabilities, no agent required.	No
Navigational	Guide the user to the right transaction, app, or process – e.g. “How do I reprocess failed IDocs?” Simple capabilities, no agent required.	No
Deep Analysis & Calculation	Complex reasoning, reporting, pattern detection, multi-step calculations – e.g. interface error analysis, financial reporting, root cause investigation. Requires an agent with tools and grounding.	Yes
Workflow with Human Approvals	Deterministic multi-step processes with conditional branching and explicit user confirmation gates – e.g. analyze → draft email → approve → send; or analyze → draft Jira ticket → approve → create. Combines agent reasoning with HITL control.	Yes

This solution covers the two most advanced use cases: deep analysis (grounded error analysis with structured output) and workflow with human approvals (email and Jira actions gated by explicit user confirmation).

7. What’s Next

We are already pushing this further:

System-triggered agents – automatic reaction to AIF errors (event-driven)
A2A (Agent-to-Agent) communication – agents coordinating across domains via remote protocol
Deeper Joule integration – MCP servers for extended tool connectivity
“One-click fix” scenarios – auto-correct + automatic reprocessing of failed interfaces

Continuing the Journey

This project is ongoing and we are committed to taking it further. The next phase focuses on three areas:

More MCP Servers – expanding the toolkit with additional integrations (monitoring dashboards, alerting systems, SAP middleware APIs) to give the agent broader reach and more actionable capabilities
Pro-Code Agent – evolving from content-based YAML agents toward a LangGraph + SAP AI SDK procode agent, enabling dynamic tool discovery, more complex reasoning chains, and cross-domain coordination via the A2A protocol
Richer Informational Capabilities – going beyond error monitoring to cover full interface architectural insight: interface definition, mapping, customer specific value-mapping and important architectural contexts
Pushing Joule Further – we will continue testing and exploring what SAP Joule can truly offer, challenging its boundaries in custom AI scenarios to understand the full range of what can be built and delivered with it in real enterprise contexts

Final Thought

This agent is a powerful example that modern enterprise AI + process orchestration is not just generative talk.

With SAP Joule capability artifacts and strong agent/grounding discipline, you can build “ops-level autonomy” that is safe, traceable, and directly business-impacting.

But results like this can only be achieved with smart and safe design. That means truly understanding the LLM you are working with – its strengths, limitations, and failure modes. It means designing secure applications where data access, tool permissions, and agent boundaries are deliberately controlled. And it means disciplined prompt management – versioning, testing, and governing prompts through SAP AI Launchpad, so that agent behavior stays consistent, auditable, and aligned with business intent.

What do you think? Have you built similar orchestration patterns in SAP Joule? Share your experiences below! 👇

References & Useful Links

#SAP #SAPJoule #AI #EnterpriseAutomation #SAPBTP #S4HANA #AIF #DevOps #SAPCommunity #ArtificialIntelligence #BusinessProcessAutomation

SAPAIinsightsfromthefield.

How AI Agents Actually Connect to SAP: APIs, RFC, ADT, MCP and Beyond