El modelo es el núcleo. El arnés es todo lo demás.

Las cinco capas de un arnés de producción

Si el arnés importa tanto como el modelo, la pregunta obvia es qué contiene. Recorrerlo de abajo hacia arriba muestra por qué existe cada capa y qué se rompe si intentas prescindir de ella. Selecciona una capa:

El contexto no falta: está en todas partes

Lo difícil de dar a un agente el contexto correcto no es que no exista. Las empresas tienen cantidades enormes. Lo difícil es que vive en todas partes: en documentos no estructurados en SharePoint y wikis, en tablas estructuradas en OneLake y data warehouses, en aplicaciones como Outlook, Teams y Word. Ningún método de recuperación único alcanza todo eso.

El límite del RAG clásico

La respuesta estándar de los últimos dos años, el RAG clásico, nunca fue diseñada para ese problema. Es un patrón de un solo disparo: tomas la pregunta, la conviertes en embedding, buscas en un índice, devuelves los top-k resultados y se los pasas al modelo. Funciona para preguntas simples sobre un corpus pequeño y limpio. Se rompe cuando la pregunta es ambigua, el corpus es heterogéneo, la respuesta exige combinar fuentes o la primera búsqueda vuelve vacía. El agente no tiene forma de recuperarse de una mala recuperación.

Cuando el RAG no funciona bien, el agente entero no funciona bien. Un solo disparo es la forma equivocada para este problema. — Idea de Marco Casalaina, parafraseada

La solución es tratar la recuperación como algo que el sistema puede iterar, igual que un agente itera sobre una tarea: planificar la consulta, probar una fuente, evaluar el resultado, probar otra si la primera vino vacía y combinar lo encontrado. Compruébalo tú mismo:

La capa de contexto como servicio: las cuatro IQ

La respuesta de Microsoft es ofrecer la propia capa de contexto como un conjunto de servicios. Son cuatro, agrupados bajo el nombre Microsoft IQ. Cada una es un servicio headless (sin interfaz propia) que los agentes invocan a través de MCP. Y todas comparten la misma idea arquitectónica: la recuperación como subagente.

El mismo ciclo, aplicado a las herramientas

Hasta aquí hablamos de datos, pero el patrón se extiende a las herramientas. Un agente con pocas herramientas puede listarlas todas en su prompt. Uno con decenas, no: listarlas todas quema contexto en cada llamada y hace más lento al modelo mientras recorre la lista. La solución es la misma que en la recuperación agéntica: en lugar de exponer todas las herramientas, el agente busca la adecuada, la obtiene y la invoca.

Foundry lo ofrece como tool search, y es el patrón en el que también han convergido los agentes de OpenAI y de Anthropic. El mismo ciclo que trae conocimiento trae también capacidad: el agente busca lo que necesita justo cuando lo necesita, en lugar de cargarlo todo desde el principio.

Una identidad y un lugar para actuar

La recuperación le da al agente la información correcta, pero la información sola no termina una tarea. Un agente que sabe que el cliente está molesto todavía tiene que escribir el correo de disculpa y reembolsar el pedido. Para hacerlo con responsabilidad necesita dos cosas:

Guardrails en la frontera de las herramientas

La identidad acota a qué puede llegar un agente. Los guardrails acotan qué fluye a través de él cuando actúa. Un chatbot solo tenía que filtrar el prompt del usuario y la respuesta del modelo. Un agente tiene más superficie que defender, porque también lee salidas de herramientas y documentos recuperados, y cualquiera de ellos puede traer una instrucción que el usuario nunca escribió. Así funciona la inyección indirecta de prompt. Pruébalo:

La solución es mover los guardrails a la frontera de las herramientas: filtrar entradas y salidas de herramientas, no solo la entrada y salida del modelo. Foundry ejecuta sus propios clasificadores a nivel de llamada y de respuesta de herramienta, por encima de la seguridad que ya traiga el modelo. Y como esos controles viven en una capa de herramientas compartida y no dentro de cada agente, un equipo los configura una vez y todos los agentes que usan esas herramientas los heredan, en lugar de reimplementar guardrails, credenciales y políticas agente por agente.

La otra mitad: evaluar agentes en producción

El contexto es la mitad de lo que decide si un agente sobrevive a producción. La evaluación es la otra mitad. Un agente con el contexto correcto todavía puede derivar, sufrir regresiones o fallar de formas nuevas a medida que cambian los patrones de tráfico. La evaluación cierra el ciclo: te dice cuándo algo cambió y si el agente hace lo que se supone que debe hacer.

Evaluación continua, no una casilla antes de publicar

La mayoría de los equipos trata la evaluación como un trámite previo: corren las pruebas una vez, ven verde y publican. Eso sirve para el software tradicional, que es determinista. Un agente no lo es: el mismo prompt contra el mismo modelo puede producir respuestas distintas, el modelo cambia cuando el proveedor lo actualiza y los datos que recupera cambian a diario. Una suite previa captura una foto del comportamiento, no una garantía.

La evaluación continua cierra esa brecha: corre contra tráfico real, muestrea interacciones de usuarios, las puntúa con los criterios que defina el equipo y envía los resultados al mismo pipeline de observabilidad que maneja los incidentes de infraestructura. Cuando la calidad cae, el equipo se entera por el mismo sistema de alertas que lo despierta cuando un servicio se cae. Esas mismas evaluaciones pueden correr antes, como compuerta en el pipeline de despliegue.

Rúbricas: ¿funciona, o funciona bien?

La mayoría de los sistemas de evaluación usa métricas genéricas como groundedness, coherencia y finalización de tarea. Son útiles, pero tienen un techo. Como dice Casalaina, las métricas genéricas te dicen si el agente funciona; no te dicen si funciona bien. Mira el caso del agente de reservas de restaurante:

Una rúbrica es una verificación específica, atada al caso de uso, que plantea una pregunta de sí o no sobre algo que el agente debería hacer. El sistema de evaluación corre el agente contra un conjunto de interacciones de prueba, puntúa cada rúbrica por interacción y consolida los resultados. El equipo ve no solo si el agente funciona, sino qué comportamientos concretos acierta y cuáles no. Funcionan mejor que las métricas genéricas porque las escribe el equipo dueño del agente, y reflejan lo que el agente realmente debe hacer.

No hay que escribirlas desde cero: Foundry puede redactar un borrador de rúbrica leyendo la configuración del agente y sus trazas de producción, y proponer las dimensiones que vale la pena puntuar. El equipo sigue siendo dueño del resultado y lo edita, pero parte de tráfico real en vez de una página en blanco.

El ciclo que se mejora solo

Microsoft integró la evaluación por rúbricas en su suite Agent Optimizer, que además vuelve accionables las rúbricas: cuando una falla, mejora automáticamente al agente. Puede reescribir el prompt de sistema para hacer explícito el comportamiento faltante, ajustar cómo usa sus herramientas, cambiar qué fuentes prioriza, cambiar el modelo subyacente y afinar sus skills. En lugar de probar un arreglo a la vez, genera varios candidatos en paralelo, puntúa cada uno contra las rúbricas y promueve el mejor como nueva versión del agente.

La evaluación no es una fase que termina. Es una capa que corre junto al agente, con rúbricas que evolucionan con su trabajo y un optimizador que convierte las regresiones en cambios accionables. El trabajo del equipo deja de ser escribir el agente perfecto el primer día y pasa a ser mantener honesto al agente mientras el mundo a su alrededor cambia.

La lección clave, uses o no Foundry

El hilo que recorre toda la conversación es que el arnés importa tanto como el modelo. Contexto difícil, evaluación difícil, prototipos que no sobreviven: todo viene de lo mismo. El trabajo que muchos equipos consideran “alrededor del modelo” es, en realidad, lo que determina si el agente funciona. Tratar el arnés como algo que se añade después es la razón más común por la que un agente empresarial nunca llega a producción.

Según la fuente, las dos primeras ideas se pueden construir sobre cualquier plataforma.