LangGraph vs Google ADK en 2026: Orquestación explícita o composición de agentes

Cualquiera que hoy en día desarrolle un agente de producción se encuentra en el mismo campo saturado: LangGraph, Google ADK, el OpenAI Agents SDK, PydanticAI, CrewAI, AutoGen, LlamaIndex y probablemente otro framework que haya aparecido mientras se escribía esta lista. La pregunta instintiva es cuál es el mejor, pero esa es la forma incorrecta de empezar. Una pregunta mejor es dónde debe residir la opinión del framework y dónde debe mantenerse el control en la aplicación.

Planteada de esta manera, la comparación entre LangGraph y el Kit de Desarrollo de Agentes de Google (ADK) resulta más interesante en 2026 de lo que sugiere el antiguo eslogan de “gráficos versus agentes”. Ambos pueden generar agentes sofisticados. Lo que los diferencia es dónde reside el control, qué opciones predeterminadas vienen incluidas y cuánta complejidad de orquestación asume el equipo.

Los dos frameworks están convergiendo

Las comparaciones anteriores trazan una línea clara: LangGraph es una herramienta de orquestación de grafos de nivel bajo, mientras que ADK es un marco multiagente de nivel más alto. Eso sigue siendo cierto en parte, pero deja de lado muchos aspectos importantes.

LangGraph está organizado en torno a nodos explícitos, estado, transiciones, persistencia, reintentos y un control detallado de la ejecución. Su diseño se basa en gran medida en una ejecución duradera, flujos con intervención humana, gestión de estado y una orquestación bien definida.

ADK ahora también abarca varios estilos de orquestación:

• flujos de trabajo basados en grafos
• flujos de trabajo dinámicos
• flujos de trabajo colaborativos multiagente
• nodos de ejecución deterministas
• delegación impulsada por agentes

En ADK 2.x, un grafo puede combinar agentes de LLM, funciones simples, herramientas, lógica de enrutamiento, estado e ingreso humano. Por lo tanto, ya no se trata de elegir entre un grafo o agentes, ya que cada framework puede hacer ambas cosas. Lo que difiere es la forma en que se construye el sistema.

Cómo piensa LangGraph

LangGraph se percibe primero como un motor de orquestación. El diseño comienza con una serie de preguntas: ¿Cuál es el estado? ¿Qué lo cambia? ¿A dónde puede dirigirse la ejecución a continuación? En forma gráfica, el flujo se ve así:

State
  ↓
Node
  ↓
Decision
 ↙   ↘
A     B
↓     ↓
Tool  Agent
 \     /
  ↓   ↓
 Validation
     ↓
    End

El gráfico aquí va más allá de la gestión de tuberías. Se convierte en parte de la arquitectura, lo cual resulta beneficioso cuando el sistema contiene una lógica de negocio determinística importante. Un flujo de trabajo puede necesitar:

• pausarse y esperar a que una persona apruebe algo
• reintentar una operación que falló
• recuperarse después de que una herramienta se dañe
• reanudarse a partir de un estado persistido
• dividirse en ramas según datos estructurados
• ejecutar código ordinario entre llamadas al modelo
• mantener el estado a lo largo de tareas de larga duración

LangGraph hace que cada uno de estos aspectos sea explícito, lo cual constituye un modelo sólido. El costo es que el equipo debe asumir una mayor responsabilidad en el diseño de la orquestación.

Cómo piensa ADK

ADK se siente más cercano a un marco de trabajo para aplicaciones de agentes. En lugar de partir de una máquina de estados, el diseño puede comenzar con agentes:

Coordinator
├── Specialist Agent
├── Specialist Agent
├── Specialist Agent
└── Specialist Agent

Cada agente puede llevar consigo sus propias instrucciones, herramientas, responsabilidades, límites, subagentes y configuraciones del modelo. El marco luego ofrece varias vías de coordinación. Un sistema bastante autónomo puede permitir que un coordinador transfiera el trabajo a especialistas. Un proceso predecible puede utilizar orquestación de grafos. Las tareas que son más fáciles de expresar en código pueden emplear flujos de trabajo dinámicos.

Lo atractivo del ADK moderno es que proporciona abstracciones de agentes con criterios definidos sin insistir en que cada paso sea dirigido por un LLM. Cuando la fiabilidad lo exige, la ejecución puede reducirse a código determinista.

La pregunta central: ¿quién controla el flujo de trabajo?

Probablemente esto sea lo primero que hay que decidir al elegir entre los dos. Imagine dos extremos.

En su mayor parte determinista

El proceso ya se conoce, paso a paso:

Receive request
→ validate
→ retrieve information
→ classify
→ call service
→ validate result
→ human approval if necessary
→ respond

El modelo agrega inteligencia dentro del proceso, mientras que la aplicación es quien controla el proceso en sí. Eso coincide con la forma en que LangGraph impulsa a los desarrolladores a pensar, y los flujos de trabajo basados en grafos de ADK ahora pueden modelar el mismo estilo.

Principalmente impulsado por agentes

Aquí el objetivo es conocido, pero no el orden de los pasos:

User goal
   ↓
Coordinator
   ↓
Which specialist is needed?
   ↓
Delegate
   ↓
Maybe call another specialist
   ↓
Synthesize

En este caso, la coordinación es en parte semántica, y el modelo colaborativo de múltiples agentes de ADK se adapta a ella de manera natural. LangGraph también puede implementar este patrón sin duda alguna. La capacidad no está en cuestión; lo importante es qué abstracción se alinea mejor con la arquitectura ya deseada.

La ventaja de LangGraph: estado explícito

El estado parece algo aburrido hasta que un agente entra en producción, momento en el que se convierte en una de las partes más importantes del sistema. Los operadores necesitan respuestas a preguntas como estas:

What has already happened?What did the previous agent produce?Which tools were executed?What has been validated?What still needs approval?Where should execution resume?What should the next node actually see?

LangGraph mantiene el estado compartido en el corazón de su modelo de programación, por lo que las transiciones son visibles. También fomenta una disciplina útil: mantener un estado estructurado en lugar de meterlo todo en un prompt gigantesco adicional. El estado de la aplicación y el contexto del modelo no deberían ser lo mismo automáticamente, y esa brecha se amplía a medida que crecen los sistemas de agentes.

La fortaleza de ADK: componer agentes

La mejor abstracción de ADK es la facilidad con la que los agentes especializados se convierten en bloques de construcción. En lugar de un único agente enorme con un prompt de sistema enorme, las responsabilidades se separan:

                Coordinator
                      │
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
    Research       Domain        Action
     Agent          Agent         Agent
        │             │             │
        └─────────────┼─────────────┘
                      ↓
                  Validation

Eso es importante porque el diseño multiagente no debería significar crear más agentes. Debería significar establecer límites significativos. Un especialista merece existir cuando aislar su contexto, herramientas, permisos, responsabilidades, modelo o criterios de evaluación genera una arquitectura mejor. Sin eso, otro agente no es más que otra llamada a un modelo con un nombre ingenioso.

Más agentes no significan un sistema mejor

Un error muy común es asumir esta lógica aritmética:

1 agent = simple
5 agents = sophisticated
20 agents = extremely sophisticated

No funciona de esa manera. Cada agente adicional puede generar otra llamada al modelo, otro prompt, otro contexto, otra transferencia de tarea, otra forma de fallar, otro límite de evaluación, más latencia, más tokens y más tareas de depuración.

Antes de agregar uno, pregúntese qué capacidad mejora de manera significativa, ya que esa responsabilidad queda aislada. Las razones sólidas incluyen un conjunto de herramientas distinto, permisos de seguridad más estrictos, un contexto separado, un modelo diferente, una evaluación independiente, una especialización que merezca ser reutilizada o tareas que puedan ejecutarse en paralelo. “La arquitectura multiagente suena mejor” no debe formar parte de esa lista.

Conclusión

El enfoque más útil no es el de gráficos frente a agentes, sino el de orquestación explícita frente a composición centrada en agentes. LangGraph parte del flujo de trabajo, su estado y los controles asociados. ADK comienza con agentes que utilizan herramientas y cooperan entre sí, y va añadiendo gradualmente características explícitas de flujo de trabajo. Las siguientes cuestiones, una vez que cualquiera de estos sistemas llegue a la fase de producción, se refieren a la ingeniería de contexto, los contratos, la ejecución con intervención humana, la observabilidad y la evaluación.