Construir agentes de IA confiables: lo que la producción realmente exige
Casi todos los demos de agentes de IA funcionan. Casi ningún agente de IA en producción lo hace — al menos no al primer intento. La distancia entre un demo convincente y un sistema del que dependen usuarios reales es donde vive casi toda la ingeniería de verdad, y rara vez se trata del prompt.
Después de llevar funciones multiagente y con LLMs a producción, llegué a tratar la confiabilidad de los agentes como un problema de sistemas primero y de prompting después. Así es como lo pienso.
El modelo es la capa de orquestación, no una función
El error de arquitectura más común es pegar un LLM al costado de una app existente: un botón que llama a un modelo, recibe un bloque de texto y espera lo mejor. Eso funciona para un demo y se desmorona con tráfico real.
En un sistema AI-native, el modelo es la capa de orquestación. Decide qué pasa después, llama herramientas, delega en otros agentes y se recupera cuando algo sale mal. Ese cambio de enfoque lo cambia todo aguas abajo — cómo manejas errores, cómo observas el sistema y cómo razonas sobre la corrección.
Diseña para el fallo, porque el modelo va a fallar
Los LLMs son probabilísticos. Alucinan argumentos de herramientas, devuelven JSON malformado, entran en bucles y, a veces, simplemente dejan de tener sentido. Un agente en producción debe asumir que todo esto va a pasar y mantenerse correcto de todos modos.
En concreto, eso significa:
- Valida cada llamada a herramienta. Trata la salida del modelo como entrada de usuario no confiable. Valida los argumentos contra un esquema antes de ejecutar nada. Si la validación falla, devuelve el error al modelo y deja que reintente — no te caigas.
- Acota el bucle. Todo bucle de agente necesita un techo duro de pasos y tokens. Un agente sin límites es un bug de costo y latencia esperando a ocurrir.
- Haz las acciones idempotentes o reversibles. Si un agente reintenta un paso, la segunda ejecución no debe cobrarle dos veces a un cliente ni enviar dos correos.
- Falla fuerte, recupérate en silencio. Expón los fallos en tu telemetría, pero dale al agente un camino degradado y elegante para el usuario.
La observabilidad no es negociable
No puedes depurar lo que no puedes ver. Con código determinista, un stack trace te dice qué pasó. Con un agente, necesitas la traza completa de por qué: cada prompt, cada llamada a herramienta, cada decisión intermedia, con tiempos y conteo de tokens adjuntos.
Instrumento los agentes para que cualquier ejecución pueda reproducirse e inspeccionarse de principio a fin. Cuando algo sale mal en producción — y va a salir — la diferencia entre un arreglo de cinco minutos y uno de cinco horas es si capturaste esa traza.
Evals por encima de la intuición
“Parece mejor” no es un criterio de release. Antes de cambiar un prompt, un modelo o una herramienta, quiero un set de evals que mida si el cambio realmente ayuda. No tiene que ser elaborado — unas decenas de casos representativos con criterios claros de aprobado/fallido atrapan la mayoría de las regresiones y te liberan de re-probar a mano en cada cambio.
Esta es la parte que los equipos se saltan porque se siente lenta. Es la parte que te deja moverte rápido sin romper lo que ya funciona.
Multiagente: poder y costo
Dividir el trabajo entre agentes especializados — un planificador, trabajadores, un verificador — es genuinamente poderoso. Permite que cada agente se mantenga enfocado, y un verificador adversarial puede atrapar errores que un solo agente lanzaría con confianza.
Pero cada agente es latencia, tokens y una nueva superficie de fallo. Recurro a diseños multiagente cuando el problema es realmente descomponible o cuando la verificación independiente importa — no porque el diagrama de arquitectura se vea impresionante. Gana el diseño más simple que cumpla el estándar de confiabilidad.
Hacia dónde va esto
La frontera se mueve rápido: modelos más baratos, contexto más largo, mejor uso de herramientas y modelos de pesos abiertos cada vez más capaces que puedes hacer fine-tuning para tu propio dominio. Los ingenieros que ganen los próximos años no serán los de los prompts más ingeniosos — serán los que traten a los agentes como sistemas de producción, con el mismo rigor que ya aplicamos a los sistemas distribuidos.
Ese es el trabajo que me importa: construir agentes que no solo se vean bien en un demo, sino que aguanten cuando el mundo se apoya en ellos.
¿Estás construyendo algo en este espacio, o contratando para ello? Me encuentras en [email protected].