Building on my recent A2A work I decided to tackle how integration changes in an Agentic era. As organisations start experimenting with AI agents, an old question comes back in a slightly new form: how should systems connect to each other? For years, the answer was often a data warehouse, an API, batch transfer, DBLinks, or some form of enterprise integration layer. Those patterns still matter. But agentic AI introduces two newer ideas into the conversation: MCP and A2A.
The mistake would be to treat MCP and A2A as replacements for what already exists. A better way to think about them is as new layers in the integration landscape.
๐ช๐ต๐ฎ๐ ๐ถ๐ ๐ถ๐?
Integration used to be mostly about moving data between systems. That is still important. But in an agentic environment, integration is also about enabling AI agents to find information, use tools, trigger actions, and sometimes work with other agents. That creates four useful patterns to understand.
๐ญ. ๐๐ฎ๐๐ฎ ๐๐ฎ๐ฟ๐ฒ๐ต๐ผ๐๐๐ฒ A data warehouse brings data from multiple systems into a curated, governed environment for reporting, analysis, dashboards, and decision-making. It is still one of the best ways to create a common view of the organisation. In fundamental terms, this is where you go when you need trusted business information.
๐ฎ. ๐๐ฃ๐ An API is a defined way for one system to request data or trigger a function in another system. APIs are mature, reliable, testable, and well understood by technical teams. This is still the right pattern when the interaction is specific and repeatable: create a ticket, update a record, retrieve a customer profile, submit a transaction.
๐ฏ. ๐ ๐๐ฃ MCP, or Model Context Protocol, is a newer standard designed to help AI agents connect to external systems, tools, data sources, and even workflows. This matters because agents need context and tools. MCP is one way of exposing those capabilities in a more agent-friendly and standardized way.
๐ฐ. ๐๐ฎ๐ A2A, or Agent-to-Agent, is about agents communicating with other agents. Google introduced A2A as a protocol to let agents communicate, exchange information, and coordinate actions across enterprise platforms and applications. This is different from an agent using a tool.
With A2A, one agent may ask another specialist agent to do part of the work. For example, a procurement agent might ask a legal agent to review contract risk, or a service agent might ask a finance agent to check billing status. That is a different kind of integration problem - it is less about connecting systems and more about coordinating capabilities.
๐ช๐ต๐ฎ๐ ๐ฑ๐ผ๐ฒ๐ ๐ถ๐ ๐บ๐ฒ๐ฎ๐ป ๐ณ๐ฟ๐ผ๐บ ๐ฎ ๐ฏ๐๐๐ถ๐ป๐ฒ๐๐ ๐ฝ๐ฒ๐ฟ๐๐ฝ๐ฒ๐ฐ๐๐ถ๐๐ฒ?
This is not a choice between old and new. It is a question of choosing the right pattern for the right problem.
Data warehouses are still highly relevant. Agentic AI does not remove the need for trusted data. If anything, it increases it. Agents that reason over inconsistent, unmanaged, or poorly defined data can produce confident but unreliable answers.
APIs remain the workhorse of enterprise integration. When the business need is clear and repeatable, APIs are often the cleanest answer. They provide well understood structure, reliability, ownership, and auditability.
MCP is useful when agents need governed access to tools and context. The business value is not simply technical convenience. The value is that agents can access approved sources and tools in a more consistent way. But this still needs strong controls around permissions, logging, data classification, and approval workflows (See Stacklok link.).
A2A becomes useful when work crosses capability boundaries. In larger organisations, different teams may eventually own different agents. HR, finance, legal, procurement, operations, and IT may each have specialist agents. A2A starts to matter when those agents need to collaborate.
The governance model becomes more important, not less. In a traditional API call, the system interaction is usually known in advance. In an agentic workflow, the path may be more dynamic. That raises questions about authority, evidence, escalation, and accountability.
Not every problem needs an agentic pattern. If a dashboard answers the question, use the dashboard. If an API solves the transaction, use the API. If a warehouse provides the trusted view, use the warehouse. Agents should not become a shortcut around good architecture.
The real risk is accidental integration. Without a clear framework, organisations may end up with agents calling tools, scraping systems, querying databases, and exchanging information in ways that are difficult to monitor or explain.
A simple decision model helps:
| Business need | Best starting point |
|---|---|
| โWe need a trusted view of business performance.โ | Data warehouse |
| โWe need one system to reliably interact with another.โ | API |
| โWe need an agent to use approved tools or data.โ | MCP |
| โWe need one agent to delegate to another specialist agent.โ | A2A |
๐ช๐ต๐ฎ๐ ๐ฑ๐ผ ๐ ๐ฑ๐ผ ๐๐ถ๐๐ต ๐ถ๐?
The practical starting point is not to redesign everything but to understand the context for each tool and make the right integration decisions as agentic AI starts to appear inside the organisation.
Map your current integration patterns. Identify where you already rely on data warehouses, APIs, manual exports, spreadsheets, reporting tools, and workflow systems. Most organisations have more integration complexity than they realise. Your solution and enterprise architecture teams are likely to have these patterns.
Separate information needs from action needs. โTell me what is happeningโ is different from โdo something in a system.โ The first may point to a data warehouse or reporting layer. The second may require APIs, workflow controls, or agent tool access (although this may blur).
Decide where agents are allowed to get their context. Do not let each experiment define its own answer - just because a PoC worked, doesnโt mean itโs the right choice. Identify approved data sources, document repositories, systems of record, and knowledge bases.
Decide what agents are allowed to do. Reading data, summarising a document, drafting a response, creating a ticket, approving a payment, and changing a customer record are very different levels of authority.
Use MCP where agent access needs to be repeatable and governed. MCP is most useful when you want agents to access tools and data in a more standardized way, rather than building one-off connections for every experiment.
Use A2A where there is a real delegation pattern. A2A makes sense when one agent needs another agentโs capability, domain knowledge, or workflow ownership. It is probably overkill if the task is just a simple system lookup.
Keep APIs in the architecture. Agentic integration does not remove the need for APIs. In many cases, MCP servers and agents are likely to still depend on well-designed APIs underneath.
Build the governance layer early. Identity, access control, audit logs, human approval points, monitoring, fallback paths, and exception handling should not be afterthoughts.
Start with low-risk use cases. Good early candidates include knowledge retrieval, service desk assistance, policy search, document review, reporting support, and workflow drafting. These help teams learn without immediately giving agents too much authority.
The principle I would use is - do not let agents become the integration architecture. Let agents operate through the integration architecture.
The agentic era does not make classic integration obsolete, it adds new layers. Data warehouses still provide trusted information. APIs still provide reliable system access. MCP helps agents connect to approved tools and data. A2A helps agents collaborate across specialist domains.
The organisations that get this right will not be the ones that connect everything to everything as quickly as possible. They will be the ones that make deliberate choices about trust, authority, context, and control.