CIS 4394 Agentic AI · Fall 2026 · Dr. Xinyu Fu
CIS 4394 Agentic AI · Fall 2026 · Dr. Xinyu Fu
MCP assumes the thing you are calling is a system: it does what it is told and returns. A2A assumes the other side has its own model, its own tools, and its own judgment — so you do not call it, you delegate to it. Announced by Google in April 2025 and contributed to the Linux Foundation that June, it is the younger and less settled of this week's two standards, and we will be honest about that.
You know the exact function, the exact arguments, and the shape of the answer. It returns in one shot or it errors. There is nothing to negotiate — and nothing that can ask you a question back.
You state an outcome, not a call. The other side may plan, use tools you cannot see, take minutes rather than milliseconds, and ask you something mid-task. That last one is why a request/response API is not enough.
A2A (Agent2Agent) is an open protocol for agents built by different teams, on different frameworks, from different vendors, to discover each other and work together over ordinary web infrastructure. Its three moving parts:
Two design commitments worth naming, because they are what makes it enterprise-shaped: it runs on plain web standards (HTTP and JSON, so your existing gateways, auth, and logging apply), and agents are treated as opaque — you expose what you can do, not how you do it. Your prompts, your model choice, and your internal tools stay yours.
Primary sources: Google's announcement (2025) ↗ · the A2A protocol site ↗.
MCP had a year of adoption before A2A was announced, and it shows. A2A moved to a neutral foundation quickly and has real vendor backing, but the open question is adoption, not design — cross-organization agent delegation requires two organizations to actually want it, plus answers to questions the protocol alone cannot settle: who is liable when a delegated task goes wrong, how you audit an agent you do not run, and what a service-level agreement means when the other side is probabilistic.
Learn it for the concepts — discovery, delegation, task lifecycle. Those survive whichever protocol wins. Be skeptical of anyone claiming the standards war is settled; in this material we would rather teach you the shape of the problem than a winner.
An Agent Card is a small JSON document an agent publishes so others can find and evaluate it — the A2A analogue of an MCP server advertising its tools. Click any highlighted field to see what it is doing and what a careful reader would ask about it.
Illustrative and simplified — a teaching example, not a spec excerpt. Field names and required properties change between protocol versions; check a2a-protocol.org ↗ for the current definition before you write one.
A campus advising agent delegates to the tutoring center's agent — a different department, a different codebase, a different owner. Press Step and watch the task move through its states. The amber state is the interesting one.
The amber state — input-required — is what a plain API call cannot express. The delegate stops and asks, and the task stays alive while it waits.
| MCP | A2A | |
|---|---|---|
| Connects | An agent to tools & data | An agent to another agent |
| Direction | Vertical — downward | Horizontal — sideways |
| Other side is | A system: deterministic, no goals | An agent: plans, may ask you questions |
| Discovery | Tool list at connect time | Agent Card, published |
| Unit of work | A tool call, usually fast | A task, possibly long-running |
| Typical use | “Read the student record” | “Get this student tutored” |
| Origin | Anthropic, Nov 2024 | Google, Apr 2025 |
The most common mistake this week is reaching for A2A when the honest answer is “these are two nodes in a graph I control.” Three options, one question that separates them: am I crossing a boundary I do not own?
A researcher node and a writer node in one LangGraph. They share state, ship together, and are versioned together. Adding a protocol here buys you serialization overhead and a second failure mode in exchange for nothing. Use edges. Week 4 →
Week 9 preview: multi-agent design — supervisors, hand-offs, and when splitting one agent into several actually helps — is a whole week of its own, and most of it happens inside a single application.
You want a system's data or actions and you would be happy with a well-described function. The other side has no goals to negotiate with. Wrap it in a server — once — and every agent you build afterwards gets it free.
The work belongs to another team, vendor, or company: they own the data, the rules, and the accountability. You want an outcome without inheriting their internals, and you may need a back-and-forth to get there. That is delegation, and that is A2A's case.
The official short introduction: Agent Cards, tasks, and discovery across vendors. Watch it with the diagram above in mind and check whether the speaker's example is really cross-organizational — or whether it would have been fine as edges in one graph. (~8 minutes; runtime approximate.)
This is a vendor introducing a standard it created, which is not a criticism — it is context. When you watch, separate three layers: the problem (agents from different builders cannot find or talk to each other), which is real and would exist without any vendor; the design (cards, tasks, opacity), which you can evaluate on its merits; and the pitch (that this particular design should be the industry's), which is a claim about the future, not a fact about the present.
Whoever's format becomes the default captures the ecosystem around it — that is the platform economics behind every standards announcement you will read this year, and why open governance under a neutral foundation is a substantive move rather than a press-release detail.
Free deep dives: Microsoft — AI Agents for Beginners ↗ · Hugging Face Agents Course ↗
Four scenarios. Pick MCP, A2A, or neither. The “neither” option is not a trick — it is the answer more often than students expect.