Introduction
Agent tooling is moving out of the prototype phase and into core software architecture. The reason is straightforward: the ecosystem is beginning to converge on open protocols for how models access tools, data, and other agents. Anthropic introduced the Model Context Protocol (MCP) as an open standard for connecting AI assistants to external systems, describing it as a way to create secure, two-way connections between data sources and AI tools in its launch announcement. OpenAI has since added MCP support to its Agents SDK, Microsoft now documents MCP servers in Copilot Studio, and Google DeepMind has introduced Agent2Agent (A2A) for agent interoperability.
This is the important shift for engineering leaders: agent systems are no longer just about choosing a model. They are becoming integration systems with protocols, permissions, orchestration, and operational boundaries. If you are building AI-native products or internal platforms, the question is no longer whether to support agent tooling standards, but which parts of the stack should be standardized now. That broader AI investment trend is not slowing down. McKinsey estimates generative AI could add $2.6 trillion to $4.4 trillion annually across use cases, while PwC projects AI could contribute up to $15.7 trillion to the global economy by 2030.
For teams already thinking about AI-native delivery, this mirrors a broader pattern I focus on across [technology consulting work](/projects/b1ee3e9a-f77b-4b3f-9066-acfbed12ce6c) and on the [blog](/blog): standards matter most when they reduce coupling and make systems easier to evolve. MCP is starting to look like one of those standards.
Standardize the model-to-tool layer before you standardize everything else
The first thing most teams should standardize is the contract between models and tools. MCP is gaining traction precisely because it addresses a recurring problem in agent systems: every custom tool integration tends to create a new interface, new security assumptions, and new maintenance burden. Anthropic defines MCP as follows:
“Model Context Protocol is an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools.” — Anthropic announcement
That matters because engineering teams need a stable abstraction between applications and the growing set of internal systems agents may need to access: ticketing, docs, source control, observability, CRM, BI, and custom business workflows. When OpenAI adds MCP support to its Agents SDK, it signals that this is not just a vendor-specific idea. When Microsoft documents MCP servers as part of enterprise Copilot workflows, it signals the same pattern is being operationalized in enterprise tooling.
Practically, teams should standardize on a few things now:
First, define a consistent MCP server pattern for internal systems. That means treating tools as managed interfaces rather than one-off function calls embedded inside application code. Second, separate tool definitions from agent workflows so you can reuse the same tool surface across multiple agents and products. Third, enforce consistent authentication, authorization, rate limiting, and auditability at the MCP boundary rather than inside every individual agent implementation.
This is where many early agent systems break down. Teams spend time tuning prompts and model parameters while leaving the tool layer ad hoc. In production, the reverse is often more important. As Thoughtworks has noted in its Technology Radar, MCP is among the notable shifts influencing AI application architecture. That is a good signal that the interface layer itself is becoming strategic infrastructure.
Pair MCP with interoperability, governance, and operational controls
MCP is not the whole story. It helps agents connect to tools and data, but engineering teams also need a standard way for agents to coordinate with other agents and a disciplined way to govern those interactions. That is where A2A becomes relevant. Google describes the relationship clearly:
“A2A is an open protocol that complements Anthropic’s Model Context Protocol (MCP), which provides helpful tools and context to agents.” — Google Developers Blog
The architectural distinction is useful. MCP is increasingly the model-to-tool or model-to-context interface. A2A points toward agent-to-agent interoperability. Teams that expect to build more than one agent should think in those terms now, even if their first implementation is simple. Standardizing one protocol for tools and another for inter-agent coordination is cleaner than inventing proprietary message-passing patterns inside each application.
Just as important, governance needs to be treated as first-class infrastructure. Gartner predicts that 33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024, and that at least 15% of day-to-day work decisions will be made autonomously through agentic AI by 2028. Gartner states:
“By 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024.” — Gartner
If that forecast is even directionally right, then permissions, audit logs, approval steps, evals, and rollback mechanisms cannot be afterthoughts. They need to be standardized alongside protocols. A useful operating model is to assume every agent action may eventually require the same controls you already expect from APIs and human operators: identity, scope, traceability, and policy enforcement.
For engineering leaders, this shifts the design question from “Can the agent call this tool?” to “Under what policy, with what evidence, and with what record?” Teams that answer that early will be in a much better position than teams retrofitting governance after agents are already woven into business workflows.
Build an AI-native stack with clean boundaries: workflows, tools, memory, and UI
The teams that will move fastest in 2026 are unlikely to be the ones with the most bespoke agent code. They will be the ones that separate concerns well. In practice, that means treating workflows, tools, memory, and user interfaces as distinct layers.
Workflows define goals, state transitions, approvals, retries, and human handoffs. Tools expose capabilities through managed interfaces such as MCP. Memory stores relevant context under explicit retention and access rules. UI gives users visibility, intervention points, and trust signals. Mixing those concerns usually makes agent systems harder to reason about and harder to scale.
This is also where standardization produces compounding returns. If your tools are exposed consistently, you can swap models more easily. If your workflows are explicit, you can test and evaluate them. If your memory layer is decoupled, you can change retrieval strategies without rewriting every agent. If your UI is designed around supervision and traceability, you can ship useful automation sooner without pretending the system is fully autonomous.
There is already evidence that AI-assisted engineering can create real leverage when integrated well. In a controlled study, GitHub reported developers using Copilot completed tasks up to 55% faster. That statistic should not be overgeneralized, but it does support a broader point: workflow-integrated AI can materially improve delivery when the surrounding system is well designed.
For most organizations, the immediate priority is not building the most autonomous agent possible. It is building a reliable substrate for many AI-assisted workflows. That means standardizing connectors, permissions, evals, telemetry, and interface contracts now, before every team invents its own stack. If you want a practical reference point for this kind of platform thinking, that is a theme I return to across [engineering operations work](/projects/b1ee3e9a-f77b-4b3f-9066-acfbed12ce6c/ops), on the [ops blog](/projects/b1ee3e9a-f77b-4b3f-9066-acfbed12ce6c/ops/blog), and via updates on LinkedIn.
Conclusion
In 2026, the best engineering teams will treat agent tooling as infrastructure, not novelty. MCP is emerging as the clearest candidate for standardizing model-to-tool and model-to-data access, with support visible across Anthropic, OpenAI, and Microsoft. A2A extends that direction toward multi-agent interoperability. The teams that should standardize now are not just choosing protocols; they are choosing cleaner boundaries between tools, workflows, governance, memory, and interfaces.
If I were setting a 2026 roadmap today, I would standardize four things first: MCP-based tool access, explicit agent workflow orchestration, enterprise-grade permissions and audit trails, and evaluation infrastructure tied to real tasks. Everything else can evolve on top of that foundation. For teams building AI-native systems, that is the difference between a demo stack and an operating model.
For more writing on scalable software, frontend architecture, and AI-native engineering, see [davidenoch.me](/) and the [blog archive](/blog).