Diseño de subagentes en la nube: Agno vs LangChain vs AI SDK

La mayoría de los equipos no necesitan «sistemas multiagente» en abstracto.

Necesitan algo mucho más específico:

• un agente que investigue
• otro que escriba o implemente
• un tercero que revise, apruebe o dirija el resultado

Esa es la verdadera cuestión al hablar de subagentes.

No «¿puede el framework crear agentes auxiliares?».

Sino:

• ¿cómo comparten contexto esos agentes auxiliares?
• ¿dónde vive el estado entre pasos?
• ¿cómo los ejecutas en la nube sin que todo el sistema se convierta en un caos de orquestación?

Para este artículo revisé la documentación oficial de Vercel AI SDK, LangChain/LangGraph, Agno y AgentOS el March 30, 2026. El objetivo no es elegir un ganador en abstracto, sino ayudar a ingenieros y PMs a elegir el diseño de subagentes adecuado para sistemas reales alojados en la nube.

TL;DR

• AI SDK es la opción más clara cuando quieres subagentes controlados por la aplicación dentro de un producto TypeScript. Sus subagentes suelen invocarse como herramientas, se ejecutan en un contexto aislado y pueden devolver un resumen condensado al agente principal. Esto funciona muy bien para aplicaciones web y despliegues en la nube al estilo de Vercel, pero tú eres responsable de la persistencia y de gestionar la orquestación con disciplina.
• LangChain/LangGraph es la opción más sólida cuando los subagentes necesitan ejecución duradera, checkpoints, estado de hilo y capacidad de reanudación. Si el workflow puede pausarse, reintentarse o continuar durante tareas prolongadas en la nube, LangGraph es la arquitectura más natural. La contrapartida es una mayor complejidad de orquestación.
• Agno + AgentOS es la opción más completa cuando quieres equipos de agentes y workflows expuestos como APIs de producción, con sesiones, trazas, visibilidad desde un plano de control y programación de tareas ya contempladas. Es especialmente útil para plataformas internas centradas en Python y servicios multiagente autoalojados.
• Para la mayoría de los equipos de producto, la elección del framework depende de dónde debe vivir el «cerebro»:
  • AI SDK: en la capa de tu aplicación
  • LangChain/LangGraph: en el grafo del workflow y el runtime de los hilos
  • Agno/AgentOS: en un runtime de agentes dedicado y su plano de control

Qué aprenderás aquí

• Cómo modelan realmente los subagentes AI SDK, LangChain y Agno.
• Qué framework se adapta mejor a cada uno de tres escenarios comunes en la nube.
• Cómo abordar el contexto, los reintentos y las responsabilidades cuando los subagentes se ejecutan en producción.
• Patrones prácticos de código para que un agente principal delegue tareas a especialistas.
• Un marco de decisión que puedes usar con ingenieros y PMs cuando un equipo dice: «probablemente necesitamos varios agentes».

Revisión de fuentes: qué respalda claramente la documentación oficial

Esta es la interpretación más clara de las fuentes primarias.

1. AI SDK trata los subagentes como herramientas de delegación explícitas

La documentación de subagentes de AI SDK es muy directa:

• un agente principal invoca a un subagente mediante una herramienta
• el subagente se ejecuta con su propia ventana de contexto
• puedes decidir qué ve realmente el modelo principal al definir la salida devuelta con toModelOutput

Ese último punto es el más importante.

El diseño de subagentes de AI SDK no se limita a descomponer tareas. También se trata de comprimir el contexto.

El usuario puede seguir viendo la ejecución completa del subagente en la interfaz, mientras que el modelo principal recibe solo un resumen conciso. Esto encaja muy bien con aplicaciones de producto donde quieres ofrecer trazas de ejecución detalladas al usuario o al desarrollador, pero no quieres saturar al orquestador principal con cada token intermedio.

Mi conclusión: AI SDK te da el control más explícito sobre los límites de los subagentes en la capa de aplicación, pero espera que tú establezcas las prácticas necesarias para producción.

2. LangChain/LangGraph trata los subagentes como nodos con contexto diseñado dentro de un workflow duradero

La documentación multiagente de LangChain destaca que la ingeniería de contexto es el problema central de diseño. La documentación plantea explícitamente los patrones multiagente en torno a estas decisiones:

• qué partes de la conversación ve cada agente
• qué herramientas recibe cada agente
• cómo se incluyen u omiten las salidas de los agentes en el siguiente paso

LangGraph va más allá al ofrecer persistencia de hilos, checkpoints y ejecución duradera. Esto importa porque los workflows prolongados en la nube rara vez terminan en un solo intento ininterrumpido. Se pausan, se reintentan, se reanudan y, a veces, esperan la aprobación de una persona o eventos externos.

Los patrones de subgrafos y grafos remotos son especialmente importantes aquí. La documentación muestra que puedes aislar el estado dentro de subgrafos e invocar grafos desplegados de forma remota. Eso se acerca mucho más a una arquitectura real en la nube que una simple «llamada a una función auxiliar» dentro del mismo proceso.

Mi conclusión: LangChain/LangGraph es más sólido cuando los subagentes forman parte de un grafo de ejecución duradera, no solo de una abstracción práctica.

3. Agno trata los equipos y workflows como servicios de producción de primer nivel

La documentación de Agno adopta un enfoque más centrado en el runtime.

En lugar de preguntar solo cómo un agente llama a otro, Agno modela:

• equipos de agentes
• workflows con pasos estructurados
• AgentOS como runtime, plano de control y superficie operativa

La documentación indica explícitamente que AgentOS admite agentes, equipos, workflows, aprobaciones, trazas, seguimiento de sesiones, memorias y programación de tareas. El plano de control también permite ver la delegación, lo cual importa en sistemas reales en la nube porque el problema a menudo no es «¿respondió el modelo?», sino «¿qué hizo cada agente, cuándo lo hizo y por qué se detuvo?».

Agno también admite patrones de ejecución remota, incluidos equipos y workflows remotos. Esto lleva el diseño de la «orquestación con una biblioteca local» a un «runtime multiagente que puede ofrecerse como servicio».

Mi conclusión: Agno/AgentOS es más sólido cuando quieres que los subagentes formen parte de una plataforma operativa, no solo de una ruta de aplicación.

Primero, el modelo mental práctico

Cuando la gente habla de «subagentes», suele referirse a una de tres cosas muy diferentes.

1. Delegación dentro de una solicitud

Un agente principal delega una subtarea acotada dentro de un único ciclo de solicitud y respuesta.

Ejemplos:

• resumir cinco documentos antes de escribir la respuesta final
• pedirle a un especialista en búsqueda de código que localice archivos relevantes
• usar un agente revisor para evaluar un borrador generado antes de devolverlo

Aquí es donde AI SDK resulta más natural.

2. Delegación en un workflow duradero

Una tarea abarca varios pasos, dura más que una sola solicitud y puede necesitar reintentos, checkpoints o revisión humana.

Ejemplos:

• un workflow de cumplimiento que investiga, redacta, valida y espera aprobación
• una automatización en la nube que se reanuda después de que un servicio externo se recupera
• un pipeline de investigación que distribuye el trabajo y luego reúne los resultados

Aquí es donde LangChain/LangGraph suele encajar mejor.

3. Equipos de agentes a nivel de plataforma

No estás creando solo una función de producto. Estás creando un servicio multiagente reutilizable con sesiones, trazas, visibilidad administrativa y programación de tareas.

Ejemplos:

• una plataforma interna de operaciones con varios equipos de agentes
• una fábrica de contenido o investigación con workflows programados diariamente
• un backend Python que ofrece varios endpoints de agentes a otros servicios

Aquí es donde Agno + AgentOS resulta especialmente atractivo.

Escenario real 1: copilot de producto dentro de una aplicación web

Supongamos que estás creando un copilot de atención al cliente en un producto SaaS.

Quieres:

• un agente principal que hable con el usuario
• un subagente de investigación que reúna el contexto de la cuenta y los tickets anteriores
• un subagente de políticas que revise las reglas de reembolso o escalamiento
• que la respuesta final se transmita en streaming a la interfaz de la aplicación

Este es un caso de uso muy común de «subagentes en la nube».

Por qué AI SDK suele ser la mejor opción aquí

AI SDK destaca cuando:

• tu producto principal ya usa TypeScript y React
• el agente principal vive cerca de la interfaz
• los subagentes son solo una parte del flujo de la solicitud en el producto
• quieres controlar explícitamente lo que ve el modelo principal

La documentación de AI SDK admite explícitamente este patrón mediante subagentes como herramientas y toModelOutput.

Ejemplo con AI SDK

import { tool, ToolLoopAgent } from "ai";
import { z } from "zod";

const accountResearcher = new ToolLoopAgent({
  model: "openai/gpt-5.1",
  instructions: `You are an account research subagent.
Return a short final summary with:
- account status
- relevant prior tickets
- any refund risk
- unresolved uncertainty`,
  tools: {
    getAccount: accountLookupTool,
    getTickets: ticketHistoryTool,
  },
});

const researchAccount = tool({
  description: "Research the customer's account before responding.",
  inputSchema: z.object({
    userId: z.string(),
  }),
  execute: async ({ userId }) => {
    return await accountResearcher.generate({
      prompt: `Research user ${userId} for support response planning.`,
    });
  },
  toModelOutput: ({ output }) => {
    const lastText = output?.text ?? "No summary produced.";
    return { type: "text", value: lastText };
  },
});

export const supportAgent = new ToolLoopAgent({
  model: "anthropic/claude-sonnet-4.5",
  instructions:
    "Help the user clearly. Use researchAccount before giving any account-specific answer.",
  tools: { researchAccount, checkPolicy: refundPolicyTool },
});

En la nube

Este patrón funciona bien cuando se despliega como parte del backend de tu aplicación en Vercel o en un entorno alojado similar:

• el agente principal permanece cerca de tu interfaz y de tu capa de autenticación
• los subagentes siguen siendo detalles de implementación de la solicitud
• la persistencia permanece en la base de datos de tu aplicación, no oculta dentro del framework

Dónde suelen surgir problemas

• Los equipos intentan hacer que AI SDK se comporte como un motor de workflows duraderos.
• Permiten que cada subagente devuelva su transcripción completa sin procesar al contexto del agente principal.
• Olvidan que la memoria a largo plazo y el comportamiento de los reintentos siguen siendo responsabilidad de la aplicación.

Si el workflow consiste principalmente en «responder a un usuario dentro del producto», AI SDK suele ser la opción más clara.

Escenario real 2: pipeline prolongado de investigación o cumplimiento

Ahora imagina un workflow más operativo.

Quieres:

• un agente planificador que divida una revisión de cumplimiento en tareas
• un especialista en recuperación de información que reúna documentos
• un analista de políticas que compare esos documentos con los requisitos de control
• un redactor que prepare el informe final
• que toda la ejecución pueda superar reintentos, pausas y pasos de aprobación humana

Esto ya no es solo un problema de «solicitud de una aplicación web».

Es un problema de workflow.

Por qué LangChain/LangGraph suele ser la mejor opción aquí

LangChain y LangGraph destacan cuando:

• la tarea necesita checkpoints y capacidad de reanudación
• quieres una semántica clara para los hilos
• distintos agentes deben ver distintas partes del estado
• el workflow puede ejecutarse de forma remota o cruzar los límites entre grafos desplegados

El énfasis de la documentación en ingeniería de contexto, subgrafos, persistencia y ejecución duradera encaja con este escenario.

Ejemplo al estilo de LangGraph

import { Annotation, StateGraph } from "@langchain/langgraph";
import { PostgresSaver } from "@langchain/langgraph-checkpoint-postgres";

const State = Annotation.Root({
  request: Annotation<string>(),
  evidence: Annotation<string[]>(),
  draft: Annotation<string>(),
});

const gatherEvidence = async (state: typeof State.State) => {
  return {
    evidence: await retrievePoliciesAndDocs(state.request),
  };
};

const writeDraft = async (state: typeof State.State) => {
  return {
    draft: await draftComplianceReport(state.evidence),
  };
};

const graph = new StateGraph(State)
  .addNode("gatherEvidence", gatherEvidence)
  .addNode("writeDraft", writeDraft)
  .addEdge("__start__", "gatherEvidence")
  .addEdge("gatherEvidence", "writeDraft")
  .addEdge("writeDraft", "__end__");

const checkpointer = PostgresSaver.fromConnString(process.env.DATABASE_URL!);

export const complianceWorkflow = graph.compile({ checkpointer });

Puedes hacer que cada nodo llame a un agente especializado o a un subgrafo. El punto importante del diseño es que el estado del workflow persiste entre pasos y ejecuciones.

Flujo ASCII

User request
   |
   v
Planner / Router
   |
   +--> Retrieval subgraph ----+
   |                           |
   +--> Policy analysis -------+--> Report writer --> Human approval --> Final artifact
                               |
                         checkpointed state

En la nube

Este es el patrón en el que confiaría para sistemas alojados que necesitan:

• ejecución duradera
• capacidad de reanudarse después de un fallo
• orquestación prolongada de varios pasos
• componentes de grafos desplegados de forma remota

Dónde suelen surgir problemas

• Los equipos convierten funciones simples de solicitud y respuesta en grafos innecesariamente complejos.
• Tratan cada componente auxiliar como un agente cuando bastaría con una llamada normal a una herramienta.
• Subestiman la importancia del diseño del esquema y del estado cuando el workflow se vuelve duradero.

Si la frase «reanudar esta ejecución mañana» importa para tu equipo de producto u operaciones, vale la pena considerar LangGraph muy seriamente.

Escenario real 3: plataforma interna de agentes o servicio multiagente programado

Ahora considera otro caso.

Estás creando una plataforma interna para tu empresa:

• los equipos de investigación ejecutan agentes analistas
• los equipos de operaciones ejecutan automatizaciones de workflows
• los responsables quieren trazas, aprobaciones, sesiones y programación de tareas
• varios equipos necesitan inspeccionar y operar el sistema en producción

Esto ya no es solo una abstracción de código.

Es un producto operativo.

Por qué Agno + AgentOS suele ser la mejor opción aquí

Agno y AgentOS destacan cuando:

• trabajas principalmente con Python
• quieres que los equipos y workflows sean conceptos de primer nivel
• quieres un plano de control real para observar las ejecuciones
• la programación de tareas, las aprobaciones y la visibilidad de las sesiones importan desde el primer día

La documentación de AgentOS es especialmente explícita en este punto. Describe un plano de control para agentes, equipos, workflows, aprobaciones, trazas, sesiones, memorias y programación de tareas. Esto se parece mucho más a una plataforma de runtime multiagente que a una abstracción ligera de un SDK.

Ejemplo al estilo de Agno

from agno.agent import Agent
from agno.team import Team
from agno.models.openai import OpenAIChat

researcher = Agent(
    name="Researcher",
    model=OpenAIChat(id="gpt-5.1"),
    instructions="Gather evidence and return only source-backed findings.",
    tools=[search_docs_tool],
)

writer = Agent(
    name="Writer",
    model=OpenAIChat(id="gpt-5.1"),
    instructions="Write a concise executive draft from the research findings.",
)

editor = Agent(
    name="Editor",
    model=OpenAIChat(id="gpt-5.1"),
    instructions="Review the draft for accuracy, clarity, and missing risks.",
)

content_team = Team(
    name="Content Team",
    mode="coordinate",
    members=[researcher, writer, editor],
    instructions="Delegate clearly and keep outputs short between steps.",
)

Luego exponlo a través de AgentOS:

from agno.os import AgentOS

os = AgentOS(teams=[content_team])
app = os.get_app()

if __name__ == "__main__":
    os.serve(app="main:app", port=8000, reload=False)

En la nube

Este modelo es especialmente atractivo cuando quieres:

• servicios de agentes expuestos mediante APIs
• sesiones y trazas persistentes
• un plano de control accesible desde el navegador para los equipos de operaciones
• workflows programados al estilo de cron
• un solo runtime que atienda a varios equipos de agentes

Dónde suelen surgir problemas

• Los equipos adoptan el runtime completo antes de confirmar que realmente necesitan una plataforma.
• Suponen que cada equipo necesita una topología multiagente cuando un solo agente con herramientas sería más simple.
• No dedican suficiente esfuerzo a las instrucciones del equipo y a los límites entre roles, lo que reduce la utilidad de las funciones del runtime.

Si tu arquitectura se orienta hacia «necesitamos un servicio interno de agentes, no solo una función de la aplicación», Agno se vuelve mucho más atractivo.

Comparación: qué busca optimizar realmente cada framework

Lo que realmente recomendaría

Si hoy asesorara a un equipo, usaría estas reglas.

Elige AI SDK cuando:

• tu producto ya está centrado en TypeScript
• los subagentes forman parte del flujo de una solicitud, no de una plataforma de operaciones
• quieres que la aplicación principal controle la autenticación, la persistencia, la interfaz y el despliegue en la nube
• necesitas uno o dos especialistas, no todo un ecosistema de runtime

Elige LangChain/LangGraph cuando:

• el workflow es prolongado o propenso a interrupciones
• la capacidad de reanudación es un requisito del producto
• los pasos de los agentes necesitan estado de hilo persistente y checkpoints
• te sientes cómodo modelando workflows explícitamente en lugar de ocultarlos en el código de la aplicación

Elige Agno + AgentOS cuando:

• quieres un runtime Python dedicado para agentes, equipos y workflows
• la visibilidad operativa importa desde el principio
• esperas que la programación de tareas, las aprobaciones y la gestión de sesiones sean requisitos de primer nivel
• tu sistema se parece más a una plataforma interna que a una función de una sola aplicación

Reflexión final

La pregunta práctica sobre los subagentes no es «¿qué framework admite múltiples agentes?».

Los tres lo hacen, de distintas maneras.

La mejor pregunta es:

¿Dónde debería vivir la coordinación en tu sistema en la nube?

AI SDK dice: deja que la aplicación se encargue.

LangGraph dice: deja que el grafo del workflow se encargue.

Agno/AgentOS dice: ejecútala dentro de un runtime de agentes dedicado.

Esa decisión moldeará tu arquitectura mucho más que el hecho de que la documentación use las palabras «subagente», «equipo» o «workflow».

Fuentes

• Vercel AI SDK: Subagentes
• Vercel AI SDK: Memoria
• Base de conocimientos de Vercel: Agentes de IA en Vercel
• Documentación de LangChain: Multiagente
• Documentación de LangGraph: Uso de subgrafos
• Documentación de LangGraph: Persistencia
• Documentación de LangGraph para Python: Ejecución duradera
• Documentación de LangSmith: Invocar agentes desde código
• Documentación de Agno: Equipos
• Introducción a AgentOS
• Plano de control de AgentOS
• Documentación de Agno: Equipo remoto
• Documentación de Agno: Workflow remoto