We've watched enterprise teams go from vague "we might do agent stuff" conversations to full internal agent environments in a matter of months, and the same protocol question comes up in almost every one: does the design need the Model Context Protocol (MCP) or the Agent2Agent Protocol (A2A)? MCP connects an agent to the tools and data it needs; A2A lets agents built by different teams or vendors work together. Both are real and useful. But it can be hard to know which one you actually need, or whether you need one at all. This article walks through five common agent architectures, what each one actually requires, and why the useful question is "which boundary am I crossing?" rather than "which protocol is trending?"The two protocols & what they standardizeThe Model Context Protocol (MCP) is a standardized way to connect LLMs with the context they need: internal databases, APIs, file systems. It uses a client-host-server architecture: a host app runs one client per server connection, and each server exposes tools, resources, and prompts to the model. Those exchanges travel over JSON-RPC, a remote procedure call format built on JSON. Anthropic open-sourced MCP in December 2024 and later donated it to the Agentic AI Foundation under the Linux Foundation.The Agent2Agent Protocol (A2A) covers a different boundary: agents talking to other agents across frameworks, vendors, or organizations. Each agent publishes an Agent Card, a JSON document that says who it is, what it can do, where to reach it, and how to authenticate. Work flows through tasks with defined lifecycle states: submitted, working, input-required, completed, failed. Google originally developed A2A, donated it to the Linux Foundation, and the protocol reached v1.0 in 2026.The two are designed to work together: use MCP to give an individual agent the tools it needs to do its job, and use A2A to let that agent collaborate with other agents across different frameworks. Neither one is a default requirement, though. The five scenarios below help you pressure-test your own design: find the boundary you're actually crossing, add a protocol only where it pulls its weight, and skip it everywhere else.Scenario 1: a customer support agent → MCPStart with one of the most common builds: a single agent that answers product questions, checks order status, and processes returns. What it needs is reliable, governable access to your internal systems. That's where MCP comes in: it defines a protocol-level contract between models and external systems that avoids hardcoding integration semantics into prompts or SDK-specific calls.A2A usually doesn't add much here. There's one agent, one trust domain, and no other agent to coordinate with. With MCP settled, the thing to actually watch is a side effect of how it works: MCP feeds tool definitions and results through the model's context, and those can consume 50,000+ tokens before the agent reads a request. A sprawling catalog of similar-sounding tools makes it worse: the model has to pick the right tool for each step, and the more lookalike options it sees, the more often it picks wrong. That's why a handful of well-described tools typically beats a catalog of vague ones.Scenario 2: a deterministic invoice pipeline → neitherSome workflows don't need an agent at all, because every step is known in advance. Invoice processing is the classic case: invoices come in, data gets extracted, three-way matching runs, payments go out. The simplest approach that works is usually the right one. If you can flowchart the whole process, you don't need an agent to figure it out, and you don't need an agent protocol either.The temptation is to make it agentic anyway, but that tends to backfire: when a deterministic pipeline is already accurate, adding AI can increase cost, slow the workflow, and create new accuracy risk. The one spot where an LLM genuinely helps is narrow: reading messy, unstructured input like a PDF invoice or an email and turning it into clean, structured data the pipeline can act on. That's a single model call inside otherwise-ordinary code, not an agent. It needs neither MCP nor A2A. You might reach for MCP later if one step has to connect to a specific system, like your enterprise resource planning (ERP) tool, but that's an add-on, not the backbone.Scenario 3: a multi-agent research system → MCP & maybe A2AResearch assistance is the kind of task you can't script in advance: each question opens up sub-questions you don't know about until you're in it. The orchestrator-workers pattern fits, with a central LLM breaking the task into pieces and delegating each to a specialized worker. The real payoff is in how context gets handled: each worker explores its own slice in a separate context window and reports back only what it found, so the lead agent reasons over clean summaries instead of a pile of raw search results. That isolation outperformed single-agent systems on complex research tasks.Each worker can use MCP to standardize tool access. Whether you also need A2A comes down to permission scope. If you own and control every sub-agent, plain software orchestration or MCP will carry you, and A2A adds overhead without benefit. A2A starts to earn its keep when a worker is a separately deployed service owned by another team, or carries its own distinct authentication and permission set. It's the same call you already make with internal APIs: you don't wrap every function call in a monolith in REST or GraphQL, only the ones that cross a real external boundary. By that test, most systems don't qualify. A lot of what gets called "multi-agent" today is one orchestrator calling tools in sequence, not separate agents crossing a trust boundary, and genuine cross-framework, cross-organization agent traffic is still rare in production.One cost shows up no matter which protocol you land on: multi-agent systems are harder to observe. Tracing which sub-agent or tool produced a given answer gets murkier as the call graph grows, sub-agents are less predictable than deterministic tool calls, and stitching individual traces into one end-to-end view across MCP and A2A boundaries is still largely unsolved. Plan for it before the graph gets deep.See how practitioners draw the lineA live debate on when A2A earns its keep and when MCP is enough.Scenario 4: cross-organization agent collaboration → MCP & A2ASome workflows span two organizations. Picture a procurement agent at your company that places and tracks orders, while the supplier runs its own agent to confirm stock and schedule shipments. Two agents, owned by different companies, each with its own systems and its own rules about what the other is allowed to see.This is the case that needs both protocols. Each agent uses MCP to reach its own side: yours queries your inventory and ERP, theirs queries their fulfillment systems. But the two agents also have to talk to each other, across separate trust domains with separate permissions, which is the boundary A2A was built for. Neither substitutes for the other: MCP for agent-to-tool inside each company, A2A for agent-to-agent between them.Scenario 5: an agentic retrieval assistant → MCPRetrieval is a case where the workflow can look agentic even though part of it starts as a fixed pipeline. Retrieval-augmented generation (RAG) grounds LLM responses by fetching relevant information from your own data before generating an answer, and a basic RAG pipeline is a fixed sequence: embed the query, retrieve similar chunks, pass them to the model. Agentic RAG extends this with dynamic retrieval of the most relevant information, adapts to the user's context, and generates personalized responses, which makes it a strong fit for support and research workloads where query patterns vary.MCP is the natural fit for connecting the agent to its retrieval tools and data sources. A2A enters only if retrieval is delegated to a separate, independently deployed specialist agent. For most teams, retrieval stays inside the same deployment.MCP & A2A have very different security modelsSecurity is a separate question, and it's where MCP and A2A differ most. MCP was designed to feed an agent context and tools, not to enforce who can do what. It shows in the spec: authorization is optional, with no required token lifecycle. That gap enables attacks like tool poisoning, where a malicious server slips instructions into a tool response that the model then trusts as its own. In one MCP security benchmark, attack success rates reached 100% for some attack types. The spec is catching up around OAuth 2.1, but until authorization is required by default, treat MCP as a convenience layer for connecting tools, not a security boundary.A2A takes a different approach: agent identity is managed at the HTTP transport layer, credentials are obtained out-of-band and not exposed in Agent Cards, and v1.0 added signed Agent Cards for cryptographic identity verification. So adopting MCP means owning consent flows and access controls yourself; adopting A2A means managing trust negotiation between agents whose internals stay opaque to each other.The layer neither protocol covers: state & memoryNeither MCP nor A2A governs the quality of the context your agents accumulate. That layer fails in four common failure modes regardless of protocol choice:Context poisoning: hallucinations enter the context and get repeatedly referencedContext distraction: context grows so large the model leans on history instead of reasoningContext confusion: superfluous content drags down response qualityContext clash: contradictory information in context derails reasoningManaging these failure modes takes fast, structured infrastructure for agent state, long-term memory, and caching, whatever protocol sits above it. It's also the layer with the least standardization: there's no common memory protocol that lets you plug in one agent memory system and swap it for another, so how memory is stored and retrieved is still a decision every team makes on its own. This is the layer Redis Iris is built for: a real-time context engine that sits between an agent and the data it needs, turning fragmented, fast-changing enterprise data into live context and memory the agent can use, served from Redis at sub-millisecond latency. It's what lets an agent resume an interrupted task or pick up where a returning user left off, since the protocols above it don't preserve that state.Redis also plugs into both protocols directly. The Redis MCP Server gives agentic apps a natural-language interface for managing and searching data in Redis, and the Redis Agent Memory Server provides a Representational State Transfer (REST) plus MCP memory service covering working and long-term memory. The A2A Redis store, a2a-redis, supplies a Redis task store, Redis streams (append-only event logs for durable message processing) for event logs, pub/sub channels (publish/subscribe messaging channels that broadcast events to subscribers) for messaging, and a push config store for the A2A Python SDK.The protocol debate, minus the marketingA panel of agent-infrastructure engineers on how the two protocols fit together.Whatever protocol you pick, the context layer is Redis IrisAcross all five scenarios, the pattern holds: an agent-to-tool boundary points to MCP, an agent-to-agent boundary between separate trust domains points to A2A, and a flow you can fully flowchart typically needs neither. Choose by the boundary in front of you and the security model you're prepared to operate, rather than by name recognition.But whichever way you go, none of these protocols owns your agent's state, memory, or context, and that's the layer that decides whether an agent survives production. It's what Redis Iris is built for: a context engine that keeps agent state and memory live, fast, and consistent, with MCP and A2A integrations already built in. Try Redis free to build on Iris, or talk to our team about your agent architecture.