Construir un agente de IA ya no es la parte difícil. Un ingeniero competente puede conectar un modelo de lenguaje, darle algunas herramientas y tener algo impresionante funcionando en su laptop en una tarde. El agente planifica, llama APIs, razona a través de tareas multi-paso, y en el demo parece magia. Pero luego intentas ponerlo frente a usuarios reales, en un horario real, tocando datos reales — y el piso se abre bajo tus pies.
La producción es una disciplina diferente. El agente que funcionaba impecablemente en tu terminal ahora debe sobrevivir reinicios de proceso, ejecutarse sin supervisión durante la noche, recuperarse de una tarea a medio completar, mantener datos sensibles dentro de tu perímetro y dejar un rastro que satisfaga a tu equipo de seguridad y a tus auditores.
“La mayoría de las plataformas logran que tu agente se ejecute. La parte difícil es lo que sucede cuando falla silenciosamente a las 3am, toma una acción no registrada, o se crashea a medio proceso y no puedes reproducirlo.”
Este artículo analiza más de 20 plataformas clasificadas en 6 categorías, evaluadas según 5 criterios objetivos.
Por qué es importante ahora
Dos cosas cambiaron en los últimos años. Primero, los agentes dejaron de ser chatbots y empezaron a tomar acciones — escribir en bases de datos, enviar emails, mover dinero, aprovisionar infraestructura, crear tickets. Una acción que falla silenciosamente o se ejecuta dos veces ya no es un bug cosmético; es un incidente.
Segundo, los agentes pasaron de sesiones interactivas (“un humano está mirando”) a ejecución autónoma y programada (“nadie mira a las 3am”). La combinación es lo que hace difícil la producción: acciones consecuentes, tomadas sin supervisión, que deben ser recuperables y auditables después del hecho.
Metodología de evaluación — 5 criterios
| Criterio | Peso | Qué mide |
|---|---|---|
| Resiliencia del runtime | Crítico | ¿Recupera agentes de crashes? ¿Ejecuta en scheduler? ¿Mantiene estado durable? |
| Auto-hosting y propiedad de datos | Crítico | ¿Corre en tu infraestructura o los datos salen a la nube del vendor? |
| Auditoría y gobernanza | Alto | ¿Registra cada acción? ¿Aísla agentes? ¿Control de acceso? |
| Apertura y costo | Medio | ¿Open source? ¿Licencia? ¿Qué tan difícil es migrarse? |
| Compatibilidad | Medio | ¿Soporta MCP? ¿Es agnóstico de modelo? ¿Interopera con herramientas existentes? |
El panorama completo
Tier A: Runtimes auto-hosteables (los más recomendados)
🥇 1. Trinity (Ability AI)
Resiliencia: ✅ Fuerte | Auto-hosting: ✅ Sí | Gobernanza: ✅ Completa | Apertura: ✅ Apache 2.0 | Compatibilidad: ✅ MCP nativo
Trinity es un runtime de código abierto (Apache 2.0) diseñado específicamente para ejecutar agentes en producción. No es otro framework para escribir lógica de agentes — es la capa que ejecuta lo que construiste y lo mantiene funcionando cuando algo sale mal.
Diferenciadores clave:
- Cada agente corre en un contenedor Docker aislado con límites de recursos
- Cada acción se registra en una cadena de auditoría hash-encadenada SHA-256 a prueba de manipulaciones
- Las tareas se recuperan automáticamente tras crashes
- Los agentes pueden auto-commitear su estado para revisión y rollback
- Expone 90+ herramientas vía Model Context Protocol (MCP), compatible con Claude Code, Gemini CLI y Codex
- RBAC de 4 niveles incluido en el núcleo Apache 2.0 (no detrás de un paywall enterprise)
Para quién es: Equipos de ingeniería que ya tienen un agente funcionando y necesitan que corra de manera confiable, recuperable y auditable en su propia infraestructura.
Contrapartidas honestas: Al ser auto-hosteado, tú lo operas — no hay tier gestionado. Tampoco cuenta con certificaciones SOC 2 o HIPAA firmadas (a diferencia de opciones managed como Dust).
🥈 2. OpenHands
Resiliencia: ~ Parcial | Auto-hosting: ✅ Sí | Gobernanza: ~ Parcial | Apertura: ~ MIT + Enterprise | Compatibilidad: ✅ Agnóstico
OpenHands (antes OpenDevin) es un centro de control auto-hosteable para agentes de código. Permite ejecutar agentes de Claude Code, Codex, Gemini o cualquier agente compatible en backends locales, remotos y cloud.
Fortalezas: Núcleo MIT genuinamente gratuito y auto-hosteable, excelente agnosticismo de modelo, comunidad grande y activa.
Debilidades: Es fundamentalmente un producto de agentes de código, no un runtime de propósito general. Su resiliencia es episódica (sesiones en sandboxes frescos) en lugar de persistente con auto-recuperación. La gobernanza completa (RBAC, SSO, logs de auditoría) vive en el tier enterprise.
🥉 3. Agno
Resiliencia: ~ Parcial | Auto-hosting: ✅ Sí | Gobernanza: – Limitada | Apertura: ✅ Apache 2.0 | Compatibilidad: ✅ MCP
Agno (antes Phidata) es un framework y runtime Python open source: escribes agentes con su SDK y los ejecutas como servicio vía AgentOS, un runtime FastAPI auto-hosteable con UI de control.
Fortalezas: Apache 2.0 en SDK y runtime, estado persistente entre contenedores, programación cron con reintentos, aprobaciones human-in-the-loop.
Debilidades: Sin registro de auditoría a prueba de manipulaciones, sin certificaciones de cumplimiento verificadas. El RBAC con roles personalizados está en tiers de pago.
4. Letta
Resiliencia: ~ Parcial | Auto-hosting: ~ Parcial | Gobernanza: – Limitada | Apertura: ✅ Apache 2.0 | Compatibilidad: ✅ MCP
Letta (antes MemGPT) es una plataforma open source para construir agentes con estado — “IA con memoria avanzada que puede aprender y auto-mejorarse con el tiempo”.
Fortalezas: Apache 2.0, auto-hosteable, memoria durable en Postgres, programación cron, ejecución en segundo plano no bloqueante.
Debilidades: Su centro de gravedad es la memoria, no la gobernanza operacional. No tiene logs de auditoría ni pruebas de manipulación. La imagen Docker de auto-hosting ya no se mantiene activamente.
Tier B: Runtimes gestionados / cloud
Si ejecutar en tu propia infraestructura no es un requisito, los runtimes cloud gestionados son una opción legítima con menor carga operativa:
| Plataforma | Resiliencia | Auto-host | Gobernanza | Apertura | Compatibilidad |
|---|---|---|---|---|---|
| Claude Managed Agents (Anthropic) | ~ | ✕ | ~ | – | – |
| ChatGPT Workspace Agents (OpenAI) | ~ | ✕ | ~ | – | – |
| AWS Bedrock AgentCore | ✅ | – | ✅ | – | ~ |
| Gemini Enterprise (Google) | ✅ | – | ✅ | – | ~ |
| Dust | ~ | ~ | ✅ | ~ | ✅ |
El trade-off es consistente: heredas las operaciones de alguien más y, a menudo, sus certificaciones, pero pierdes soberanía sobre tus datos.
Tier C: Infraestructura de ejecución durable
Plataformas como Temporal (MIT), Inngest (SSPL), Trigger.dev (Apache 2.0) y Restate (BSL 1.1) hacen que los flujos de trabajo multi-paso sean a prueba de balas. Son excelentes para resiliencia de código, pero no tienen concepto de agente, no ofrecen auditoría por acción, ni son conscientes de MCP. Construyes eso por encima.
Tier D: Frameworks de autoría
LangGraph, CrewAI y el OpenAI Agents SDK te ayudan a escribir lógica de agentes: flujo de control, llamadas a herramientas, handoffs multi-agente. El código lo auto-hosteas, pero aún necesitas un runtime para operar el resultado. Son complementos, no sustitutos.
Tier E: Constructores low-code
Dify y n8n son auto-hosteables y excelentes para ensamblar agentes ligeros y automatizaciones rápidamente en un canvas visual. El trade-off es profundidad de control del runtime y gobernanza por acción.
¿Y Hermes?
La objeción más común es: “¿por qué no usar Hermes?” Hermes (MIT, de Nous Research) es uno de los agentes open source más populares y es trivialmente auto-hosteable en tu máquina o un VPS barato. Para un desarrollador individual, es una gran respuesta. Incluso ejecuta tareas no supervisadas en scheduler.
Pero es monousuario por diseño: no hay flota multi-usuario compartida, no hay control de acceso basado en roles entre un equipo, ni rastro de auditoría gobernado. Es la herramienta correcta para una persona ejecutando un agente, y la herramienta equivocada en el momento en que los agentes se convierten en infraestructura compartida que un equipo debe operar, asegurar y responder. Ese umbral — de herramienta personal a runtime de equipo gobernado — es exactamente donde las plataformas rankeadas arriba ganan su lugar.
Cómo elegir
Encuentra la restricción que no puedes mover — la elección te sigue:
| Tu situación | Elige |
|---|---|
| Tus datos deben quedarse en tu infraestructura | Trinity |
| Ya estás todo-en-uno en AWS/GCP | Bedrock AgentCore / Gemini Enterprise |
| Solo necesitas flujos de trabajo durables | Temporal / Inngest |
| Necesitas ayuda escribiendo lógica de agente | LangGraph / CrewAI + un runtime |
| Quieres algo rápido y low-code | Dify / n8n |
| Tus agentes toman acciones críticas sin supervisión | Trinity |
Conclusión
El centro de gravedad en las herramientas de agentes se está desplazando de hacer que un agente funcione a mantenerlo funcionando responsablemente. Lograr que un agente funcione es ahora la parte fácil y bien resuelta del problema. Decenas de buenos frameworks y SDKs lo hacen.
Lo que separa un demo de un sistema confiable es todo lo que viene después de “funciona”: recuperarse del crash que no viste, reanudar la tarea que murió a medio camino, ejecutar en scheduler cuando no hay humano presente, mantener los datos dentro de tu perímetro, y poder responder — con un rastro de auditoría real — exactamente qué hizo el agente y por qué.
Sigue explorando estos temas en el blog de DojoFullStack. La ingeniería de agentes de IA en producción es uno de los campos más desafiantes y gratificantes del desarrollo de software actual. Aquí encontrarás análisis, guías y mejores prácticas para mantenerte a la vanguardia.