La distancia entre un agente de IA que funciona en demo y uno que aguanta datos reales en producción es mayor de lo que parece. Hemos construido suficientes sistemas para saber que el problema no está en el modelo ni en el prompt. Está en tres capas: la arquitectura de herramientas que rodea al modelo, la estrategia de evaluación, y cómo se instrumenta la observabilidad.
Este post no es teórico. Es un resumen de las decisiones que tomamos en cada proyecto y por qué las tomamos. Algunas parecen obvias en retrospectiva. Ninguna lo era cuando las aprendimos por primera vez.
Por qué los demos de agentes de IA mienten
Un demo de agente siempre funciona bien porque está construido sobre supuestos que en producción no se cumplen: datos limpios, casos de uso bien definidos, usuarios que siguen el happy path. Cuando el agente se conecta al sistema real, aparecen las excepciones: datos mal formateados, llamadas a APIs que a veces fallan, inputs ambiguos que el modelo interpreta de formas inesperadas, y casos edge que nadie documentó porque nadie los había considerado importantes.
Diseñar para producción desde el principio no es más lento que diseñar para demo. Es diferente. Requiere tomar decisiones de arquitectura que parecen innecesarias hasta que el agente lleva tres semanas en producción y las necesitas.
Los tres niveles de una arquitectura de agente para producción
Nivel 1: El modelo de decisión
El modelo de lenguaje es solo una capa. Lo que decide si el agente funciona en producción es qué contexto recibe, cómo se estructura ese contexto, y qué mecanismo de fallback existe cuando el modelo produce una salida que no cumple el esquema esperado.
En producción, el modelo fallará en algunos casos. No por bug, sino porque los LLMs no son deterministas y los datos reales tienen distribuciones que el modelo no ha visto en evaluación. La arquitectura tiene que absorber esos fallos sin que el sistema entero se detenga. Esto significa: validación de esquema en la salida del modelo, reintentos con prompt modificado cuando falla la validación, y un camino de fallback explícito que deriva a revisión humana cuando los reintentos se agotan.
Nivel 2: La capa de herramientas
Los agentes útiles usan herramientas: consultan bases de datos, llaman a APIs externas, leen y escriben en sistemas del cliente. Cada operación de herramienta tiene que ser idempotente, estar envuelta en manejo de errores explícito, y tener un timeout definido. Si no, el agente queda colgado esperando una API que no responde, o reintenta una operación que ya completó con efectos secundarios.
Las herramientas también tienen que estar diseñadas para que el modelo las use correctamente. Un tool schema mal escrito produce un agente que llama a las herramientas con argumentos erróneos. Esto no falla con datos de prueba limpios. Falla con datos reales ambiguos, que son los que encontrarás en producción.
Un tool schema es una interfaz de comunicación entre el modelo y el sistema. Si la interfaz es ambigua para un humano, es aún más ambigua para el modelo.
Nivel 3: Observabilidad desde el primer commit
Sin observabilidad, operar un agente en producción es volar a ciegas. Necesitas saber: qué decisiones tomó el modelo en cada ejecución, qué herramientas llamó y con qué argumentos, cuánto tardó cada paso, en qué porcentaje de casos el agente tomó el camino de fallback, y qué inputs produjeron outputs erróneos.
Instrumentamos con LangSmith para tracing de agentes y Sentry para errores de sistema. Los dashboards de métricas de negocio los construimos a medida porque las métricas que importan son específicas de cada proyecto: en un agente de clasificación de documentos lo que importa es la tasa de error por categoría; en un agente de generación de informes lo que importa es la latencia por tipo de informe.
Evaluación continua, no puntual
La mayoría de equipos evalúa el agente al final del desarrollo: pasan un batch de casos de prueba, miden la tasa de acierto, si supera el umbral el agente se despliega. Este enfoque funciona para modelos de clasificación estáticos. No funciona para agentes.
Los agentes toman decisiones en secuencia. Un error en el paso 2 contamina todos los pasos siguientes. La evaluación tiene que medir la ejecución completa, no solo las salidas individuales. Y tiene que correr en cada PR, no solo antes del release final.
Un agente que pasa el 95% de los casos de prueba con datos limpios puede fallar en el 30% de los casos con datos de producción. La evaluación sin datos reales no mide lo que necesitas medir.
El dataset de evaluación tiene que incluir: los casos habituales que el agente tiene que manejar bien, los casos edge que históricamente han dado problemas, y una muestra de los inputs más difíciles que existen en producción. Este dataset se construye en el sprint de diagnóstico, no en la fase de QA.
Principios no negociables
- Datos de producción en evaluación desde el sprint 1, no en la fase final.
- Cada herramienta del agente tiene timeout explícito y manejo de error definido.
- Tracing activo desde el primer deploy en staging.
- Fallback documentado para cada camino de decisión del agente.
- Los prompts versionados y testeados como código, no como strings sueltos en el repositorio.
Estos principios no hacen el desarrollo más lento. Lo hacen predecible. Y en proyectos de IA para empresas, la predictibilidad vale más que la velocidad inicial. Un agente que entra en producción en seis semanas y funciona es más valioso que uno que entra en cuatro semanas y requiere tres meses de correcciones.