Intelligent Interface Monitoring with SAP Joule

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:

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

Tools

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

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]

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]

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]

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.

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:

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/..."
  }
}

{
  "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/..."
  }
}

{
  "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:

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

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

{
  "emailStatus": "sent",
  "emailTitle": "AIF Interface Monitoring Report — 2026-03-31",
  "emailBody": "<h2>Interface Monitoring Summary</h2><p>Critical: 2 interfaces...</p>",
  "recipient": "integration-ops@company.com",
  "message": "Email 'AIF Interface Monitoring Report — 2026-03-31' 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:

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:

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 demonstrates that modern enterprise AI combined with process orchestration can deliver practical, production-ready outcomes, not just conceptual prototypes.

Using SAP Joule capability artifacts together with a disciplined approach to agent design and document grounding, it is possible to introduce controlled “ops-level autonomy” that remains safe, traceable, and aligned with business processes.

Achieving this, however, requires deliberate design decisions. It starts with a clear understanding of the LLM being used, including its strengths, limitations, and potential failure modes. It also requires a secure architecture, where data access, tool permissions, and agent boundaries are explicitly defined and enforced. Finally, it depends on structured prompt management, including versioning, testing, and governance in SAP AI Launchpad to ensure consistent, auditable, and predictable agent behavior.

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

References & Useful Links

• SAP Joule - Overview

• SAP AI Core - Document Grounding

• SAP AI Core - Prompt Template Management

• SAP AI Launchpad

• SAP Cloud Application Programming Model (CAP)

• Model Context Protocol (MCP) - Overview

• Agent-to-Agent Protocol (A2A)

• Joule Pro-Code Development Tools
  
  

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