Elegir un framework de agentes no consiste en comparar cuántas integraciones aparecen en una página de producto. La cuestión importante es qué debe poder hacer el sistema cuando deja de ser una demostración: mantener estado, pedir una aprobación, reintentar una tarea, limitar permisos, registrar una decisión y recuperarse de un fallo.
El mercado se ha movido rápido. En lugar de una única categoría de «framework de agentes», hoy conviven tres enfoques: runtimes ligeros para añadir herramientas y delegación a una aplicación; orquestadores de grafos para procesos largos y controlados; y harnesses que incorporan un entorno de trabajo, herramientas, memoria y permisos. Esta comparativa revisa seis opciones actuales con una pregunta práctica: ¿qué problema resuelve mejor cada una en una empresa?
Antes de comparar: un agente no sustituye a un flujo determinista
Un agente es útil cuando debe interpretar información no estructurada, elegir entre herramientas dentro de un límite o preparar una respuesta contextual. Si el proceso ya se puede describir como una secuencia estable de validaciones y llamadas a API, un workflow convencional será más fácil de probar, auditar y operar.
La arquitectura más sólida suele ser híbrida: reglas y validaciones para lo que no admite ambigüedad; IA para clasificar, extraer, resumir o proponer; y una aprobación humana para acciones sensibles. Esta distinción importa más que el nombre del framework.
La comparativa rápida
| Opción | Enfoque principal | Encaja especialmente en | Atención antes de adoptarla |
|---|---|---|---|
| LangGraph | Orquestación de grafos y estado duradero | Procesos complejos, largos o con reanudación y revisión humana | Es deliberadamente de bajo nivel: exige diseñar bien estado, nodos y pruebas |
| Google ADK | Kit multilenguaje con agentes, grafos y colaboración | Equipos que buscan una plataforma común en Python, TypeScript, Go, Java o Kotlin | Conviene validar la integración real con el modelo, la nube y el despliegue elegidos |
| OpenAI Agents SDK | Primitivas ligeras: agentes, herramientas, handoffs y guardrails | Aplicaciones que quieren un loop de agente sencillo y trazable sin inventar una abstracción nueva | Revise la dependencia de servicios, el modelo operativo de datos y el coste de cada ejecución |
| Microsoft Agent Framework | Agentes, workflows y un harness con foco empresarial | Entornos .NET o Azure y equipos que vienen de AutoGen o Semantic Kernel | Está evolucionando: planifique la migración y pruebe compatibilidad antes de estandarizar |
| PydanticAI | Python tipado, validación estructurada y proveedores intercambiables | Backends Python donde el contrato de entrada y salida es crítico | El tipado reduce errores de integración, pero no convierte una respuesta del modelo en un hecho correcto |
| Claude Agent SDK | Harness programable de Claude Code | Agentes de ingeniería que necesitan ficheros, terminal, sesiones, permisos, MCP y subagentes | Diseñe con precisión el sandbox, las aprobaciones y el alcance de las herramientas |
LangGraph: control explícito para procesos que deben durar
LangGraph se define como un runtime de orquestación de bajo nivel para agentes con estado y de larga duración. Su propuesta es clara: combinar pasos deterministas escritos por el equipo con decisiones asistidas por un modelo dentro de un mismo grafo. Incorpora capacidades de persistencia, reanudación tras fallos, streaming e intervención humana sobre el estado.
Es una buena elección cuando el recorrido no es lineal. Por ejemplo, un expediente puede pasar por extracción documental, comprobaciones de negocio, una consulta a varios sistemas, una cola de excepciones y una aprobación antes de actualizar un ERP. En ese escenario, poder inspeccionar y retomar el estado aporta más valor que crear varios agentes con nombres llamativos.
Su contrapartida es que no oculta la complejidad. Hay que decidir qué se guarda, cómo se versiona el estado, qué nodo es idempotente y cómo se prueba cada transición. Para una primera automatización de tres pasos, puede ser más de lo necesario.
Google ADK: agentes y workflows en varios lenguajes
El Agent Development Kit (ADK) de Google ha reforzado su orientación a producción con workflows basados en grafos y agentes colaborativos. Su cobertura de Python, TypeScript, Go, Java y Kotlin resulta interesante si la empresa no quiere que cada área adopte una base técnica distinta para sus agentes.
La ventaja práctica es poder separar el diseño del proceso de una implementación exclusivamente Python. Puede encajar en organizaciones con servicios de backend diversos o con una plataforma interna que necesita exponer el mismo patrón de agente a varios equipos.
La decisión no debe basarse solo en la lista de lenguajes. Antes de adoptarlo, pruebe cómo resolverá autenticación, trazas, despliegue, almacenamiento de estado, acceso a datos y portabilidad entre proveedores de modelos. Un framework multilenguaje no elimina esas decisiones; las hace más visibles.
OpenAI Agents SDK: menos abstracciones para aplicaciones con herramienta y delegación
OpenAI plantea su Agents SDK como un conjunto reducido de primitivas: agentes, handoffs entre especialistas y guardrails. Añade herramientas, trazas y un loop de ejecución gestionado, de modo que el equipo no tenga que implementar desde cero la alternancia entre modelo y llamadas a herramientas.
Es útil para construir un asistente operativo que consulta fuentes autorizadas, prepara un resultado estructurado y deriva ciertos casos a un especialista. El diseño ligero facilita entender qué está ocurriendo y evita aprender un lenguaje de workflows propio para problemas sencillos.
La cautela es no confundir «delegación» con arquitectura empresarial. Tener varios agentes no resuelve automáticamente la calidad de datos, los permisos o las decisiones irreversibles. Si el agente puede crear un pedido, enviar un correo contractual o modificar un registro crítico, el guardrail debe complementarse con una política determinista y una autorización externa al modelo.
Microsoft Agent Framework: la convergencia de AutoGen y Semantic Kernel
Microsoft presenta Agent Framework como sucesor directo de AutoGen y Semantic Kernel. Une abstracciones de agente y multiagente con sesiones, middleware, telemetría, tipos y workflows basados en grafos. Incluye además un harness orientado a tareas largas, con planificación, seguimiento de tareas, memoria, acceso a ficheros y aprobaciones.
Para equipos que ya trabajan con .NET, Azure o los proyectos anteriores de Microsoft, es una opción natural para evaluar. Su planteamiento diferencia con buen criterio el agente abierto de un workflow con pasos conocidos: si puede resolverlo una función, la documentación recomienda usar una función.
Como ocurre con toda consolidación de plataformas, es importante no convertir una migración en un proyecto puramente técnico. Empiece por un caso acotado, defina una estrategia de observabilidad y confirme que las versiones y conectores necesarios están listos para su entorno.
PydanticAI: contratos de datos fuertes en Python
PydanticAI se dirige a equipos Python que quieren construir agentes con el mismo énfasis en tipos y validación que emplean en servicios web modernos. Combina el loop de agente con dependencias tipadas, salidas estructuradas, integración MCP, aprobaciones, evaluación, trazas y compatibilidad con múltiples modelos y proveedores.
Su mejor caso de uso es una automatización donde el resultado debe convertirse en una estructura verificable antes de tocar otro sistema: clasificar una solicitud, extraer campos de un documento, proponer una acción o preparar una orden para revisión. Validar que una salida cumple un esquema permite detectar respuestas incompletas antes de enviarlas a CRM, ERP o una cola de trabajo.
Hay un límite importante: un JSON válido puede contener una conclusión equivocada. El contrato técnico debe acompañarse de fuentes, reglas de negocio, umbrales de confianza y muestreo humano. La validación de esquema protege la integración; no sustituye la validación de la decisión.
Claude Agent SDK: cuando el agente necesita un entorno de trabajo real
El Agent SDK de Anthropic lleva a Python y TypeScript el loop y las capacidades de Claude Code: lectura y edición de ficheros, comandos, búsqueda web, sesiones, subagentes, MCP, permisos, habilidades y hooks. Se sitúa más cerca de un harness que de una librería mínima de llamadas a modelo.
Es especialmente relevante para tareas de ingeniería, análisis de repositorios, mantenimiento operativo o automatizaciones que deben trabajar con artefactos reales. La posibilidad de controlar aprobaciones, ejecutar hooks y aislar el entorno es más importante que el número de subagentes que se lancen.
La pregunta decisiva aquí es de seguridad: ¿qué directorios puede leer o modificar?, ¿qué comandos están permitidos?, ¿dónde se ejecutan?, ¿qué acciones requieren aprobación y cómo se conserva la evidencia? Un agente con terminal sin un límite claro no es una automatización madura.
Cómo elegir sin caer en una comparativa de logos
Antes de iniciar un piloto, responda por escrito a estas seis preguntas:
- ¿Qué decisión o tarea concreta mejora? Defina una salida observable, no el objetivo genérico de «tener un agente».
- ¿Qué debe ser determinista? Mantenga fuera del modelo importes, permisos, reglas legales, límites de aprobación y cambios irreversibles.
- ¿Qué estado debe sobrevivir? Si hay esperas, reintentos o trabajo entre varios días, priorice persistencia, idempotencia y reanudación.
- ¿Con qué herramientas y datos se conecta? Inventarie identidades técnicas, ámbitos de acceso, datos enviados y acciones permitidas.
- ¿Cómo se observa y evalúa? Necesita trazas, registros de herramientas, conjuntos de prueba y revisión de casos fallidos antes de medir productividad.
- ¿Qué pasa si falla? Diseñe una cola, una ruta manual o un modo degradado; no deje que el sistema improvise una acción sensible.
En términos sencillos: elija LangGraph si el núcleo es el control de un proceso con estado; Google ADK si necesita una base multilenguaje de agentes y workflows; OpenAI Agents SDK si busca primitivas ligeras y directas; Microsoft Agent Framework si su contexto empresarial se apoya en el ecosistema Microsoft; PydanticAI si Python y los contratos de datos son centrales; y Claude Agent SDK si el trabajo exige un entorno de ingeniería completo.
El framework es una decisión reversible; el diseño de control no
Los frameworks seguirán cambiando más rápido que los procesos de negocio. Por eso conviene aislar las integraciones, guardar el estado en componentes controlados por la empresa, modelar las acciones como contratos y no atar los permisos a un prompt. Cambiar de librería será entonces un proyecto de evolución, no una reconstrucción total.
Si quiere convertir un proceso real en una automatización con IA que sea útil y operable, en KMOOPS podemos ayudarle a definir el caso, integrar los sistemas y diseñar los controles necesarios. Consulte nuestros servicios o contacte con nosotros.