But MCP doesn't claim to address agent to agent communication, right?

It's not so much about what you _can do_ but about the messaging and posturing, which is what drives the adoption of standards as a social phenomenon.

My team's been working on implementing MCP-agents and agents-as-tools and we consistently saw confusion from everyone we were selling this into (who were already bought in to hosting an MCP server for their API or SDK) for their agents because "that's not what it's for".

Kinda weird, but kinda simple.

Creating new standards is not easy, largely because everyone has to agree that they will use this particular one. Plastering it with endorsements attempts to show that there is consensus and give confidence in adoption. If they didn't put them in, you'd instead say nobody is using or going to use this.

you know how the endorsements work right? some comms intern writes a quote, emails it to someone at the other companies for the go ahead/approval, and that's how you get dozens of companies all spouting BS that kinda sounds the same.

True, but look at those "partners"; most of them are lame BigCo/consultancy types with no history of technological innovation or collaboration, in fact generally anti.

The list is aimed at bureaucratic manager types (which may be the correct approach if they are generally the decision makers), its not a list that will impress engineers too much I think.

Hi there (I work on a2a) - reposting from above.

We are working with partners on very specific customer problems. Customers are building individual agents in different frameworks OR are purchasing agents from multiple vendors. Those agents are isolated and do not share tools, or memory, or context.

For example, most companies have an internal directory and internal private APIs and tools. They can build an agent to help complete internal tasks. However, they also may purchase an "HR Agent" or "Travel Assistant Agent" or "Tax Preparation Agent" or "Facilities Control Agent". These agents aren't sharing their private APIs and data with each other.

It's also difficult to model these agents as structured tools. For example, a "Tax Preparation Agent" may need to evaluate many different options and ask for specific different documents and information based on an individual users needs. Modeling this as 100s of tools isn't practical. That's where we see A2A helping. Talk to an agent as an agent.

This lets a user talk to only their company agent and then have that agent work with the HR Agent or Travel Booking Agent to complete complex tasks when they cannot be modeled as tools.