Enterprise software is now being asked to serve two kinds of caller: people using interfaces, and AI applications acting on someone's behalf. The second caller needs the same data and the same actions, with different guarantees. It must be discoverable by software, permitted explicitly, limited in scope, and recorded well enough that a transaction can be reconstructed afterwards.
Two open protocols address that gap. The Model Context Protocol (MCP) standardises how an AI application reaches tools and data. The Agent2Agent protocol (A2A) standardises how independent agents discover each other and delegate work. Neither replaces your APIs, and neither makes a badly modelled system safe to expose. What they do is define the contract, so integration work stops being bespoke for every client.
This article explains what both protocols specify, how they differ, and what an enterprise actually has to build. It closes with the cases where conventional APIs or simpler automation remain the better answer.
Why enterprise software is being asked to support agents
An internal assistant that can read a customer record and raise a credit note is more useful than one that writes a summary of that record. The moment software can act, four enterprise requirements appear: identity of the acting party, least-privilege authorisation, an audit trail, and a defined failure mode for every action.
Historically each integration solved this privately. The commercial argument for MCP and A2A is the same one that made REST and OpenAPI useful: a standard contract reduces the cost of the next integration, and makes the behaviour auditable and testable across vendors.
What is Model Context Protocol?
MCP is an open standard for connecting AI applications to external systems, described in its own documentation as a common connector in the way USB-C is a common port. It uses JSON-RPC for message exchange and defines a small set of roles.
| Component | Role |
|---|---|
| Host | The AI application the user interacts with, such as a desktop assistant, an IDE or an enterprise chat client |
| Client | The connector inside the host that maintains a one-to-one connection to a specific server |
| Server | The service that exposes a system's capabilities in MCP terms |
A server exposes three primary primitives. Tools are functions the model may call, each with a declared schema. Resources are addressable data the application can read, such as a record or document. Prompts are reusable templates the server offers. Clients contribute capabilities in the other direction, including sampling, where the server asks the host's model to generate text, and elicitation, where the server requests additional information from the user.
Transport is either standard input and output for locally run servers, or Streamable HTTP for remote servers. The specification defines an OAuth-based authorisation model for HTTP transports, and it is versioned by date: at the time of writing the current published revision is dated 28 July 2026. Server features are extensible, which is how capabilities such as interactive application views are being added without changing the core. The primary documentation is at modelcontextprotocol.io, and it is the only source to build against for a specific version.
What is Agent2Agent?
A2A is an open standard for communication between AI agents built on different frameworks and by different vendors. It was originated by Google and donated to the Linux Foundation, where it is maintained by a technical steering committee with representatives from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow, under the Apache 2.0 licence.
| Concept | What it is |
|---|---|
| User | The party whose goal the work serves, human or automated |
| Client agent | The agent that initiates the request on the user's behalf |
| Remote agent | The agent exposing an HTTP endpoint that implements A2A; opaque to the caller |
| Agent Card | A JSON document describing identity, endpoint, skills, capabilities and authentication requirements |
| Task | A stateful unit of work with its own identifier and lifecycle, including long-running operations |
| Message and Part | A single turn of communication, carrying text, file references or structured data |
| Artifact | A tangible output produced during a task, such as a document or structured record |
Interaction uses JSON-RPC over HTTP. Results can be returned in a single response, streamed as server-sent events for incremental progress, or delivered through push notifications to a client-provided webhook for long-running or disconnected work. Authentication requirements are declared in the Agent Card and credentials travel in HTTP headers, separate from the protocol messages themselves. A2A deliberately does not specify how an agent calls its own tools, and it is not an agent framework; it is the communication layer between agents.
MCP versus A2A
| Dimension | MCP | A2A |
|---|---|---|
| Direction | Agent to tools, data and resources | Agent to agent |
| Primary problem | How one agent reaches a system's capabilities | How independent agents discover each other and delegate work |
| Discovery | Server configuration, registry or client setup | Agent Card published by the remote agent |
| Unit of interaction | Tool call, resource read, prompt | Task with lifecycle, messages and artifacts |
| Statefulness | Largely request-oriented | Explicit task state, including long-running work |
| Visibility of internals | The host sees declared tools and schemas | The remote agent is opaque; internals are not shared |
| Transport | Standard input and output, or Streamable HTTP | HTTP with JSON-RPC, streaming and push notifications |
| Relationship | Complementary: equips an agent with tools | Complementary: lets equipped agents collaborate |
The practical summary: use MCP to give an agent access to a specific system, and A2A when two agents, possibly from different vendors, have to cooperate on a task without exposing their internals.
Integrating existing enterprise systems
| System | What an agent typically needs | Integration consideration |
|---|---|---|
| CRM | Account and contact lookup, activity history, opportunity updates | Field-level permissions and duplicate handling must be enforced server side |
| ERP | Orders, invoices, stock positions, supplier records | Read-heavy access with tightly scoped write tools; accounting periods and reversals matter |
| Inventory platforms | Availability, reservations, transfers | Reservation semantics must match warehouse reality, not a cache |
| Marketplaces | Listings, orders, settlement status | Rate limits and per-marketplace rules dominate the design |
| Pricing engines | Contract price, discount rules, validity windows | Return price with validity and provenance, never a bare number |
| Payment systems | Authorisation status, refunds, tokenised credentials | Agents should never handle raw card data; use tokens and merchant-of-record rules |
| Logistics | Rates, labels, tracking events, exceptions | Exception handling is the real work, not label creation |
| Customer service | Ticket creation, history lookup, response drafting | Human approval before anything reaches a customer |
Technical architecture
A workable enterprise pattern has five layers.
- System of record and its API. The authoritative service, unchanged in its rules, with permissions enforced there rather than in the agent.
- A tool gateway. A control point that maps capabilities to scopes, applies rate limits, validates payloads and records every call.
- MCP servers. Thin adapters exposing a bounded set of tools and resources for a specific domain, running as a service identity rather than as any individual user.
- Agent runtime and orchestration. The component that plans, sequences calls, handles failures and decides when to escalate. For cross-organisation work, this is where A2A client and server roles appear.
- Identity and telemetry. Delegated identity, credentials per agent, and structured logs linking user intent, tool calls, outputs and business outcome.
Two design rules prevent most incidents. First, the agent's identity is separate from the user's, and its scopes are narrower than the user's own rights. Second, every write goes through the same validation as human input, because a tool that trusts the model has moved its trust boundary to the least reliable component.
Security and governance
- Least-privilege permissions. Per-tool scopes, no wildcard access to a database, and no administrative tools exposed by default.
- Identity and authentication. OAuth-based authorisation for HTTP transports, credentials per agent, short-lived tokens, and revocation that works without redeployment.
- Audit logs. Every tool call with actor, delegation chain, arguments, result and correlation identifier, retained for the period your compliance position requires.
- Prompt injection. Treat retrieved content as untrusted input. Separate instructions from data, restrict which tools can be composed in a single task, and require approval for irreversible actions.
- Data protection. Minimise what enters a model context, define retention, and know which data leaves your environment. In the UAE, personal data processing falls under Federal Decree-Law No. 45 of 2021, with separate regimes in the DIFC and ADGM; where EU customers are involved, the AI Act's transparency obligations are also relevant.
- Human approvals. Any irreversible action above a defined value or risk threshold, and anything customer-facing, requires a person to approve.
- Operational resilience. Timeouts, retries with idempotency keys, circuit breakers, and a defined degraded mode when the model or a system of record is unavailable.
Commercial implementation patterns
| Pattern | What the agent does | Why it pays back |
|---|---|---|
| AI-enabled CRM | Summarises history, drafts follow-ups, updates fields after a call | Removes record-keeping work from sales and service teams |
| Procurement automation | Checks contract pricing, assembles a basket, raises a requisition | Repetitive and rule-bound, with clear approval thresholds |
| Inventory management | Reconciles stock discrepancies, drafts replenishment proposals | High-volume reconciliation that people do badly under time pressure |
| B2B marketplace integration | Matches demand to supplier stock, checks terms, proposes orders | Two-sided data work that scales poorly with headcount |
| Consumer electronics supply chain | Tracks serials, warranty status and returns across partners | Serial-level accuracy is a data discipline agents enforce well |
| Circular economy ecosystems | Verifies condition, provenance and eligibility across participants | Grading and provenance are structured rules that benefit from automation |
We expand on the commerce-facing subset in our agentic commerce article, and on oversight design in AI agents for business.
When conventional APIs or simpler automation are better
MCP and A2A earn their cost when you need discoverability and reuse across multiple clients or organisations. They are unnecessary ceremony when one application calls one service on a fixed path.
Choose a conventional API and workflow engine when the sequence is known in advance, when there is a single consumer, when determinism and testability matter more than flexibility, or when the actions must be strictly auditable and repeatable. A scheduled job that reconciles inventory should stay a scheduled job. An agent belongs where the path genuinely varies and where judgement within bounds is the value.
Implementation roadmap
| Stage | Objective | Complete when |
|---|---|---|
| 1. Use case and boundary | Choose one bounded workflow with a measured cost | Baseline volume, handling time and failure rate recorded |
| 2. Data and API readiness | Confirm the system of record exposes the needed capabilities | Each required action has a stable, permissioned endpoint |
| 3. Tool design | Define tools, schemas, scopes and validation rules | Read and write tools tested against real data |
| 4. Governance | Identity, logging, approval thresholds, retention | An audit can reconstruct any action end to end |
| 5. Pilot | Operate with human review on a narrow slice | Accuracy and cost per case measured against the baseline |
| 6. Scale | Extend tools and workflows, or add A2A for cross-organisation work | Cost per case stable, escalation rate understood |
How Sardo Group builds enterprise AI integration
Our work connects the three layers this requires: the systems of record and their APIs, the tool and agent layer that reaches them, and the governance that makes the result operable. In practice that means API and integration engineering, MCP server implementation for internal systems, agent workflow design with approval thresholds, and ecosystem architecture where several organisations participate.
Relevant capabilities: AI and automation, API and systems integration, platform development and ecosystem development.
Frequently asked questions
What is MCP integration?
It is the work of exposing an existing system's data and actions to AI applications through a Model Context Protocol server, with declared tools, scoped permissions and audit logging, rather than granting an assistant broad access to a database.
Do we need both MCP and A2A?
Only if agents must cooperate across team or organisational boundaries. MCP covers an agent reaching your systems. A2A covers agents delegating tasks to each other. Many enterprises start with MCP alone and add A2A when a second party is involved.
Is A2A a Google proprietary protocol?
No. It was originated by Google and donated to the Linux Foundation, is licensed under Apache 2.0, and is governed by a technical steering committee with participants from several major vendors.
How do we prevent an agent doing something destructive?
Scope every tool narrowly, run the agent under its own identity with fewer rights than a human user, validate all writes server side, require idempotency keys, and put human approval in front of anything irreversible.
What is the biggest risk in these projects?
Prompt injection through retrieved content, followed by over-broad permissions that turn a prompt flaw into a data incident. Both are design problems, and both are cheaper to solve before a pilot than after.
Can this work with an on-premise ERP?
Yes, provided some controlled egress path exists for the tool gateway. Where an external model is not permitted, a self-hosted model with the same tool contracts can be used, at higher infrastructure cost and typically lower capability.
Discuss Your Enterprise AI Integration Project
If you are deciding whether a workflow needs an agent, an API or a scheduled job, that is the right conversation to have before any protocol work begins. We will assess the systems involved, the permissions required and the oversight model, then scope what to build. Start with AI and automation, review API and systems integration, or start your enterprise AI integration project and we will respond with a technical assessment against your systems.