Seems like over engineering just build an API in front of your agent, give the other agent the spec in a markdown file.
why dropbox when you can just rsync
I'm a fan of that phrasing usually but that's not a good comparison in this case I feel. Agents are perfectly fine to use existing REST APIs. I have yet to see the big selling point for MCP as they are usually a very thin layer on top of an existing API just with a formalized description for each tool.
How is it better than just a REST API with a openapi spec json file?
I know our sales/business team is pitching it quite a bit (instead of our current end-to-end solution we provide), but no one has quite been able to define the boundaries of how that interacts when we don't own the full solution. Curious how others have been using it. Definitely seems designed for more of an internal or B2B use case where agents have super well defined behavior but are ultimately behind some other system entirely.
I'm a fan of that phrasing usually but that's not a good comparison in this case I feel. Agents are perfectly fine to use existing REST APIs. I have yet to see the big selling point for MCP as they are usually a very thin layer on top of an existing API just with a formalized description for each tool. How is it better than just a REST API with a openapi spec json file?
you can also put that REST API behind a self-documenting CLI. that’s how I setup my agents to talk to each other
AI infrastructure/tools developer here (www.hic-ai.com). I considered the A2A protocol carefully, but I decided a while ago that, from my perspective, the A2A protocol was not solving the correct problem. There is no distinction (from the perspective of an agent) between a communication from Agent A to Agent B, on the one hand, and a communication from Agent A to "future Agent A", on the other. In fact, agents have no inherent sense of identity at all, so there is no inherent notion of a unique Agent A. The notions like "Agent A" received a message or that "Agent A" is sending a message to a different agent (or to its future self) are all inextricably intertwined with the idea of an agentic identity existing and being well defined in the first place, which it is not. The A2A protocol assumes the existence of such a well-defined agent identity in its presumption that agent cards point to a specific agent that can be discovered and deployed. I also think gRPC adds a significant layer of indirection and obfuscation, plus it's painful to implement. The lack of widespread adoption suggests that A2A is not really solving a real-world problem, compared to MCP, for instance.
Ya, we tried it a bit, but have stayed with agent-behind-MCP style patterns for now. I think A2A or something like it will become a big thing as everything matures. It just felt over complicated for our use case. One misconception I had was we would just slap A2A on our existing agents and they’d work well together. Kind of dumb in hindsight.
I am using A2A at work. It's a bit like the "microservices architecture" for agents... Allows you or teams to develop agents independently and have them interact as and when they need to. No major hurdles so far.
This was my assumption. Agents will supersede services. There will be many companies way ahead of the curve and the rest of the industry will take 5-10 years to catch up.
Why would an agent supersede a service for a well-defined workflow contract that does not require an agentic loop? I assume both will need to exist.