Interface messages fail in the systems that are hardest to ask questions of. Ask in SAP Joule what broke and why: the assistant reads your SAP systems over MCP, explains the failure in plain language, and gives you the steps to fix it.
Return on investment
Most of the time spent on a failed interface message is not the fix. It is noticing the failure, finding it, and working out why. The assistant takes those steps off your team and leaves them one decision: approve the fix.
See every skill with prompts you can paste into Joule in the documentation.
The assistant does not integrate with one system and stop. Each system is reached through a Model Context Protocol server that exposes a small, well-named set of reads and actions. Interface messages fail in AIF, as IDocs, and in the middleware between systems - and the useful question usually spans more than one of them.
Because MCP is an open standard, the same servers serve this assistant, your own agents, and whatever model you move to next year. Adding another system is a tool definition rather than another point-to-point integration to maintain.
The servers run in your BTP account and reach on-premise systems through Destinations and the Cloud Connector. Calls run under a real principal, so SAP authorisation objects still decide what is visible.
The people who know whether a missing delivery matters are rarely the people with the authorisations to investigate it. So the usual path is a ticket, a queue, and a day lost before anyone has looked.
Here they ask in plain language - which interfaces failed, what this payload was trying to do, what it would take to fix it - and get an answer grounded in the actual systems. The specialists get their time back for the failures that genuinely need them.
Two sources, kept deliberately separate, because they answer different questions.
Interface specifications, runbooks, mapping documents and past incident write-ups - retrieved from where they already live, including Amazon S3 and SharePoint. These explain how an interface is supposed to behave, and they are the part a generic assistant is missing.
What the message actually contained, what the system actually did, what the master data says right now - read from SAP at the moment of the question. This is deliberately not copied into a document index: a snapshot of transactional data drifts, and an answer built on a stale copy is worse than no answer. Documents are retrieved; facts are queried.
The path is short on purpose. A failure is surfaced and grouped with others like it. The assistant reads the payload and the interface definition, checks the live system state, and explains the root cause against your own documentation. It then produces the ordered fix steps - and, where you have allowed it, applies the correction and reprocesses the message. Every step is recorded. See the whole flow as a diagram in How error resolution works.
Everything the assistant does is instrumented with Boidra Platform, so you can see the traces, what it cost, and whether the answers were any good.
The documentation covers the assistant's skills with example prompts, its architecture, the landscape connector and the Agents app, how it connects to SAP Joule over A2A, and the settings an administrator can change.
The assistant is deployed and observed with Boidra Platform. Its traces, cost, alerts and the AI Asset Dashboard are covered in the Boidra Platform documentation.
Interface messages wherever they fail - AIF, IDocs, and the middleware in between. The assistant reaches each system through an MCP server rather than a bespoke connector, so adding another interface type is a tool definition rather than a new integration project.
No - that is the point. Someone asks which interfaces failed overnight and why, in plain language. The assistant queries the systems, groups the failures, and explains what happened. The people who understand the business process can ask directly instead of raising a ticket for someone who understands the GUI.
Two different places, deliberately. Documents - interface specifications, runbooks, mapping documents, past incident write-ups - are retrieved from your own stores, including Amazon S3 and SharePoint. Transactional facts are read live from SAP at the moment of the question, over MCP. Documents explain how an interface is supposed to work; only the system knows what it actually did.
Only where you let it. Read and analysis are the default. Write paths carry guardrails - confirmation steps, value limits and human-in-the-loop - and every action is traced, so an auditor can see who asked, what the assistant did, and what changed.
Yes. The MCP servers run in your BTP account and reach on-premise and private-cloud systems through Destinations and the Cloud Connector, so no inbound hole is opened in your network. Authentication and SAP authorisation objects still apply.
Tell us what you’re trying to automate in SAP. We’ll tell you - honestly - whether an agent is the right tool, and how we’d start.
