Diseñar sistemas agénticos que sobrevivan a producción

Gartner prevé que más del 40% de los proyectos de IA agéntica se cancelen antes de que acabe 2027, por coste, valor poco claro y controles débiles (Gartner, 2025). Ninguno de esos motivos es el modelo. Son problemas de diseño, y así diseñamos sistemas agénticos para que sigan sanos un año después del lanzamiento.

Por qué derivan los agentes

Un agente es una cadena de decisiones probabilísticas que depende de cuatro cosas, y las cuatro cambian:

• Modelos. Los proveedores actualizan pesos y retiran versiones.
• Prompts. Alguien edita una instrucción para arreglar un caso y rompe otros tres.
• Herramientas. Las APIs ganan campos, pierden endpoints, endurecen límites.
• Datos. Las peticiones del próximo trimestre no se parecen a las del anterior.

El fallo habitual no es una caída. Es una bajada lenta de la tasa de resolución que nadie ve, porque nadie definió la métrica.

Orquestación

Más allá de un único agente con un par de herramientas, usamos orquestación explícita: un grafo donde cada nodo es una llamada al modelo, una llamada a herramienta o una comprobación determinista, y cada arista es una transición con nombre.

Dos patrones han aguantado bien:

• Un coordinador con trabajadores especialistas. El coordinador divide el objetivo y reparte partes a agentes acotados con herramientas acotadas. Cada especialista es más fácil de evaluar y más barato de ejecutar que un generalista con cuarenta herramientas.
• Puertas deterministas alrededor de pasos probabilísticos. Precios, reglas de elegibilidad y comprobaciones de permisos son código, no juicio del modelo. El modelo propone; la puerta decide.

El patrón a evitar es un único prompt enorme que lo hace todo. Luce en la demo y se degrada sin que nadie lo note.

Primero la evaluación

Antes de construir, acordamos con el cliente qué significa "resuelto", con números. Esos criterios se convierten en datasets de escenarios reales con resultados esperados, y se ejecutan en cada cambio: actualizaciones de modelo, ediciones de prompt, cambios de herramientas.

Sin ese harness no puedes cambiar de modelo, ni siquiera reformular una instrucción, y saber qué se ha roto. Por eso los criterios de evaluación se escriben antes que el código.

Trazabilidad

Cada ejecución en producción tiene una traza completa: el objetivo, cada llamada al modelo con entradas y salidas, cada llamada a herramienta con argumentos y resultados, latencia, tokens y coste. Cuando algo falla, la respuesta sale de los datos, sin tener que reproducir nada.

Los fallos que aparecen en las trazas se convierten en nuevos casos de evaluación, para que el mismo error se detecte la próxima vez.

Control de costes

Una tarea difícil puede consumir cincuenta veces los tokens de una fácil. Sin controles, la factura mensual es una sorpresa. Por defecto ponemos:

• Presupuesto de coste por tarea con corte automático.
• Enrutado de modelos: modelos pequeños para clasificar y extraer, grandes solo donde el razonamiento compensa.
• Caché de recuperaciones repetidas.
• Coste por tarea resuelta como métrica principal, junto a la tasa de resolución.

Después del lanzamiento

El despliegue es donde empieza la vida real del sistema. Los modelos, las herramientas y el negocio van a seguir cambiando. Los sistemas que duran están hechos para eso: orquestación que se cambia pieza a pieza, evals que dicen qué se rompió, trazas que dicen por qué y presupuestos que lo mantienen asumible. Es también lo que permite a una empresa subir de nivel de autonomía con evidencia y no con esperanza.

Si estás diseñando un sistema multiagente, o cuidando uno que ha derivado, ese es nuestro trabajo en sistemas agénticos. Escríbenos y te diremos dónde esperamos que se rompa primero.