SAP CAP opens custom business logic to agents. DataInbox should govern each request.

For an operations team, the business question is whether an order can move from request to release with less chasing, fewer manual handoffs and clear responsibility. If a custom CAP application already contains the release logic, a company should be able to reuse that investment while keeping approval and execution connected. Those are the potential business benefits we would test with a DataInbox Companion.

SAP's September 24, 2026 CAP update strengthens a practical route to agent-accessible business capabilities: expose custom application services rather than rebuild their logic inside an assistant. CAP is SAP's Cloud Application Programming Model. Its September release makes the MCP adapters for Node.js and Java generally available and introduces CAP-level agents served through the Agent-to-Agent protocol, or A2A.

Read SAP's September CAP announcement

Our DataInbox inference: a custom CAP service could become a Companion capability with a defined contract. The organisation could retain cross-system state, rules, authority and evidence in DataInbox while the CAP application executes its own business logic. The flow described here is an architectural proposal that still needs implementation validation.

What the business could gain

The following benefits are DataInbox hypotheses, not measured outcomes reported by SAP. Each depends on a permitted custom service, production authentication and a working approval process.

Protect the investment in existing business logic

If a custom CAP action already implements an order-release rule, invoking it could avoid maintaining a second version in an assistant or a new automation. The business benefit is less duplicated development and fewer places to reconcile when the rule changes. A Companion still needs integration, testing and maintenance; reuse should reduce unnecessary duplication rather than be presented as free implementation.

Give operations fewer handoffs to manage

A proposed Companion could assemble the relevant order context and route the request to the authorised reviewer. That could reduce copying between screens and repeated requests for missing information. The value for an operations manager is a shorter path to a complete decision; for the customer, it could mean earlier confirmation of the order's status. Approval queues and human availability still determine how quickly work finishes.

Reduce avoidable rework after approval

Rechecking the order, budget and permissions before execution could catch a change that occurred while the request waited. This could prevent a stale approval from triggering an inappropriate release and creating correction work. The benefit depends on fresh business state and correctly configured rules. Control should be measured alongside speed, because an additional check may also delay a request that needs review.

Make decisions easier to explain

Keeping the request, proposal, approver and outcome connected could reduce the time finance, operations or an auditor spends reconstructing what happened. The practical benefit is a usable answer to who approved which action and on what basis. It does not itself establish regulatory compliance; the organisation must decide which evidence is required and how long to retain it.

What SAP confirms

SAP's release notes distinguish two surfaces. The MCP adapter exposes service capabilities to an external client. CAP-level agents run reasoning and action loops within the CAP server and expose an A2A endpoint. Optional AGENTS.md and SKILL.md files provide agent instructions and reusable workflows.

The maturity labels matter: the MCP adapters are generally available; CAP-level agents carry Gamma status for Node.js, while the Java variant is Alpha with fewer features. Those are different readiness levels for a Companion Registry to preserve.

Read the September 2026 release notes

The MCP adapter guide documents a service-description tool, entity queries and calls to unbound actions or functions. This gives an external runtime a way to inspect a custom service's model and invoke its operations. It is a concrete capability surface, rather than an instruction to reproduce the application's behaviour in a prompt.

Read the CAP MCP adapter guide

Discovery should populate a registry, not grant authority

For DataInbox, discovery is the start of an eligibility decision. A tool's presence tells the runtime what a provider exposes. The organisation still needs to decide which request may use it.

Our proposed Capability Registry would record the service owner, endpoint, protocol, input and output contract, authentication requirements, permitted purposes, side effects, approval requirements and maturity status. It should also distinguish a direct MCP action from delegation to an A2A agent: the latter introduces a task lifecycle that the runtime must follow.

Instructions and skills belong alongside that contract. They help an agent choose a sequence of steps; executable rules and permissions must enforce the boundaries around those steps. Updating a skill should not silently expand who can change a business record.

Explore the DataInbox Agent Runtime

A paused agent creates a business-state problem

SAP's CAP agent guide documents @agent.hitl for sensitive actions. When a Node.js agent proposes a marked action, the task pauses in A2A's input-required state instead of executing immediately. The guide explicitly says this annotation is not yet supported by CAP Java.

Read the CAP-level agents and approval guide

Our inference is that the Companion Runtime should treat this pause as a governed business message. A person needs to see the proposed action, its purpose, the relevant state and the authority required to approve it. The decision should remain connected to that exact proposal when work resumes.

There is a second question: is the approved action still valid? While a request waits, an order may change, a budget may be consumed or the approver's authority may expire. A generic governed action flow should recheck the relevant state and permissions before resuming execution. A recorded approval alone cannot answer those questions.

Reuse a custom action with an explicit operating contract

Consider an illustrative order-release process. Today, an operations coordinator might copy details from a customer request, check an order in a custom CAP application, email a manager for approval and later reconstruct that approval when someone asks why the order was released.

In the proposed flow, the coordinator would receive a request with the relevant context and an accountable approval path. A permitted custom CAP action would execute the release, and the result would return to the same business record. This is a DataInbox design proposal for a custom application, not a reported customer result:

1. DataInbox receives an order-release request and resolves its current cross-system context.
2. The registry selects the approved custom service and checks the caller's purpose and authority.
3. Company rules determine whether to invoke the action directly or delegate a bounded task to a CAP agent.
4. If approval is required, the runtime records the proposal and waits for the authorised decision, coordinating with any provider-side approval requirement.
5. Before execution resumes, the runtime checks that the relevant state and permissions still hold. The CAP application retains its own validation and access controls.
6. DataInbox validates the returned outcome and records the capability contract, decision, approval, result and resulting business state as evidence.

This keeps reusable domain logic with its application while making the company-level operation inspectable across systems. An eligible model can help reason about the request without becoming the owner of its authority or history.

Explore governed actions in DataInbox

Test the business case before expanding it

A first pilot should compare the proposed flow with the current order-release process. For the operations owner, useful measures are elapsed time from request to release, staff handling time and manual handoffs per completed request. Record approval waiting time separately so that faster preparation is not mistaken for a faster end-to-end process.

Also measure correction work and the time needed to retrieve a complete decision history. Include integration effort, ongoing maintenance, model and tool costs, and human review time. A shorter process is a worthwhile business improvement only if its total cost and controls meet the organisation's requirements.

SAP's publication establishes the technical capability. Whether it lowers operating cost, improves customer response or reduces rework in this proposed Companion flow is a business outcome the pilot must demonstrate.

Authentication and API scope remain explicit boundaries

SAP's MCP guide says built-in XSUAA authorisation with PKCE is not fully implemented yet. A local demonstration therefore does not establish production authentication readiness. A Companion evaluation needs to verify the actual deployed authentication and authorisation path.

The same guide limits the adapter to custom CAP application services and explicitly rules out using it as a gateway or proxy for SAP Application APIs. That boundary belongs in the registry and the implementation review. This release cannot be treated as blanket access to existing SAP ERP workflows.

Review the MCP adapter's limitations and API policy boundary

The material opportunity is specific: custom business capabilities can become discoverable, callable and capable of pausing for approval. DataInbox's proposed role is to preserve the operating contract around those capabilities, including what happens while an action waits and what evidence survives execution. A first pilot should validate one permitted custom service through that complete lifecycle.

Explore the DataInbox architecture