LangChain, LangGraph, ADK, A2A, CrewAI, and Agno: how I choose between them

Before any comparison, a distinction that is often ignored and that avoids much of the confusion in this market:

• LangChain, LangGraph, ADK, CrewAI, and Agno help build agents.
• A2A does not build any agent. It is a protocol for independent agents to communicate with each other.
• LangChain and LangGraph do not compete. LangChain delivers components and abstractions (models, tools, RAG). LangGraph controls execution, state, and workflow. I use both together in most of my corporate projects.

Executive Summary

If I had to summarize my decision rule in one sentence per tool:

LangGraph with LangChain for corporate systems that cannot fail. ADK when the client already lives within Google Cloud. CrewAI when the value is in autonomous collaboration between roles. Agno when the goal is to go from zero to a proprietary platform as quickly as possible. A2A when two agents need to communicate without living in the same process.

1.LangChain

LangChain is a high-level SDK for assembling applications with LLMs. It standardizes models from different providers, tool calling, prompts, and messages, middleware, RAG, retrievers, vector stores, and structured output.

A point that often goes unnoticed: in the current architecture, LangChain's create_agent functions as an agent harness (model, tools, instructions, and middleware mounted over LangGraph). This means that even when using only LangChain, you are indirectly relying on LangGraph's persistence and human-in-the-loop under the hood ([Docs by LangChain][1]).

I use LangChain when the agent cycle is relatively simple: corporate chatbots, RAG over documents, SQL agents, assistants with tools, integration with various model providers, proof of concept.

User
   ↓
FastAPI API
   ↓
LangChain Agent
   ├── Model
   ├── Retriever
   ├── Internal API
   └── SQL Tool

A mistake I see frequently in teams that are starting out: leaving the agent to access dozens of tables directly or execute critical business rules without going through a domain layer. I treat LangChain as an integration and composition layer, never as a substitute for application architecture. The agent's tools should call well-defined services, not the raw database:

Agent
 ├── get_customer()
 ├── get_policy()
 ├── get_transaction()
 └── open_request()

Infrastructure

For simple applications, my standard stack is FastAPI or Node.js, Docker, Cloud Run, ECS Fargate, Azure Container Apps, or Railway, PostgreSQL, pgvector or Qdrant, Redis when it makes sense, and LangSmith or OpenTelemetry for observability.

In medium scale, the design becomes:

Load Balancer
      ↓
FastAPI replicas
      ↓
LangChain Agents
 ├── PostgreSQL
 ├── Redis
 ├── Vector DB
 └── Internal APIs

I don't use LangChain alone when the workflow has many steps, lasts minutes or hours, requires human approval, retry by step, compensation, resumption after failure, complex state, or complete auditing. At this point, LangGraph enters.

2.LangGraph

LangGraph is my preferred framework for stateful workflows and agents built as a graph: state, nodes, edges, conditions, loops, subgraphs, checkpoints, interruptions, and resumption of execution are explicit in the code, not hidden inside an autonomous agent.

It combines deterministic steps with LLM-controlled steps and delivers persistence, durable execution, streaming, and human-in-the-loop natively ([Docs by LangChain][2]).

START
  ↓
Validate request
  ↓
Fetch data
  ↓
Analyst agent
  ↓
Enough confidence?
  ├── Yes → Execute next step
  └── No → Human review
                 ↓
               Resume
                 ↓
                END

It is my standard recommendation for anti-fraud, credit, compliance, recruitment with steps and approvals, customer service with human escalation, investigations, document processing, and any regulated process that needs to survive a restart or failure.

The state needs to be typed and contain only what matters:

class RiskState(TypedDict):
    transaction_id: str
    rule_score: float
    ai_score: float | None
    evidence: list[str]
    decision: str | None
    human_review: bool

The practice I demand from any team I work with: make explicit where AI can suggest, where it can choose a path, and where deterministic rules prevail without exception.

Infrastructure

API Gateway
      ↓
Agent Server / LangGraph
      ↓
PostgreSQL Checkpointer
      ↓
Redis / queue
      ↓
Workers

Kubernetes, ECS, or VMs in containers, PostgreSQL for checkpoints and threads, Redis for queue and coordination, Kafka or SQS or Pub/Sub for domain events, object storage for documents, Qdrant or pgvector for RAG, OpenTelemetry and LangSmith for tracing.

It's worth noting: the LangSmith Deployment documentation recommends Kubernetes for standalone production and explicitly warns that long-running LangGraph execution servers should not depend on serverless environments with scale-to-zero, as this can interrupt ongoing tasks and compromise resumption ([Docs by LangChain][3]). I've seen this infrastructure decision made incorrectly for cost savings and turn into a production incident.

LangGraph's strong point is explicit execution control. The weak point is that it requires more engineering: state modeling, error handling, idempotence, checkpointing, graph versioning, state migration, retry strategy. It doesn't hide the complexity of your system. It gives you the tools to control it, which is different from pretending it doesn't exist.

3.Google ADK

The Agent Development Kit is Google's open-source framework for production agents, with support for Python, TypeScript, Go, Java, and Kotlin. It brings together agents, tools, graph workflows, multi-agent systems, sessions, memory, artifacts, evaluation, and deployment in one package ([Google GitHub][4]).

A detail that often surprises those who assume ADK is "just for Gemini": the framework offers support or adapters for other models, including Claude, Ollama, vLLM, and LiteLLM. The strongest operational integration remains within the Google Cloud ecosystem, but model dependency is not absolute ([Google GitHub][4]).

I recommend ADK when the company is already on Google Cloud, Gemini or Vertex AI are the main models, there is a polyglot team, the project will use Cloud Run, GKE, or Agent Runtime, and it's necessary to integrate A2A and MCP natively.

Application
   ↓
ADK Agent
   ├── Tools
   ├── Agent Team
   ├── Graph Workflow
   ├── Session Service
   ├── Memory Service
   ├── MCP
   └── A2A

ADK separates four concepts that I consider fundamental for any agent architecture, regardless of the framework: session is the current conversation, state is the temporary data of that session, memory is the knowledge searchable between sessions, and events are the history of messages and actions. In-memory implementations serve for development; in production, they need to become persistent storage or managed services ([Google GitHub][5]).

Infrastructure

The Agent Runtime is Google Cloud's managed service specifically designed for agent execution and scalability, with autoscaling, managed session, agent identity, and integrated observability ([Google GitHub][6]). It makes sense when the project is fully Google Cloud and you want the least operational effort possible.

Cloud Run is my choice for simple APIs, stateless agents, or those with external state, variable load, short executions, MVPs, and webhooks.

GKE enters when the agent is long-running, uses an open-source model, needs vLLM or GPU, service mesh, complex private network, or high customization.

Between LangGraph and ADK, my rule is straightforward: I choose LangGraph when the application needs to be cloud-agnostic, the graph and state are the system's core, the team is Python or TypeScript, and there's a strong need for custom control. I choose ADK when Google Cloud is already the client's strategic platform, there's a distributed team in Go, Java, Kotlin, Python, and TypeScript, and Agent Runtime, Vertex AI, and IAM are already part of the conversation.

4.A2A

A2A stands for Agent2Agent Protocol. It's not a framework; it's an open protocol for communication between independent agents, even if built with different frameworks and languages.

It defines Agent Card, skills, and capabilities, messages, tasks, task states, context ID, streaming, authentication, and file and structured data exchange, allowing agents to collaborate without exposing internal memory, tools, or proprietary logic ([A2A Protocol][7]).

The analogy I use in class:

MCP:
Agent → tool, API, database, or resource

A2A:
Agent → another agent

They are complementary, not competing ([A2A Protocol][8]).

I use A2A when there's a real boundary: agents from different departments, companies, hosted on different clouds, built with different frameworks, or a corporate agent consuming a supplier's agent.

Customer Service Agent
          ↓ A2A
Financial Agent
          ↓ A2A
Anti-fraud Agent
          ↓ A2A
Compliance Agent

Nothing prevents the anti-fraud from being LangGraph, finance being ADK, and customer service being Agno. A2A is the communication contract between them, not the implementation of any.

What I don't do: use A2A for communication between sub-agents that live in the same process, workflow, repository, transaction, or have direct access to the same state. In this case, the native primitives of LangGraph, ADK, CrewAI, or Agno resolve with much less overhead.

Infrastructure

API Gateway
      ↓
A2A Client
      ↓
A2A Server
      ├── Agent Card
      ├── Task Store
      ├── Streaming
      ├── Authentication
      └── Agent Runtime

I treat A2A as a distributed services architecture: one service per agent or domain, Kubernetes, ECS, Cloud Run, or Agent Runtime, API Gateway, OAuth2/OIDC, mTLS in sensitive communication, service mesh in Kubernetes, PostgreSQL for task states, Kafka or Pub/Sub or SQS for domain event processing, SSE or webhook for updates, OpenTelemetry with correlation ID and task ID, rate limiting, circuit breaker, and idempotency key.

A2A does not solve deployment, database, queue, or observability. It standardizes only communication. Everything else remains normal engineering work.

5.CrewAI

CrewAI orchestrates multi-agents around two concepts: crews, which are groups of specialized agents, and flows, which are structured workflows controlling state, event, branch, and execution. A crew can have researcher, analyst, reviewer, and writer; the flow decides when this team is called and what happens with its