I have to say, the endorsements at the end somehow made this seem worse…

MCP is solving specific problems people have in practice today. LLMs need access to data that they weren't trained on, but that's really hard because there's a millions different ways you could RAG something. So MCP defines a standard by which LLMs can call APIs through clients. (and more).

A2A solves a marketing problem that Google is chasing with technology partners.

I think I can safely say which one will still be around in 6 months, and it's not the one whose contributors all work for the same company.

The jsonrpc calls look similar-ish to mcp tool calls except the inputs and outputs look closer to the inputs/outputs from calling an LLM (ie messages, artifacts, etc.).

The JS server example that they give is interesting https://github.com/google/A2A/tree/main/samples/js/src/serve... - they're using a generator to send sse events back to the caller - a little weird to expose as the API instead of just doing what express allows you to do after setting up an sse connection (res.send / flush multiple times).

A2A is for communication between the agents. MCP is how agent communicate with its tools.

Important aspect of A2A, is that it has a notion of tasks, task rediness, and etc. E.g. you can give it a task and expect completely in few days, and get notified via webhook or polling it.

For the end users for sure A2A will cause a big confusing, and can replace a lot of current MCP usage.

MCP - exposes prompts, resources and tools to a host, who can do whatever they like

A2A - exposes capability discovery, tasks, collaboration?/chat?, user experience discussions (can we embed an image or or a website?).

High-level it makes sense to agree on these concepts. I just wonder if we really need a fully specified protocol? Can't we just have a set of best practices around API endpoints/functions? Like, imo we could just keep using Rest APIs and have a convention that an agent exposes endpoints like /capabilities, /task_status ...

I have similar thoughts around MCP. We could just have the convention to have an API endpoint called /prompts and keep using rest apis?

Not sure what I am missing.

Companies who are betting their future on LLMs realized a few years ago that the data they can legally use is the only long term difference between them, aka “moat.”

Now that everyone has more or less the same public data access, and a thin compute moat is still there, the goal is to transfer your private textual data to them forever so they have an ever updating and tuned set of models for your data

I absolutely get the value of LLMs calling tools and APIs. I still don't see much value in LLMs calling other LLMs.

Everyone gets really excited about it - "langchain" named their whole company over the idea of chaining LLMs together - but aside from a few niche applications (Deep Research style tools presumably fire off a bunch of sub-prompts to summarize content they are crawling, Claude Code uses multiple prompts executions to edit files) is it really THAT useful? Worth building an entire new protocol with a flashy name and a bunch of marketing launch partners?

LLMs are unreliable enough already without compounding their unreliability by chaining them together!

[0]: https://google.github.io/A2A/#/topics/a2a_and_mcp

https://google.github.io/A2A/#/topics/a2a_and_mcp

Basically (google claims): MCP enables agents to use resources in a standard way. A2A enables those agents to collaborate with each other.

https://digitalcommons.dartmouth.edu/dissertations/62/

A2A is an open protocol that complements Anthropic's Model Context Protocol (MCP), which provides helpful tools and context to agents.

A "server" sample: https://github.com/google/A2A/tree/main/samples/js/src/serve...

So it looks like the point is that it keeps the connection/context open for multiple interactions vs. MCP, which is more like pure request-response?

1. This is in the “embrace and extend” type area vis-a-vis MCP — if you implemented A2A for a project I don’t think you’d need to implement MCP. That said, if you have an MCP server, you could add a thin layer for A2A compliance.

2. This hits and improves on a bunch of pain points for MCP, with reasonable relatively light weight answers — it specs out how in-band and out-of-band data should get passed around, it has a sane (token based largely) approach to security for function calling, it has thought about discovery and security with a simple reliance on the DNS security layer, for instance.

3. The full UI demos imagine significantly more capable clients - ones that can at least implement Iframes - and reconnect to lost streaming connections, among other things. It’s not clear to me that there’s any UI negotiation baked into this right now, and it’s not clear to me what the vision is for non-HTML-capable clients. That said, they publish clients that are text-only in the example repo. It may be an area that isn’t fully fleshed out yet, or there may be a simple answer I didn’t see immediately.

Upshot - if you’re building an MCP server right now, great —- you should read the A2A spec for a roadmap on some things you’ll care about at some point, like auth and out of band data delivery.

If you’re thinking about building an MCP server, I’m not sure I’d move ahead on vanilla MCP - I think the A2A spec is better specified, and if for some reason A2A doesn’t take off, it will only be because MCP has added support for a couple of these key pain points — it should be relatively easy to migrate.

I think any mid-size or better tool calling LLM should be able to get A2A capability json and figure out what tool to call, btw.

One last thing - I appreciate the GOOG team here for their relatively clear documentation and explanation. The MCP site has always felt a little hard to understand.

Second last thing: notably, no openAI or Anthropic support here. Let’s hope we’re not in xkcd 927 land.

Upshot: I’d think of this as a sane superset of MCP and I will probably try it out for a project or two based on the documentation quality. Worst case, writing a shim for an exact MCP capable server is a) probably not a big deal, and b) will probably be on GitHub this week or so.

What “agents” need is not a protocol for operating, they need a protocol for discovery and addressability. How do I find someone’s agent? How do I talk to it and verify its identity? Once I’ve done that, it can just be a normal chat interface for all I care.

How much guarantee does Google's LLM/agent provide that it didn't hallucinate (read wrong info) in any of the steps including parsing job description and than matching that with profile of candidates?

I don't understand when these LLMs are presented to solve real life problems as if an LLM is like a sane person doing their job.

"Today, we’re launching a new, open protocol called Agent2Agent (A2A), with support and contributions from more than 50 technology partners"

Why do you think the majority of the big consultancy firms like McKinsey, KPMG, PwC, Deloitte, Cognizant, Capgemini and Accenture are all here in this round table?

You are on the menu when they arrive to replace you with an agent.

Exhibit A:

Hiring a software engineer can be significantly simplified with A2A collaboration. Within a unified interface like Agentspace, a user (e.g., a hiring manager) can task their agent to find candidates matching a job listing, location, and skill set.

The recruiter is now an "agent". Not a human. Don't think it isn't going to happen to you because that example targeted recruiters.

The big consultancy firms already have tens of thousands of employees and are ready to try it on them first before recommending to businesses to replace.... you.

https://github.com/enso-labs/a2a-langgraph

Hiring a software engineer can be significantly simplified with A2A collaboration

Why not abstract away the applicant altogether, outsourcing the search for talent that make these very systems tick. Let the candidate microtrading really take off, there's always a better candidate in the pipeline after all

This kind of feels to me like someone at google saw how successful MCP was becoming and said "we need something like that". I feel the same way about OpenAI's Agent SDK.

I think the word "Agent" appearing in any engineering project is a tell that it's driven by marketing rather than engineers' needs.

A2A looks like a typical enterprise, authenticated, strict DTD style spec.

Agents acting on behalf of consumers need a simple file that describes: 1) What services are provided 2) What tools are available and how to use them

Agent behavior and actions should happen in latent space. The format of any spec is almost meaningless, as long as it's self describing and conveys those 2 points.

A quick scan of the "partners" for A2A includes many of the same groups that helped launch AGNTCY. Either they jumped ship or they're teaming up with everyone. The Google announcement does read like marketing hype, though, so it remains to be seen how functional it is.

Let the inter-agent standard wars begin.

MCP actually fills a gap since people don't normally expose things like writing to their local filesystem as a callable API.

The one that will win — will be the one that gives devs the confidence to run in full “yolo/autonomous” mode. That’s the future.

So it’s actually looks like a strategic focus, rather than just announcement for interest, relevance or whatever

I read about them only for hypothetical scenarios. Is it a real thing?

If I'm reading it correctly, A2A is similar to MCP in that they both use JSONRPC but extends the capabilities for agents to be able to communicate with one another, potentially using separate backend models. MCP simply exposes applications data and workflows to a model itself and is not attempting to make agents communicate with one another.

The fact that A2A wasn't proposed as an extension to MCP seems disingenuous at best. To me, it looks like Google (among the other AI giants) is trying to create their own repository of agents, controlling the protocol, thereby enabling them to become the de-facto source for finding trusted agents.

Further, it comes off to me as a defense against the existential threat that AI poses to google's search and ads monopoly.

The problem is, as a consumer of AI, I don't want multiple agents communicating with one another. What I want is one model that communicates with non-agentic services. Making AI work well and understanding what it's doing is hard enough. You now want to pull in multiple models and companies into the picture? Talk about a risk management nightmare.

Shadow IT SaaS is already a massive problem for companies. Now imagine Shadow Agents doing work for your business using A2A to connect dozens of different unsupervised work for the company. No thanks!

For the inevitable defense of A2A "But it's open source and Apache licensed!". That's just bait. If you control the protocol, you control the ecosystem. See: Android, VSCode, Chromium, Java, Kubernetes, etc.

For me? I like my single-model audibility pulling in context using MCP. A2A just seems like an insane attempt at a land grab in the AI agent wars.

I think they are trying to ride the MCP hype as well with their own implementation that is also meh. MCP itself is also an over-engineered implementation of AI plugins by OpenAI. Obviously the end game is control over a standard which can act as a strategic tool for boosting valuations or even better product positioning.

The better approach is to simply use open standards that already exists but I guess this is just not sexy.

I'm curious to see answers, from indie builder perspective.

[1] https://livingsystems.substack.com/p/the-future-of-data-less...

[2] https://livingsystems.substack.com/p/will-data-served-as-lan...

Agents can just be viewed as tools, and vice versa. Is this an attempt to save the launch after getting scooped by MCP?

OK, I'm being a little bit facetious. But there has been an awful lot of work in this space (or closely related space). Going back to FIPA[1], KQML[2], DAML+OIL[3], etc., up through the more recent AGNTCY[4] and Agent Communication Protocol[5] stuff, there's a lot "out there".

[1]: http://www.fipa.org/

[2]: https://en.wikipedia.org/wiki/Knowledge_Query_and_Manipulati...

[3]: https://www.w3.org/TR/daml+oil-reference/

[4]: https://github.com/agntcy

[5]: https://github.com/orgs/i-am-bee/discussions/284

Hiring a software engineer can be significantly simplified with A2A collaboration.

Holy shit.. NO!

(I know, they still get billions in revenue, but maybe that's their curse, too comfy to take it seriously)