A practical guide to architecture, enterprise use cases and a controlled first pilot
Enterprise AI is moving from isolated assistants to connected agents
The first wave of enterprise generative AI focused on assistants that could answer questions, summarize information or support a single task. The next shift is more operational: specialized AI agents coordinating across applications, data and business functions to complete an outcome.
That shift creates a new architectural question. If one agent understands a supply shortage, another can evaluate suppliers and another can update an enterprise system, how do they discover each other, exchange context and coordinate work without creating a new layer of brittle point-to-point integrations?
Agent2Agent, or A2A, provides part of the answer. It gives agents a common way to communicate and collaborate. Model Context Protocol, or MCP, connects an agent to the tools, systems and data it needs. Within the SAP landscape, Joule and Joule Agents bring business context and process intelligence into that model. Our previous article, Agent2Agent Protocol: What It Means for SAP and Enterprise AI, covers how these standards differ and why governance has to anchor any agent network; this article picks up from there and moves into architecture and a first pilot.
The opportunity is not simply to connect more AI. It is to build a governed network in which every agent has a defined role, access boundary and business purpose.
What the architecture looks like in practice
A practical multi-agent architecture can be understood through four layers:
- Business interaction: A user, application or event initiates a goal, such as resolving a supply risk or accelerating a customer response.
- Agent coordination: Joule or another orchestrating agent interprets the goal, identifies the required capabilities and delegates work to specialized agents through A2A.
- Tool and data access: Each agent uses approved tools, APIs and enterprise data. MCP can standardize how an agent connects to these resources, while SAP services provide the business context and authorizations required for enterprise execution.
- Governance and observability: Identity, permissions, monitoring, audit evidence and human approval points control how the network operates.
SAP’s reference architecture is designed to support both directions of integration over time. Joule can already act as an A2A client, allowing it to initiate work with compatible external agents, while SAP has described Agent Gateway as the component intended to let external applications and agents consume Joule Agents. Availability and supported interaction patterns continue to evolve, so organizations should confirm current SAP roadmap and product availability before committing to a bidirectional design, and should plan an initial pilot around the outbound pattern that is available today.
This distinction matters. Enterprises rarely operate a single-vendor technology landscape. A useful agent network must work across SAP applications, cloud platforms, industry systems and custom solutions while maintaining clear security and ownership boundaries.
A manufacturing shortage scenario
Consider a manufacturer facing a projected component shortage that could affect production. In a traditional environment, the issue may move between planning, procurement, supplier communication and finance through emails, dashboards and manual follow-up.
In a controlled multi-agent workflow, the sequence could look different:
- A planning agent detects that available inventory and confirmed supply will not cover an upcoming production requirement.
- The agent shares the task and relevant context with a procurement agent through A2A.
- The procurement agent evaluates approved suppliers, lead times, contractual conditions and alternative materials using authorized enterprise tools and data.
- A finance or risk agent assesses the cost and working-capital impact of the available options.
- The agents return a coordinated recommendation, including the evidence behind it and any exceptions requiring human approval.
- Once an authorized employee approves the recommendation, the appropriate business action is executed and recorded in the relevant system.
The value does not come from removing people from the process. It comes from reducing the time spent collecting information, moving between systems and coordinating routine analysis, while keeping consequential decisions under accountable human control.
Where A2A and MCP each fit
Our previous article covers the distinction between A2A and MCP in detail: A2A standardizes how independent agents discover one another and coordinate work, while MCP standardizes how a single agent connects to the tools, APIs and data it needs. In the architecture above, that distinction maps directly onto two layers: MCP operates at the tool and data access layer, giving each agent a consistent way to reach its authorized resources, while A2A operates at the agent coordination layer, letting Joule or another orchestrator delegate work to those agents and receive results back.
The protocols are therefore complementary within one design rather than alternatives to choose between. A single workflow, such as the manufacturing scenario above, typically uses both: A2A to move the task from the planning agent to the procurement agent to the finance agent, and MCP to let each of those agents reach its own approved systems along the way. Neither protocol removes the enterprise’s responsibility for identity, authorization, data classification, approvals and operational monitoring.
Start with a controlled 90-day pilot
A multi-agent initiative should not begin with a broad objective such as automating an entire department. The strongest first pilot is narrow enough to govern, measurable enough to evaluate and useful enough to prove business value.
Days 1-30: Select and design
- Choose one process with a clear owner, measurable delays and repeatable handoffs.
- Map the decisions, systems, data sources, agent roles and human approval points.
- Define what each agent may read, recommend and execute.
Days 31-60: Build and test
- Connect the minimum number of agents and tools required for the workflow.
- Test incomplete data, conflicting recommendations, unavailable systems and failed handoffs.
- Capture logs and evidence that allow the business owner to understand every material action.
Days 61-90: Run under supervision
- Operate the workflow with human approval before any consequential execution.
- Measure cycle time, manual touches, exception rate, recommendation quality and user confidence.
- Decide whether to scale, redesign or stop based on evidence rather than technical novelty.
What enterprises should not overlook
Interoperability does not automatically create trust. An agent may be technically reachable without being authorized, reliable or suitable for a specific business decision. Our previous article sets out a fuller agent trust model, from admission and permissions through monitoring and eventual removal from the network; the questions below are the operational version of that model, sized for a first pilot.
Before scaling, organizations should be able to answer several questions clearly:
- How is every agent identified, admitted and assigned permissions?
- Which data can each agent access, retain or share with another agent?
- When is human approval mandatory?
- How are disagreements, timeouts and partial failures handled?
- What evidence is recorded for audit, investigation and continuous improvement?
These are not secondary considerations. They determine whether an agent network remains a promising demonstration or becomes a dependable enterprise capability.
From connected agents to coordinated business outcomes
A2A gives enterprises a common language for agent collaboration. MCP gives agents a structured way to connect with tools and context. SAP Joule, Joule Agents and the SAP Business AI Platform bring these capabilities closer to the processes and data on which enterprises already operate.
But successful adoption will not be measured by the number of agents connected. It will be measured by whether those agents reduce friction, improve decisions and deliver traceable business outcomes within the right controls.
For organizations beginning this journey, the right next step is not a fully autonomous enterprise. It is one carefully selected process, one governed architecture and one pilot that can prove value safely.
How Altivate Can Help
Altivate helps organizations connect SAP strategy, enterprise architecture and AI innovation to practical business outcomes. From use-case selection and process design to integration, governance and pilot delivery, we help enterprises move from agentic AI concepts to controlled, value-driven implementation.
Ready to identify where multi-agent AI can create value in your SAP landscape? Contact Altivate to explore a focused pilot built around your business priorities.
