Hay un momento que le ocurre a casi todos los equipos que construyen un agente de IA por primera vez. La demo funciona de maravilla. El agente responde preguntas, usa herramientas, recuerda el contexto. Se lo muestras a los stakeholders y quedan impresionados. Luego alguien pregunta: "¿Podemos poner esto en producción?"
Esa pregunta revela una brecha que la mayoría de los equipos subestima. Los agentes de demo están construidos para funcionar una vez, en un entorno controlado, con un desarrollador mirando. Los agentes de producción necesitan funcionar miles de veces, en condiciones impredecibles, sin que nadie mire.
La trampa de la demo
Los agentes de demo son típicamente sin estado. Reiniciarlos y no se pierde nada, porque nada se guardó. No tienen autenticación, porque el desarrollador que ejecuta la demo es de confianza. No tienen limitación de velocidad, porque solo hay un usuario. No tienen monitoreo, porque el desarrollador puede ver lo que está pasando.
La producción elimina cada uno de esos supuestos. Los usuarios pierden contexto cuando el agente se reinicia. Usuarios no autorizados encuentran el endpoint. Alguien envía mil mensajes en un minuto. El agente da una respuesta incorrecta y nadie sabe por qué. El proveedor de IA se cae y el agente falla en lugar de degradarse con gracia.
Lo que la producción realmente exige
El primer requisito es estado persistente y fiable. Un agente de producción gestiona conversaciones en curso, preferencias de usuario acumuladas, colas de tareas y contexto aprendido. Ese estado necesita sobrevivir a los reinicios, sobrevivir a los fallos y ser recuperable cuando algo sale mal.
ZeroClaw maneja esto con SQLite en modo WAL: compatible con ACID, archivo único, sobrevive a los cortes de energía. Todo el estado del agente vive en un archivo. Hacer una copia de seguridad es `cp memory.db memory.db.bak`.
El segundo requisito es un modelo de seguridad que no dependa de la confianza. Los agentes de producción manejan credenciales reales, acceden a sistemas de archivos reales e interactúan con usuarios reales que buscarán debilidades. El modelo de seguridad no puede ser "confiar en el desarrollador del plugin" o "asumir que los usuarios se comportan bien". Necesita ser denegado por defecto.
Esto es precisamente donde falló la arquitectura de OpenClaw en 2026. El modelo de confianza de WebSocket, los permisos de skills a nivel de SO y el marketplace de plugins con el 41,7% de entradas vulnerables no eran bugs —eran decisiones arquitectónicas que tenían sentido para una herramienta de desarrollador y se convirtieron en pasivos cuando esa herramienta se desplegó como infraestructura de producción.
El tercer requisito es la observabilidad. Cuando un agente da una respuesta incorrecta en producción, "usó el contexto incorrecto" no es un diagnóstico útil. Necesitas trazado de solicitudes desde la recepción del mensaje hasta la entrega de la respuesta, seguimiento del uso de tokens por conversación y por usuario, logs de ejecución de herramientas con entradas y salidas, y logs de recuperación de memoria que muestren exactamente qué contexto se inyectó en cada solicitud.
La fiabilidad es el cuarto requisito. Producción significa expectativas de disponibilidad 24/7, lo que significa reinicio automático en caso de fallo, degradación elegante cuando el proveedor de IA no está disponible, reintento de conexión con backoff exponencial para los canales, y endpoints de comprobación de salud para los sistemas de monitoreo.
El quinto requisito es el control de costes. Los agentes de IA sin control queman tokens de formas difíciles de predecir. La producción requiere presupuestos de tokens por usuario y por canal, limitación de velocidad para prevenir abusos, y enrutamiento de modelos —modelos baratos para consultas simples, modelos caros para las complejas.
Lo que la mayoría de los frameworks hacen mal
El camino feliz recibe toda la atención. El manejo de errores obtiene un try-catch que registra en la consola. La lógica de reintento se deja como ejercicio para el lector. La degradación elegante es un comentario TODO. Cuando el proveedor de IA devuelve un 429, el agente falla en lugar de poner en cola la solicitud y reintentar con backoff.
La eficiencia de recursos se trata como algo agradable de tener en lugar de un multiplicador de costes. Un framework que usa 1 GB de RAM para una sola instancia de agente no puede escalar a despliegues multi-tenant sin una infraestructura costosa.
La seguridad es el descuido más común. El instinto es construir la función primero y añadir seguridad después. Pero la seguridad no se puede añadir a posteriori sobre una arquitectura permisiva —la crisis de OpenClaw lo demostró a escala.
La historia de producción de ZeroClaw
ZeroClaw fue diseñado para producción desde el principio. Un binario único significa que el despliegue es copiar un archivo de 12 MB. La huella de 4 MB de RAM significa que puedes ejecutar 50 instancias de agente en un único VPS de 1 GB, haciendo los despliegues multi-tenant económicamente viables. El arranque en frío de menos de 10 ms significa que los reinicios son invisibles para los usuarios.
La seguridad de memoria de Rust elimina clases enteras de vulnerabilidades en tiempo de compilación. El modelo de lista de permisos denegado por defecto significa que cada herramienta, ruta de archivo y endpoint de red debe ser explícitamente permitido en config.toml. SQLite con modo WAL te da estado compatible con ACID en un único archivo sin servidor de base de datos que gestionar.
La lista de verificación de producción
Para los equipos que llevan agentes de IA a producción, la lista de verificación tiene menos que ver con funciones y más con la madurez operativa. Define los permisos de herramientas explícitamente antes de lanzar. Establece presupuestos de tokens por usuario y por canal antes de que te sorprenda una factura. Configura monitoreo y alertas sobre tasas de error y percentiles de latencia. Configura copias de seguridad automatizadas de la base de datos de memoria. Prueba los escenarios de fallo deliberadamente: ¿qué pasa cuando el proveedor de IA está caído? ¿Cuando el canal se desconecta? ¿Cuando el disco se llena?
La brecha entre la demo y la producción es la madurez operativa. El framework que eliges determina cuánto de esa madurez está integrada frente a añadida a posteriori. Un runtime diseñado para producción desde el primer día te da una base sobre la que construir. Un runtime diseñado para demos, con funciones de producción añadidas a posteriori, te da una carga de mantenimiento que se acumula con el tiempo.