> I think I can safely say which one will still be around in 6 months

LangChain is still around but that doesn't mean much. MCP isn't much better.

Langchain has long solved (we can argue on if it's done it well, opinions vary) the problem of needing to orchestrate LLM calls into a coherent workflow. Plus it had a first mover advantage.

MCP solves a data and API integration problem.

Both are concrete things that people need to do today. AI agents talking to one another is not a concrete problem that organizations building features that integrate AI have today.

Langchain is one of the most hilarious libraries I've ever had the displeasure of looking through. Many of the abstractions look like they were written by a college student who took clean code way too literally. Many of the methods are so trivial and shallow that I'm shocked people use it in any serious capacity.

This. I was amazed opening something like PagagraphLineReaderFactory, thinking it somehow deals smartly with paragraph boundaries and too long paragraphs etc., and finding a trivial single line regex wrapped in two screens of OOP boilerplate.

> the problem of needing to orchestrate LLM calls into a coherent workflow.

I didn't feel the need to use Langchain, chaining LLM calls is usually just a few lines of code (I think even fewer than when using Langchain).

I am still simply doing plain fetch requests to LLMs APIs, and it works great, 10/10 would recommend.

Hi there (I work on a2a) - A2A works at a different level than MCP. 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.

While I can logically understand these problems and why A2A could solve them, unfortunately you're asking me to suspend disbelief about the actual agents being built and deployed.