Open vs. closed agent architecture: SAP A2A, Salesforce Headless 360, and ServiceNow Action Fabric

1. What distinguishes open and closed agent architectures

With the rise of autonomous AI agents, enterprise platforms face an architectural question that goes beyond mere functionality: How are agents allowed to access the system, and who controls this access? Two fundamental patterns are emerging.

A closed architecture routes every agent through a defined, vendor-proprietary gateway. Access to data and actions occurs only through this controlled channel; external agents must comply with the platform provider's protocol. An open architecture provides data, workflows, and actions via interfaces and the Model Context Protocol, allowing any agent to use them directly without necessarily passing through a vendor-specific AI layer.

1. Why this is more than just a technical detail. The choice between open and closed determines who retains control over the agent that ultimately triggers a change in the system. In the SAP change context, this is immediately relevant because a change initiated by an agent follows the same path to production as any other.

2. Distinguishing from the Frankenstein debate. The discussion regarding an uncontrolled multitude of third-party agents has been held elsewhere. This is not about the image of a patchwork system, but about the concrete architectural difference between three major platforms and its consequences for governance.

2. Why the issue becomes acute in 2026

1. Agents act on production systems. Agents are no longer limited to answering questions; they execute multi-step processes and trigger actions with real-world consequences. As soon as an agent can initiate a change to a productive business system, the architecture of its access becomes a governance issue.

2. The major platforms are choosing opposite paths. By spring 2026, the divide has become visible. SAP is pursuing a controlled, platform-native path, while Salesforce and ServiceNow are deliberately opening their systems to any agent. The same task—giving agents access to business actions—is thus being solved in completely different ways architecturally.

3. Regulation raises the stakes. With the obligations of the EU AI Act taking effect in August 2026 and the requirements already in place from NIS2 and DORA, the question of which agent is allowed to trigger which action and how this is verified becomes a compliance issue. The architecture of agent access helps determine how well these obligations can be met.

4. The choice is long-lasting. An access architecture, once chosen, shapes the landscape for years. Deciding today on a closed or open model determines how flexible or how controlled the agent landscape will be in the future.

3. Comparing the three vendor approaches

In 2026, the three major platforms represent three different answers to the same question.

1. SAP, the controlled path via Joule. SAP positions access to agentic use cases via agent-to-agent communication through Joule as the intended path. According to SAP, public interfaces are intended for static applications, not for dynamic third-party agents. SAP justifies this by citing the governance required for a multi-tenant platform. This is complemented by the SAP AI Agent Hub, a vendor-agnostic control plane for discovering, inventorying, and managing SAP and non-SAP agents as well as MCP servers, with policies defining which agent can access which data and processes.

2. Salesforce, the open path via Headless 360. With Headless 360, Salesforce has introduced an architecture in which data, workflows, and actions are accessible via interfaces, MCP tools, or the command line. A multitude of MCP tools can be used from various agent runtimes without a vendor-specific AI interface necessarily acting as a mandatory gateway.

3. ServiceNow, the open path via Action Fabric. With Action Fabric, ServiceNow has opened up long-established workflows, playbooks, approval chains, and business rules to any AI agent via interfaces and MCP. The logic of the respective action remains within the platform, while the agent invokes defined, rule-bound actions.

4. The common thread and the difference. Salesforce and ServiceNow are clearly opting for an open model where the platform serves as the execution layer and the choice of agent lies with the customer. SAP is opting for a controlled model where the platform's own channel is the intended path. Both approaches have an internal logic, but they differ fundamentally in where control over the agent resides.

4. Where architectural choice becomes a governance risk

1. The closed model concentrates control. A controlled channel simplifies governance because every access point passes through a single instance. However, it shifts decision-making power more heavily toward the platform operator. The real governance question here is not which gateway is the most secure, but whether the organization retains the choice to use another one, because a system that allows only one path ultimately controls those who walk it.

2. The open model distributes responsibility. Open access gives the customer flexibility and the freedom to choose their agent, but it requires that governance be established by the customer themselves. Without an internal control and approval instance, openness can lead to uncontrolled access, especially when many agents are accessing the same actions in parallel.

3. The common blind spot is SAP production. Regardless of the model, the question remains: what happens when an agent triggers a change that lands in an SAP system? Neither the openness of Salesforce or ServiceNow nor the controlled Joule channel from SAP replaces change governance that enforces a mandatory "no" before reaching SAP production.

4. The burden of proof applies to both models. Whether open or closed, the regulatory obligation to provide proof remains. It must be traceable which agent triggered which action and on what basis it was approved. This audit trail is not automatically complete in either model; it must be consciously created.

5. An evaluation framework for SAP organizations

The architectural debate is not merely a spectator sport for SAP customers, as their landscapes increasingly mix SAP and non-SAP platforms. The following points help determine your own position.

1. Clarify the access path for each platform. Determine the path through which agents access each involved platform—whether controlled via a vendor-specific channel or open via interfaces and MCP. This inventory alone reveals where control and where openness prevail.

2. Define your own governance entity. Regardless of the platform model, you need a dedicated entity to decide which agent-driven changes are permitted in production. This is mandatory for open platforms and, for closed ones, it supplements the vendor's own controls with a customer-specific perspective.

3. Inventory your agent landscape. Track which agents and MCP servers are accessing which systems, including those from third-party vendors. A central inventory is the prerequisite for controlling and verifying access in the first place.

4. Establish accountability intentionally. For every agent-driven change, ensure there is documentation of which agent triggered it and how it was approved. This proof bridges the architectural question with the end-to-end audit trail required by regulators.

5. Secure SAP production independently. Route agent-driven changes into SAP production through the same change governance process as any other change. The agent platform's architecture does not replace this control.

6. Tool Landscape

The following table compares the three platform approaches and includes SAP-side change governance for contrast. It demonstrates that agent access architecture and SAP production control are two distinct issues.

¹ Solutive AG is the initiator of the Change Orchestration Institute. The assessment in the table is a self-disclosure by the provider and is not part of an editorially independent validation. The Orchestration Layer is not an agent platform but addresses change governance prior to SAP production. It is included in the table for contrast, not as a comparable alternative to the three platform approaches.

The table makes it clear that none of the agent platforms replace SAP-specific change governance. SAP, Salesforce, and ServiceNow address the question of agent access, but the question of whether an agent-driven change is permitted in SAP production exists on a separate level. Complete governance combines the platforms' access architecture with independent change governance on the SAP side.

7. Operational consequences for SAP organizations

The architectural debate leads to concrete steps.

The first consequence concerns clarity regarding the models. SAP organizations should be aware that the platforms they use follow different agent architectures: controlled in the case of SAP, and open in the case of Salesforce and ServiceNow. This clarity is the foundation for all further decisions.

The second consequence concerns your own control. Regardless of the platform model, you need a dedicated governance entity for agent-driven changes, especially where open platforms intentionally shift responsibility to the customer.

The third consequence concerns verification. The regulatory obligation to make agent-driven changes traceable applies to both models and must be implemented intentionally, rather than expected as an automatic byproduct of the platform.

The fourth consequence concerns SAP production. The path of an agent-driven change into an SAP production system must be managed through the same change governance as any other change, because the agent platform's access architecture and the control of SAP production are two different tasks.