Choosing Your Protocol
Part of the free Generative AI course on LogicWiz, module: Nova Joins the Network.
Episode 38: Choosing Your Protocol
Nova could now reach any tool and delegate to any agent. Arjun's last lesson wasn't a new API. It was a question: "For this job — which one?"
The Architect's Question
You've built Nova's whole reach: MCP to touch tools and data, A2A to hand tasks to other agents, and gateways to govern both at scale. The engineering is done. What's left is judgment — the thing interviewers actually probe: given a job, which protocol do you reach for?
It's not a yes/no with a right answer. It's a design decision driven by the shape of the work.
The Decision Rule
Here's the rule in one line, and a way to feel it. Tap through some real jobs:
{{visual:protocol-chooser}}
The pattern underneath:
- Reach for MCP when the job is a single capability — fetch a value, run a query, take one deterministic action. "Get the registered address." "Update the order." Wrapping that in a whole agent is over-engineering.
- Reach for A2A when the job is a multi-step, reasoning-driven task — combine several tools and judge the results. "Verify this company." "Plan this trip." That's an agent's work, so delegate to an agent.
📌 One sentence to keep: MCP = low complexity (single tool / data access). A2A = high complexity (reasoning + multiple tools). Match the protocol to the complexity of the task, and you'll rarely be wrong.
Determinism is the tell. Highly deterministic outcome (a database update)? MCP. Fuzzy, "macro" decision that needs reasoning? A2A.
The Cost of Reusing an Agent
There's a trap on the A2A side worth naming. Calling a full agent is expensive — more compute, more architecture, and if another team owns that agent, maybe a real bill per call. Reusing a whole agent when you need only a slice of its logic is waste: you might trigger five reasoning steps to get the value of two.
So there's a third option between "simple tool" and "full agent": selective logic repurposing. If you need a specific piece of an agent's capability but not its whole reasoning workflow, extract that logic and expose it as a standalone MCP tool — the function without the overhead. Or, if it still needs some reasoning, bundle just that into a smaller, focused agent.
💡 The design drivers, whenever you choose: cost, reusability, and latency. Will this be reused by other teams? Expose it as an agent. Is it a hot path where milliseconds matter? Lean toward a direct tool. Is it a one-off? Don't build an agent for it.
A Family of Gateways
Zoom all the way out. As agent systems scale, every communication layer grows its own control plane — not just MCP. Modern AI infrastructure is converging on four gateways:
{{visual:four-gateways}}
The MCP gateway you built in Episode 36 is one member of a family: an LLM gateway governs model access, an A2A gateway governs agent-to-agent traffic, and an inference gateway governs where models actually run. Same idea each time — a central place for routing, auth, monitoring, and resilience — applied to a different kind of traffic.
Why Companies Bet on A2A
A2A is younger and less adopted than MCP — many jobs are still fine as plain API calls. So why the momentum? Two strategic reasons the PDF is blunt about:
- Monetization. Exposing a capability as an agent (rather than a raw API) lets a company charge for the agentic capability directly — a cleaner product than open API access. A travel platform can sell "a flight-booking agent," not just an endpoint.
- A training ground. An A2A agent receives natural-language requests from the outside world, not rigid API calls. That stream of real, messy queries is gold — a feedback loop for improving the underlying agent. Every third-party call teaches the platform how people actually ask.
On maturity: MCP sits higher on the adoption curve today; A2A is still climbing. In interviews, expect deep technical questions on MCP (executors, list_tools, transports) but more conceptual questions on A2A — the "why", the agent card, discovery. Knowing when each applies is the senior signal.
Try It: Let Nova Choose
Put the whole chapter to work. Give a model the decision rule and a task, and let it classify — MCP or A2A — with a reason:
{{cell:l38-classify}}
What Nova Learned
Nova began this chapter as a brilliant, frozen book — unable to name last week's ticket. She ends it able to reach any tool through MCP, delegate any task through A2A, and scale both behind gateways — choosing, each time, the lightest protocol the job allows.
That's the real lesson of agent communication protocols: not a single API, but the judgment to connect an agent to the world without drowning it in wires. Nova can finally talk to everything. And she knows when to keep it simple.