Los agentes en producción.

La demo no es el producto.

Una demo responde a una sola pregunta: si la idea funciona. Corre sobre ejemplos escogidos, en una sala tranquila, con alguien delante del teclado que sabe exactamente qué escribir. Nada de eso se parece a un martes por la tarde en un departamento de siniestros.

La producción es otro entorno. Las entradas son desordenadas: documentos escaneados, correos a medio terminar, una hoja de cálculo que alguien editó a mano el año pasado. El usuario no conoce la frase exacta. El sistema tiene que funcionar de todos modos, o decir con claridad que no puede.

Qué cambia cuando el modelo empieza a trabajar.

01

Entradas → Barreras

En una demo, un error es un tema de conversación. En producción, un error llega a un cliente, a un contrato o a una máquina. Eso cambia todo el diseño: dejas de optimizar para la mejor respuesta y empiezas a optimizar para la peor que puedas asumir.

02

Cola de revisión → Monitorización

Un modelo que solo existe en un cuaderno nunca se desvía, porque nadie observa cómo se enfrenta a datos nuevos. En cuanto entra en tu entorno, las entradas cambian debajo de él: proveedores nuevos, frases nuevas, casos límite que nadie probó. Sin monitorización, te enteras por una queja en vez de por un panel de control.

03

Traspaso

Alguien de tu equipo tiene que quedarse con el sistema cuando nos vamos: leer sus registros, reentrenarlo, decidir cuándo apagarlo. Diseñamos ese traspaso desde el primer sprint, no desde el último.

Nada de esto es exótico. Es la misma disciplina que ya necesita cualquier software en producción, aplicada a un sistema que puede equivocarse con seguridad de una forma distinta cada semana. Las herramientas cambian; el criterio no debería. Un equipo que trata a un agente como un servicio normal, con la misma revisión y los mismos hábitos de guardia, suele llevarse menos sorpresas que uno que lo trata como magia.

Qué construimos en lugar de una demo.

Empezamos por la versión más estrecha de la tarea que siga siendo útil: un tipo de documento, una decisión, un equipo. La ponemos delante de usuarios reales con datos reales antes de añadir nada más. Si falla, falla en pequeño y falla pronto, donde sale barato arreglarlo.

Después añadimos las partes que nunca aparecen en una demo: registro de actividad, reintentos, una forma de marcar una respuesta incorrecta, una persona que revisa los casos marcados. Todo eso es lo que hace que un agente sobreviva a un martes por la tarde.