Llevar a los agentes a producción con el Servicio de Agente Foundry y el Framework de Agente.
Cómo un agente de preparación de ventas pasa de un código local a un despliegue alojado, con identidad definida, en un entorno aislado y monitoreado, publicado en Microsoft 365 y basado en datos empresariales.
Fuentes: Foundry Agent Service + Microsoft Agent Framework Explained
De prototipo a agente de producción
Hacer que un agente de IA funcione en una laptop es la parte fácil. El trabajo más complicado en una gran empresa es hacer que funcione de forma segura para miles de personas: asignarle una identidad, limitar lo que puede leer, registrar sus acciones y presentárselo a los usuarios dentro de las herramientas que ya tienen abiertas. Microsoft Foundry Agent Service, junto con el framework de código abierto Microsoft Agent Framework, está diseñado para cubrir esa necesidad. El primero se encarga del alojamiento con controles empresariales, posibilidades de medición y capacidad de detección, y permite utilizar agentes creados con las herramientas que prefiera. El segundo ayuda a desarrollar tanto agentes individuales como cargas de trabajo multiagente mediante orquestación.
La idea es que un agente puede desplegarse directamente desde un entorno local, ejecutarse con una identidad segura y permisos definidos, y ser monitoreado interacción por interacción, lo que permite depurarlo, mejorarlo y escalarlo sin que nadie pierda el control. Los agentes también pueden publicarse en herramientas conocidas, donde cada acción es rastreable, regulable e aislada.
La otra parte del enfoque es la implementación práctica. Los agentes resultan útiles cuando trabajan con datos empresariales reales: correos electrónicos, reuniones y sistemas operativos proporcionan información personalizada, documentos y presentaciones. Los equipos utilizan frameworks familiares para desarrollar sus soluciones, y luego gestionan el rendimiento, el costo y la calidad de todos sus agentes a medida que su número aumenta.
¿Qué dificulta el despliegue empresarial?
Construir un agente se ha vuelto mucho más fácil. Sin embargo, desplegarlo de manera segura y fiable en toda una organización no lo es tanto. Muchos de los agentes que se están desarrollando actualmente ya han superado con creces la fase piloto a pequeña escala. Algunos son experiencias de chat utilizadas por miles de empleados, mientras que otros funcionan silenciosamente en segundo plano, conectándose ocasionalmente a sistemas críticos para las operaciones.
Todos ellos necesitan las mismas bases: control de identidad y acceso, conectividad privada, y telemetría y rastreo tanto a nivel de un agente individual como de toda la flota. Unir todo esto manualmente es complicado, y ese es el problema que los servicios de Foundry están diseñados para resolver, permitiendo así que los agentes funcionen de forma segura, a gran escala y con total visibilidad. Ayuda imaginar la alternativa: un equipo que aloja su propio agente debe decidir cómo se autentica el agente, qué cuenta de servicio utiliza, a dónde van los registros, cómo los datos de un usuario permanecen separados de los de otro, y quién recibe notificaciones cuando el agente actúa de forma incorrecta. Cada una de estas respuestas representa un pequeño proyecto, y una revisión de seguridad preguntará por cada una antes de que el agente acceda a un calendario o a un registro de cliente.
El ejemplo: un agente para la preparación de reuniones de ventas
El ejemplo en ejecución es un agente que ayuda al equipo de ventas a prepararse para las reuniones con clientes. Su código ya está escrito, utilizando el Microsoft Agent Framework en Python, aunque se podría sustituir por cualquier otro framework y lenguaje. Define una buena cantidad de herramientas, algo de lógica de middleware y un flujo de trabajo, y por el momento todo funciona localmente.
La pregunta abierta es cómo llevarlo a algo seguro, escalable, conforme a normativas y protegido en toda la empresa. En Visual Studio Code, al expandir la extensión AI Toolkit se encuentra una acción para desplegarlo en agentes alojados. Esta acción empaqueta el agente tal como está escrito y lo despliega dentro de Foundry como un agente alojado. El mismo agente que funcionaba localmente ahora aparece en el portal de Foundry, y el entorno de pruebas puede llamarlo para mostrar qué aporta la capa de alojamiento.
Preguntarle qué reuniones importantes hay esta semana demuestra los patrones más recientes de los agentes. El agente funciona dentro de un entorno seguro, una microVM, donde razona, verifica el calendario y puede escribir y ejecutar código, al igual que lo hacen los agentes de programación como GitHub Copilot CLI o Claude Code.
Identidad, aislamiento y restricciones
Se producen varias acciones en el momento en que se despliega el agente, y la siguiente imagen muestra dónde aparece esa configuración de identidad y permisos en el portal.
- El agente recibe su propio ID único de Microsoft Entra. Cualquier acción que realice, como leer un calendario, puede rastrearse hasta él. Con esa identidad, puede acceder a recursos de forma autónoma bajo sus propios permisos definidos, o bien puede actuar en nombre de una persona utilizando los permisos de dicho usuario.
- Cada usuario que inicia una sesión de agente recibe una microVM segura y dedicada. Si dos vendedores hacen preguntas al mismo tiempo, cada uno cuenta con una instancia de agente separada, de modo que la información de cada sesión se lee, escribe y almacena en su propio espacio.
- Para cada interacción, el servicio verifica las políticas y restricciones definidas por la organización, que abarcan aspectos como el filtrado de contenido, la protección contra inyecciones de comandos y el uso de material protegido por derechos de autor. El control preciso de lo que puede hacer y acceder el agente proviene de la configuración que se establece automáticamente al momento del despliegue.
De vuelta en el área de juegos, el agente devuelve su respuesta. Basándose en las señales que recopiló y analizó, una cuenta de cliente, Zava DIY, resulta ser la de mayor prioridad. En este caso, el agente trabajó en nombre del usuario, con la identidad y permisos de esa persona, para revisar el calendario y identificar las cuentas que requieren atención. Dado que es necesario leer el buzón de entrada, el calendario y los almacenes de datos y archivos, contar con los controles de acceso adecuados es precisamente lo que se requiere para un sistema que cumpla con los requisitos.
Monitoreo y publicación
Otras dos necesidades empresariales provienen directamente de Foundry. La primera es la observabilidad. El portal ofrece monitoreo y seguimiento de las actividades, de modo que se puede seguir cada conversación, ver cómo el agente responde a cada pregunta y verificar el estado general del agente.
El segundo aspecto es la discoverabilidad. Una vez que un agente está en funcionamiento, aún debe llegar a las personas que lo necesitan, y a nadie le gusta crear una nueva aplicación con la esperanza de que todos encuentren el enlace y lo guarden como favorito. Si una empresa ya utiliza Microsoft 365 y Teams, un botón de publicación puede tomar cualquier agente desplegado en Foundry y registrarlo en esos servicios. De esta manera, las personas lo encuentran y lo utilizan donde ya trabajan, ya sea en una computadora de escritorio o en un teléfono fuera de la oficina. En Microsoft 365, el agente aparece en la experiencia Copilot Chat, y también está disponible en Teams.
La capa de inteligencia detrás de respuestas fundamentadas
Foundry también se integra con la capa de inteligencia unificada de Microsoft para IA, la cual mantiene a los agentes basados en el conocimiento y contexto empresarial adecuados para que sus respuestas sean relevantes. Esto va mucho más allá de lo que ofrece un servidor MCP de única fuente. Está compuesto por tres componentes.
- Work IQ proporciona contexto sobre cómo trabaja una persona: conexiones con el correo electrónico, el calendario, reuniones anteriores, chats de Teams, archivos y más.
- Fabric IQ añade contexto sobre las operaciones empresariales conectadas, como datos de ventas, registros de clientes o logística.
- Foundry IQ combina varias fuentes de conocimiento para un agente, desde datos estructurados y bases de datos hasta material no estructurado en almacenamientos en la nube; incluso las imágenes pueden ser recuperadas mediante procesos automatizados.
En la primera ejecución, solo estaba visible la búsqueda en el calendario, que corresponde a la función de Work IQ. El agente más avanzado utiliza las tres funciones.
Ejecución completa: preparación para la reunión de Zava
El mismo agente tiene acceso a las tres plataformas IQ a través de las herramientas y habilidades que se le han proporcionado. En el entorno de pruebas, una nota de los resultados anteriores del agente señala una reunión importante con Zava, por lo que la siguiente solicitud le pide que ayude a prepararse para dicha reunión.
Dentro del entorno de pruebas, hace lo que se acaba de describir: consulta Work IQ en busca de correspondencia, extrayendo correos electrónicos y conversaciones de Teams relacionadas con Zava; accede a Fabric IQ para obtener datos de uso, patrones de compra y detalles de contratos; y busca material de capacitación en ventas y marketing a través de Foundry IQ para encontrar lo más relevante para ese cliente.
El agente también cuenta con algunas habilidades basadas en el popular modelo de habilidades para agentes. Una de ellas genera presentaciones en PowerPoint y otra crea documentos informativos en Word. Devuelve dos archivos vinculados: un documento informativo en Word para el equipo interno y una presentación personalizada para usar con Zava.
- El resumen sintetiza el contexto obtenido de la capa de inteligencia, además de los datos de relaciones del sistema CRM, las comunicaciones recientes de la correspondencia del usuario, los análisis empresariales sobre el estado de salud, el uso y la medición, y los tickets de soporte del sistema de gestión de tickets. El resultado es un único documento de preparación con temas de discusión recomendados.
- La presentación se personaliza para esta interacción específica con el cliente y utiliza los colores de marca de la empresa. Combina material de Fabric IQ y Foundry IQ en puntos clave de discusión e información específica del cliente sobre actividades recientes, junto con datos de operaciones empresariales, métricas de campañas, y nuevas oportunidades y servicios que podrían impulsar aún más la colaboración.
El valor proviene de algo más que del despliegue: los agentes operan sobre la capa de inteligencia, donde acceden a datos de trabajo, datos empresariales y conocimiento organizacional en nombre de una persona, con una integración estrecha con Microsoft 365.
Cómo se construye
Para los desarrolladores que desean crear algo similar, el punto de partida es más sencillo que el ejemplo completo. La CLI para desarrolladores de Azure puede inicializar un nuevo proyecto, por ejemplo, un agente de preparación de ventas. Se admiten agentes basados en chat y siguen siendo muy populares; se puede utilizar cualquier framework, incluido LangGraph, y el servicio también soporta patrones emergentes. Las plantillas proporcionan los archivos necesarios, y a partir de ahí se puede depurar el proyecto localmente y desplegarlo. Ese es un agente sencillo creado a partir de una plantilla, con mucho espacio para personalización.
Al volver al agente avanzado se puede ver qué hay detrás de él. El código define herramientas y fuentes de conocimiento, incluidos los tres tipos de inteligencia artificial, además de otros tipos de habilidades que se pueden añadir a los patrones de agentes de programación en la actualidad. En esencia, el agente utiliza el SDK de GitHub Copilot, el cual ejecuta un bucle de agente sobre el conjunto definido de herramientas. Ese bucle realizó el razonamiento a partir de docenas de archivos, correos electrónicos, reuniones anteriores y datos operativos y de servicio, y de ahí surgieron las recomendaciones.
El Microsoft Agent Framework une todas las partes e incluye elementos como middleware. Una regla de ejemplo: si el agente de codificación intenta generar uno de esos documentos sin suficientes datos de los tres IQ, el middleware lo bloquea, ya que es casi seguro que el resultado sin esos datos fiables sea una alucinación. Este tipo de patrones son importantes al escalar una implementación empresarial, con controles de calidad que abarcan a todo el equipo de ventas además de medidas de seguridad adicionales. El beneficio total se logra cuando tanto los frameworks como los patrones se combinan y se alojan dentro del Foundry Agent Service.
Ejecutar una flota
Una vez que varios agentes están en ejecución, la siguiente cuestión es su monitoreo y gestión, lo cual es posible porque todo funciona dentro de Foundry. El portal muestra el rendimiento y el costo de toda la flota en una sola vista: el estado de los agentes y las alertas (en la demostración, todos están en buen estado y aún no hay alertas), el costo estimado, las tasas de éxito y el uso de tokens, además de detalles detallados sobre el volumen de ejecuciones de los agentes más activos. Los agentes con las mejores y peores tasas de éxito indican cuáles necesitan atención.
Todo lo necesario para pasar de la fase experimental a la producción y publicar las soluciones ante todos los usuarios finales está integrado, con una completa capacidad de observabilidad. El objetivo principal es reducir la complejidad de crear e implementar agentes de manera segura y fiable en toda la organización. Para quienes estén listos para probarlo, el primer paso es iniciar un proyecto en el portal de Foundry y explorar las muestras públicas de Microsoft para encontrar el SDK adecuado.
De todo esto se deriva un orden de trabajo práctico. Comience con un agente pequeño extraído de una plantilla y hágalo funcionar localmente. Añada herramientas y fuentes de conocimiento una por una, utilizando un middleware que impida continuar cuando falte información de referencia. Despliegue tempranamente en el entorno alojado, de modo que la identificación, el aislamiento y el rastreo se apliquen mucho antes de que lleguen los usuarios reales. Publique en las herramientas de chat que ya utilizan las personas solo después de que los registros de rastreo parezcan correctos, y mantenga la vista general de la flota activa una vez que varios agentes estén en funcionamiento, ya que es allí donde primero se manifiestan el aumento gradual de costos y la disminución de las tasas de éxito. Los equipos que siguen esta secuencia tienden a encontrar problemas mientras aún es económico solucionarlos.
Por qué el entorno local y el alojado se comportan de manera tan diferente
Vale la pena separar lo que escribió el desarrollador de lo que agrega la plataforma. Las herramientas, el middleware y el flujo de trabajo del agente de ventas son código de aplicación ordinario, y se comportan de la misma manera en una laptop que en la nube. Lo que cambia después del despliegue es todo lo relacionado con ese código: existe una identidad, las sesiones están aisladas, se evalúan políticas en cada interacción, se acumulan registros y se abre un camino para la publicación. Nada de esto requiere reescribir el agente, y por eso la demostración trata el despliegue como una sola acción en un editor y no como un proyecto de migración.
Tres preguntas resumen este enfoque, y cada una corresponde a una capa descrita anteriormente.
- ¿Quién está actuando? La identidad de Entra responde a esta pregunta, ya sea que el agente utilice sus propios permisos limitados o tome prestados los de un usuario.
- ¿Dónde tiene lugar el trabajo y quién puede verlo? Los entornos aislados de microVM por usuario mantienen separadas las sesiones, y las políticas de contenido e inyección de la organización se aplican en cada llamada.
- ¿Qué hizo y está funcionando bien? Los registros, las vistas de las conversaciones, los indicadores de estado, así como los resúmenes de costos y tasas de éxito, responden a estas preguntas, tanto por agente como para todo el conjunto de sistemas.
Límites dentro del código
Las restricciones de la plataforma no sustituyen a las restricciones incorporadas directamente en el agente. La regla de middleware que impide la generación de documentos cuando los tres indicadores de calidad no han proporcionado suficientes datos es una buena ilustración, ya que establece un estándar de calidad del que ninguna política genérica podría tener conocimiento. Un informe elaborado sin historial del CRM ni cifras de uso seguirá pareciendo impecable, y un vendedor podría asistir a una reunión con un cliente basándose en detalles inventados. Evitar esto a nivel de código, antes incluso de que se genere un archivo, es más económico que corregirlo posteriormente.
Ese mismo razonamiento explica por qué la demostración agrupa las habilidades como piezas separadas y reutilizables. Una habilidad para crear un mazo y otra para redactar un informe pueden ser probadas, versionadas y reutilizadas por otros agentes, mientras que el bucle de agente decide cuándo llamarlas. Al combinar ese bucle, el middleware del framework y la capa de alojamiento se obtienen tres puntos donde aplicar el control: cómo razona el agente, qué se le permite emitir y qué le permite hacer el entorno.
Aspectos a considerar antes de copiar este patrón
El ejemplo muestra un caso óptimo en el que todas las fuentes de datos están conectadas y los permisos están bien organizados. En la práctica, la calidad de la información proporcionada depende de la calidad de los datos del CRM, de gestión de tickets y de análisis subyacentes. Los permisos definidos con un alcance específico solo son útiles cuando realmente se han definido de esa manera, y un agente que actúa con los derechos de acceso del propio usuario puede ver todo lo que ese usuario puede ver; por lo tanto, las cuentas con permisos excesivamente amplios generan agentes con capacidades igualmente amplias. Los paneles de control de la flota son útiles para identificar a los agentes más débiles, pero aún así alguien tiene que analizar los registros y decidir si una tasa de éxito baja se debe al modelo, a una herramienta, a una fuente de datos faltante o a restricciones establecidas de forma demasiado estricta.
Leer más
- MAF 1.0, LangGraph o CrewAI? Elegir un framework de agentes en 2026 — Compare el Microsoft Agent Framework 1.0, LangGraph y CrewAI en cuanto a estado, memoria, depuración, protocolos, rutas en Azure y costos, además de un breve proceso de toma de decisiones y un patrón de implementación.
- Instantáneas de memoria del agente, habilidades, degradación y alcance de ramas — Cuatro mejoras para una capa de memoria basada en base de datos vectoriales incrustada en agentes de programación: instantáneas portátiles con función de fusión, activación de habilidades, degradación con verificaciones de conflictos y memoria con alcance por ramas.