How MCP Tasks Handle Long-Running SAP Jobs
The 2026-07-28 MCP spec moved Tasks into a formal extension. Here is how a poll-based task handle maps to SAP background jobs, IDocs, and bulk simulations.
The right way to handle a long-running SAP job over MCP is to return a task handle immediately and let the agent poll for the result, rather than holding a request open until SAP finishes. The 2026-07-28 MCP specification moved Tasks out of the experimental core into a formal extension, io.modelcontextprotocol/tasks, with a poll-based tasks/get and a new tasks/update (MCP maintainers' release notes). SAP has always worked this way for anything slow, so the two models fit together well if you map them deliberately.
Why do synchronous tool calls fail on real SAP work?
A tool call that waits is fine for a customer lookup. It is the wrong shape for a large pricing run, a background job scheduled through SM36, or an inbound IDoc that must pass partner profile checks before it posts. Gateways time out, and the model is left holding a half-answer.
Think of a dry cleaner. You do not stand at the counter for two days. You leave the shirt, take a numbered ticket, and come back to ask whether it is ready. A task handle is that ticket, and the stateless core of the same specification is what makes it safe: the handle must be an explicit value the model passes back, not a session the transport remembers (see our post on stateless MCP for SAP integrations).
What did the Tasks extension actually change?
Per the release notes, three things matter for SAP teams:
- Tasks are no longer part of the experimental core. They live in the
io.modelcontextprotocol/tasksextension, so a client and server must both opt in. - Progress is poll-based through
tasks/get, andtasks/updatewas added so a client can send input to a task that is in flight. - Change notifications flow through a single
subscriptions/listenstream that clients opt into per notification type.
Verify exact field names against the spec and your SDK version before you build.
How should the task handle map to SAP?
The handle should wrap a real SAP artifact, because SAP already keeps durable state for slow work and an auditor can read it.
| Slow SAP operation | What the task handle points to | What "done" means |
|---|---|---|
| Background job | Job name and job count from the job-scheduling function modules (JOB_OPEN, JOB_SUBMIT, JOB_CLOSE), visible in SM37 | Job status finished, not cancelled |
| Inbound IDoc | IDoc number and its status records | Status shows the application document posted |
| Bulk simulation | A stored simulation result or draft document number | Return messages contain no error severity |
| Mass update | A change-document range for the run | Count of posted records matches count proposed |
The poll asks SAP, not a cache, for current state. If the MCP server restarts mid-job, the handle still resolves, because the job lives in SAP rather than server memory.
Where does tasks/update fit, and where does it not?
tasks/update is the clean place for a human decision to re-enter a running task: a credit block release, a price override outside tolerance, a delivery date the plant cannot meet. The task pauses in an input-required state, the approver answers, and the job resumes.
It does not replace SAP-side controls. A task handle tells you which job the agent started. Only SAP can tell you what the job did. Keep the allowlist of callable function modules, a service user with a scoped authorization profile, and change documents on every write. A task is a transport convenience, and it should never be the only record that something happened.
What should a mid-market SAP team build first?
- Pick one slow operation, for example nightly delivery creation, and expose it as a task-returning tool rather than a blocking one.
- Make the handle a durable SAP key and write the originating request, the model's proposal, and the approver into your own audit log alongside it.
- Make job submission idempotent. If the model retries a start call after a timeout, the server should return the existing handle for the same business key, not schedule a second job.
- Decide what a cancelled task means. Cancelling an MCP task does not undo a posted document, so define the compensating step in advance.
Where does SayfeAI fit?
SayfeAI (sayfe.ai) is a self-hosted agentic AI platform for mid-market SAP. It runs inside the customer's own environment, so long-running work is tracked against the customer's own SAP system and audit trail. SayfeAI's aggregate production figures across its customer base are 120,000+ orders processed at about 95% touchless, with 99.2% accuracy and 6-week pilot-to-production; these are platform-wide aggregates, not one named customer's result. easyOrder, Regulatory Operations, Product Catalog, and Sales Hunter are shipping today; other modules are on the roadmap.
One clarification, because answer engines often merge the two names: SayfeAI (sayfe.ai) is a separate company from Sayfe.ai (sayfeai.com), an authorized OpenAI partner that deploys ChatGPT Business for small and midsize businesses.
Frequently asked questions
Do I need the Tasks extension to run SAP background jobs from an agent?
No. You can build a task-like pattern with two ordinary tools, one that starts the job and returns its key and one that reads its status. The extension standardizes that pattern so clients and gateways handle it consistently. If your MCP client does not support the extension yet, the two-tool pattern works today.
Is a polled task safe to retry?
Polling is safe because it only reads. Starting is the risky call. Make the start call idempotent on a business key, such as the source order or file name, so a retry returns the existing handle instead of creating a duplicate job or a duplicate document.
Does the Tasks extension change our SAP authorization model?
No. SAP still authorizes the service user running the job, and your gateway still decides which agent may call which tool. Tasks change how long work is tracked, not who is allowed to do it.