Interface messages fail in the systems that are hardest to ask questions of. This agent connects any SAP system over MCP, answers in plain language what broke and why, 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 agent takes those steps off your team and leaves them one decision: approve the fix.
The agent 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 agent, 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 agent 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.
Everything the agent does is instrumented with Boidra Platform, so you can see the traces, what it cost, and whether the answers were any good.
Interface messages wherever they fail - AIF, IDocs, and the middleware in between. The agent 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 agent 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 agent 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.
