Microsoft lleva Agentic Retrieval al edge: memoria, MCP y evaluación para datos que no salen
La actualización de julio de 2026 para Agentic Retrieval en Foundry Local mejora ingesta, memoria de conversaciones, seguridad, evaluación multivuelta y despliegues desconectados. Para builders, la decisión clave es separar la capa de conocimiento de la capa que orquesta al agente.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Microsoft actualizó en julio de 2026 la extensión de Agentic Retrieval en Foundry Local con la versión 0.9.5. El producto sigue en preview, pero el cambio tiene interés más allá de Azure: intenta empaquetar una capa de conocimiento y una capa agentic para equipos que necesitan conversar con datos privados, ejecutar tools y mantener el procesamiento cerca de la infraestructura.
Qué cambió en julio
La actualización se concentra en cuatro problemas que aparecen cuando un RAG deja de ser una demo:
- Ingesta más visible y resistente. El procesamiento escala horizontalmente, reintenta trabajos y reporta formatos no soportados en vez de descartarlos silenciosamente. También permite cancelar una ingesta y detectar duplicados o trabajos atascados.
- Memoria para conversaciones largas. La compactación automática conserva el historial completo mientras reduce el contexto activo. Es útil para conversaciones con muchas llamadas a herramientas, pero no elimina la necesidad de decidir qué estado debe persistir fuera del modelo.
- Evaluación multivuelta. La plataforma añade medición de calidad a través de varios turnos, no solo una respuesta aislada. Esto encaja mejor con agentes que deben recuperar datos, invocar un tool y corregir el rumbo.
- Operación desconectada y endurecimiento. Microsoft menciona mejoras para entornos air-gapped, manejo de secretos y tokens, parches de dependencias y despliegue con NetworkPolicy. La instalación gestiona su propio ingress y exige una CNI que aplique políticas de red.
La demanda se infiere de consultas como Agentic Retrieval, RAG on-premises, MCP local y air-gapped AI, además de la documentación de siete superficies REST y el interés creciente por correr agentes con datos sensibles fuera de la nube pública. No hay herramienta de volumen SEO conectada, así que no convierto esas señales en cifras inventadas.
La arquitectura útil es la separación de capas
La documentación describe una capa de conocimiento para ingerir, indexar y recuperar documentos, y una capa agentic para planear, mantener threads, ejecutar runs y decidir cuándo llamar herramientas MCP. Esa separación evita un error común: meter todo el contexto disponible en cada prompt y confiar en que el modelo descubra por sí solo qué información tiene permiso de usar.
En el diseño de Microsoft, la knowledge base define el límite de conocimiento disponible para el agente. Las knowledge sources pueden ser remote_mcp o indexed_sources_mcp, y el agente emparejado solo usa las fuentes que están enlazadas a esa base. Ese contrato es más importante que la marca del modelo: convierte el acceso en una configuración explícita que se puede revisar.
Hay tres modos de despliegue:
- Combined: ingesta local más orquestación agentic.
- Agentic: solo runtime de agentes, usando MCP externos, sin la capa local de ingesta.
- Knowledge: ingesta y RAG sin la capa que orquesta conversaciones.
La elección correcta depende del problema. Si ya tienes un buscador interno expuesto por MCP, el modo agentic puede evitar duplicar índices. Si necesitas aislar documentos y aplicar RBAC por colección, combined ofrece una frontera más completa. Si solo quieres búsqueda, no añadas un agente para justificar una arquitectura más grande.
Tradeoffs que un builder debe probar
El producto requiere un endpoint de modelo propio o compatible con OpenAI Chat Completions; no empaqueta un modelo. Eso te da control sobre el proveedor, pero te convierte en responsable de latencia, capacidad, actualización y compatibilidad del endpoint. Microsoft recomienda una ventana de contexto de 32K tokens para mejorar recuperación y uso de herramientas, pero la compactación no reemplaza un diseño de memoria.
También hay un límite operativo que merece atención: todas las instancias comparten actualmente el mismo endpoint LLM configurado a nivel de clúster. Para un entorno multiárea o multi-tenant, eso obliga a pensar en cuotas, identidad, aislamiento de datos y observabilidad antes de abrir acceso a más equipos.
Un piloto seguro debería medir:
- cobertura de ingesta y archivos omitidos;
- calidad de recuperación por colección y rol;
- número de llamadas MCP por run;
- latencia de compactación y tasa de reintentos;
- calidad por conversación completa, no solo por turno;
- comportamiento cuando el endpoint de modelo o una fuente MCP queda desconectada.
Si el agente maneja documentos internos, registra qué knowledge source se usó, no solo el texto final. Esa trazabilidad sirve para depurar respuestas y para demostrar que el agente no recibió acceso implícito a todo el clúster.
Para los builders que vienen empezando, el curso gratis es una base práctica para diseñar herramientas con permisos y validación antes de conectar datos reales.
La noticia no es que Microsoft haya inventado un RAG local. Es que está formalizando una frontera que muchos equipos terminan construyendo a mano: una capa de conocimiento con límites claros y una capa de agente que puede conversar, usar tools y ser evaluada sin sacar todos los datos de la infraestructura.