Before you build an AI agent, decide on a protocol, not a framework

Most guides on building an AI agent start with a tool question: n8n, Copilot Studio, or a Python framework. That's the wrong first decision. The question that decides how expensive a later change becomes isn't the tool. It's the protocol the agent uses to talk to tools and to other agents.

MCP decides which tools the agent can even see

The Model Context Protocol, MCP, standardises how an agent accesses data and tools. Without that standard, every team builds its own integration to every system the agent needs to talk to, and each of those integrations breaks separately the moment the underlying system changes. With a dedicated MCP server per system, for SAP master data or an internal ticketing system, you build that integration once, and every agent you build afterwards can reuse it. That decision gets made at the start of the project, not retrofitted later, because the tool layer otherwise turns into a patchwork nobody can account for.

A2A decides whether agents can actually work together

A single agent handling a task end to end hits limits quickly. A split is usually more useful: one agent checks an incoming order, a second reconciles it against SAP master data, a third escalates discrepancies to a person. The Agent2Agent protocol, A2A, governs how these agents hand off tasks without each handoff needing its own bespoke interface. Without A2A, the same split usually ends up as tightly wired code that has to be rewritten every time the workflow logic changes.

Why the model choice is secondary

An agent built directly against a single model provider's API ties the whole system to that provider's pricing and availability decisions. Building instead on Microsoft's Agent Framework with MCP and A2A as the protocol layer lets you orchestrate across multiple models, Claude for text understanding, GPT for code generation, Gemini for a specific multimodal case, without the rest of the architecture caring which one you're calling. Which model gives the best answer today will change. Which protocol connects your tools and agents shouldn't have to.

Where this meets the governance question

An agent that hands off tasks and makes decisions on its own moves toward the automation-agent category described in our post on agent taxonomy, and with it toward Annex III territory under the EU AI Act. That classification needs to be settled before the agent reaches production, not after. An AI Discovery Sprint scores which agent idea justifies the effort and how it should be classified. The AI Use-Case Build implements the architecture on MCP and A2A once that decision is made.