Azure | The .NET Blog

Microsoft Foundry Abril 2026: Foundry Local GA, GPT-5.5, CodeAct con Hyperlight

Emiliano Montesdeoca — Tue, 02 Jun 2026 00:00:00 +0000

Un mes ocupado para Microsoft Foundry. Estos son los anuncios más importantes.

Foundry Local Está Disponible de Forma General

Foundry Local — el runtime de IA local multiplataforma de Microsoft — pasa de vista previa a GA en Windows, macOS (Apple Silicon) y Linux x64. Inferencia de modelos locales lista para producción con un SDK amigable para desarrolladores. La versión 1.1 agrega soporte para transcripción, embeddings y la API Responses.

GPT-5.5

El último modelo de la familia GPT-5 ya está disponible en Foundry. Cuota predeterminada para suscripciones Tier 5 y Tier 6. Si has estado trabajando con variantes anteriores de GPT-5, vale la pena evaluarlo para tus casos de uso.

Trazado de Agent Framework en Foundry

Dos características de trazado se incluyen en vista previa este mes:

Trazado de Microsoft Agent Framework — Los agentes MAF ahora pueden emitir trazas OpenTelemetry en Foundry. Depura el comportamiento de los agentes, rastrea la ejecución de múltiples pasos, detecta latencia y errores en llamadas a herramientas. Esto llena un vacío real: saber qué hizo realmente tu agente en producción, no solo qué devolvió.

Trazado de agentes hospedados — Las sesiones, llamadas a herramientas y pasos de ejecución de los agentes hospedados también aparecen en las trazas de Foundry. La misma historia de observabilidad extendida al nivel hospedado.

CodeAct con Hyperlight (Alpha)

Esta es la adición técnicamente más interesante: Agent Framework ahora puede ejecutar código Python dentro de micro-máquinas virtuales Hyperlight.

CodeAct es el patrón donde un agente genera y ejecuta código Python como herramienta. La preocupación obvia es la seguridad: estás ejecutando código generado por el modelo. Las micro-VMs de Hyperlight proporcionan aislamiento a nivel de proceso con tiempo de inicio cercano al nativo, haciendo que la ejecución de código en sandbox sea práctica sin la sobrecarga de contenedores o VMs completos.

Para flujos de trabajo agenticos donde la ejecución de código es necesaria, esto es una mejora de seguridad significativa sobre ejecutar código en el proceso host.

Panel de Monitoreo de Agentes (Vista Previa)

Un panel de operaciones unificado que combina uso de tokens, latencia, tasa de éxito de ejecución y puntuaciones de evaluadores en una sola vista. La distinción de los paneles de observabilidad regulares: incluye resultados de evaluación junto con métricas operativas, por lo que puedes correlacionar “el agente es más lento” con “las puntuaciones del evaluador cayeron” — o confirmar que no están relacionados.

Evaluadores Personalizados de Evaluación Continua (Vista Previa)

Ahora puedes traer tus propios evaluadores basados en código o en prompts a los pipelines de evaluación continua. Anteriormente, la evaluación continua estaba limitada a evaluadores integrados. Los evaluadores personalizados te permiten hacer cumplir criterios de calidad específicos del equipo en tu bucle de monitoreo de producción.

Inventario de Agentes en el Plano de Control

La vista Operate del Plano de Control de Foundry ahora muestra todos los agentes compatibles en una suscripción: agentes de Foundry, Azure SRE Agent, bucles de agentes de Logic Apps y agentes personalizados registrados. Una vista para entender qué está desplegado y dónde.

Publicación original: What’s new in Microsoft Foundry | April 2026

Tu Agente MAF Local Acaba de Tener un Hogar en Producción

Emiliano Montesdeoca — Sat, 30 May 2026 00:00:00 +0000

Hacer que un agente funcione localmente es la parte divertida. La parte complicada es todo lo que viene después: desplegarlo sin perder la cordura, gestionar sesiones, configurar identidad, conectar la observabilidad. Normalmente eso significa mucha infraestructura personalizada de pegamento.

Foundry Hosted Agents acaba de eliminar la mayor parte de ese pegamento para los usuarios de Microsoft Agent Framework (MAF).

Lo Que Foundry Hosted Agents Realmente Hace

Cuando despliegas un agente MAF en Foundry Hosted Agents, la plataforma gestiona una lista sorprendentemente larga de cosas que de otro modo tendrías que construir tú mismo:

Escalar a cero — tu agente no cuesta nada cuando está inactivo y vuelve a arrancar automáticamente
Sandboxes aislados por VM por sesión — cada sesión de usuario obtiene su propio sandbox con persistencia del sistema de archivos que sobrevive a eventos de reducción de escala
Entra ID integrado — cada agente obtiene su propia identidad para llamar a modelos de Foundry, Toolbox y servicios Azure sin secretos dentro de la imagen
Despliegues versionados — cada despliegue es una instantánea inmutable, con soporte de despliegue blue/green y canary
Observabilidad sin configuración — APPLICATIONINSIGHTS_CONNECTION_STRING se inyecta en tiempo de ejecución para que las trazas OpenTelemetry de MAF fluyan automáticamente hacia App Insights

Ese último es genuinamente agradable. Sin cableado extra, sin configuración adicional. Las trazas simplemente aparecen.

La Diferencia en el Código Es Mínima

Esto es lo que más aprecio de esta integración. No reescribes tu agente. Solo lo envuelves:

En .NET:

using Microsoft.Agents.AI.Foundry.Hosting;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddFoundryResponses(agent);

var app = builder.Build();
app.MapFoundryResponses();

app.Run();

En Python:

server = ResponsesHostServer(agent)
server.run()

Eso es todo. La misma lógica que probaste localmente es lo que se ejecuta en producción. La plataforma la envuelve en la infraestructura de gestión de sesiones, identidad y escalado.

Dos Protocolos, Un Agente

Los Hosted Agents soportan dos estilos de endpoints:

Responses (/responses) — compatible con OpenAI, gestiona el historial de conversación y streaming. Buen valor predeterminado para agentes con forma de chat.
Invocations (/invocations) — tú defines el esquema de petición/respuesta. Bueno para flujos de trabajo no conversacionales.

Si estás construyendo algo que parece una conversación, empieza con Responses. Si estás construyendo un agente con forma de API que toma entrada estructurada y devuelve salida estructurada, Invocations te da la flexibilidad.

El Flujo de Despliegue con `azd`

Cuando ejecutas azd up con un agente MAF:

Opcionalmente crea un proyecto Foundry y despliega un modelo
Empaqueta tu código y empuja una imagen a Azure Container Registry
Aprovisiona cómputo desde la imagen ACR
Asigna un Entra ID dedicado al agente
Expone un endpoint estable (https://{project_endpoint}/agents/{agent_name})
Gestiona todo lo demás desde ese punto en adelante

Las sesiones persisten hasta 30 días. El cómputo inactivo se desaprovisiona después de 15 minutos y se restaura transparentemente en la siguiente solicitud. Desde la perspectiva del agente, nada cambió.

Conclusión

La distancia entre “funcionando localmente” y “ejecutándose en producción” ha sido históricamente larga y dolorosa para los agentes de IA. Foundry Hosted Agents + MAF cierra esa brecha significativamente. Si ya tienes un agente local construido con Agent Framework, vale la pena probarlo hoy.

El equipo dice que GA llega pronto — actualmente está en preview. Consulta los docs de integración de MAF Hosted Agent y los ejemplos de .NET para empezar.

Artículo original: From Local to Production: Deploy Your Microsoft Agent Framework Agent with Foundry Hosted Agents

Foundry Local 1.1: Transcripción en Tiempo Real, Embeddings y la API de Respuestas

Emiliano Montesdeoca — Thu, 28 May 2026 00:00:00 +0000

Foundry Local 1.0 demostró el concepto: ejecutar modelos de IA localmente en Windows, macOS (Apple Silicon) y Linux x64 con un SDK amigable para desarrolladores. La versión 1.1 añade tres capacidades que cubren muchos casos de uso reales en producción.

Transcripción de Audio en Vivo

La nueva característica más significativa: streaming de voz a texto en tiempo real directamente desde el micrófono. Subtítulos, interfaces de voz, transcripción de reuniones, herramientas de accesibilidad — todo ejecutándose localmente sin ninguna dependencia de la nube.

La API es basada en sesiones y transmite resultados a medida que llegan, con marcadores is_final para distinguir texto intermedio del finalizado. Disponible en todos los bindings de lenguajes: JavaScript, C#, Python y Rust.

Carga un modelo de voz en streaming del catálogo, crea una sesión con ajustes de audio (frecuencia de muestreo, canales, idioma), iníciala, envía fragmentos de audio PCM sin procesar y consume el stream asíncrono de resultados. El artículo tiene ejemplos completos en Python y C#.

Embeddings de Texto

Búsqueda semántica, pipelines RAG, clustering, comparación de similitudes — todo esto requiere embeddings. Foundry Local 1.1 añade soporte para modelos de embeddings para que puedas generar vectores localmente desde el mismo SDK, sin enviar datos a un endpoint en la nube.

Para aplicaciones donde la residencia de datos importa o donde procesas contenido sensible, la generación local de embeddings es una capacidad significativa.

API de Respuestas

Foundry Local ahora soporta la API de Respuestas — la interfaz estructurada diseñada para interacciones agénticas. Esto añade:

Llamada a herramientas — permite que los modelos que se ejecutan localmente invoquen herramientas que defines tú
Entrada multimodal visión-lenguaje — pasa imagen + texto a modelos capaces de visión
Compatible con la forma estándar de la API, por lo que los agentes existentes que apuntan a la API de Respuestas de OpenAI funcionan contra modelos locales

Mejoras en el Tamaño del Paquete

Dos cambios reducen el tamaño del paquete de JavaScript:

La capa FFI koffi ha sido reemplazada por un addon C de Node-API personalizado
El proveedor de ejecución WebGPU se distribuye como un plugin separado, para que las aplicaciones que no necesitan aceleración por GPU no paguen el coste de tamaño

El SDK de C# ahora apunta a versiones de framework inferiores para mayor compatibilidad con .NET.

Por Qué Esto Importa

Las tres capacidades juntas — transcripción, embeddings, llamada a herramientas — cubren los bloques de construcción fundamentales de muchas aplicaciones de IA. Ejecutarlos localmente significa:

Sin internet requerido
Sin costes por token
Sin datos que salgan de la máquina
Latencia consistente independientemente de las condiciones de red

Foundry Local es la elección correcta para escenarios en el borde, cargas de trabajo sensibles a la privacidad, aplicaciones sin conexión, o cualquier cosa donde quieras evitar la dependencia de la nube durante el desarrollo.

Post original: Foundry Local 1.1: Live Transcription, Embeddings, and Responses API

Cosmos DB Shell Está en Vista Previa Pública — Y Tiene un Servidor MCP Integrado

Emiliano Montesdeoca — Sun, 24 May 2026 00:00:00 +0000

Si alguna vez has tenido que ir y venir entre una pestaña del portal, una muestra de SDK y un script a medio terminar solo para responder una pregunta de Cosmos DB, ya conoces la fricción que este proyecto está diseñado para eliminar.

Azure Cosmos DB Shell acaba de entrar en vista previa pública. Es una CLI de código abierto con sintaxis tipo bash y — la parte que lo hace interesante — un servidor MCP integrado.

Qué lo Hace Diferente de Otras CLIs de Base de Datos

La CLI en sí es útil: comandos familiares, soporte para scripts, integración CI/CD. Esa parte es lo mínimo esperado para una herramienta de base de datos orientada a desarrolladores.

La parte interesante es la integración del servidor MCP. Cada comando que expone la CLI se convierte en una herramienta MCP que tus agentes de IA pueden llamar. No hay ninguna capa de API personalizada, ni código de integración que escribir. Tu agente puede:

Navegar por las jerarquías de bases de datos con cd, ls, pwd
Ejecutar consultas SQL con query y obtener resultados estructurados
Crear y modificar elementos con create item, update, rm
Gestionar bases de datos y contenedores con mkdb, mkcon, rmdb, rmcon
Inspeccionar el contexto actual con endpoint, pwd

El cambio clave: tu agente no está hablando con una API de Cosmos DB — está hablando con la misma interfaz de shell que usas tú. Los comandos son deterministas, auditables y de código abierto para que puedas inspeccionar exactamente qué está pasando.

La Base de Código Abierto Importa

Esto no es un servicio gestionado de caja negra. El shell es de código abierto, lo que significa:

Los equipos de seguridad pueden auditar la implementación
Los equipos de plataforma pueden hacer fork y ampliarlo para sus estándares específicos
Los desarrolladores pueden contribuir con mejoras que beneficien a todos

Para los equipos empresariales que adoptan herramientas de IA, “¿podemos ver exactamente cómo funciona?” es cada vez menos un requisito opcional. El código abierto aquí es un diferenciador significativo.

Tres Escenarios que Se Vuelven Más Fáciles

Análisis inteligente de datos — conecta un agente al shell, haz preguntas en lenguaje natural, obtén resultados de consultas estructurados. El agente se encarga de la construcción de la consulta; el shell se encarga de la ejecución.

Gestión autónoma de datos — los flujos de trabajo que necesitan crear, actualizar o eliminar datos en Cosmos DB pueden hacerlo a través de las herramientas MCP sin necesitar una integración personalizada.

Supervisión y alertas en tiempo real — un agente puede consultar contenedores periódicamente, comparar resultados y mostrar anomalías a través del canal de notificación que tenga sentido.

La interfaz MCP hace que estos escenarios sean composables con cualquier plataforma de IA que hable MCP — no solo las herramientas de Microsoft.

Para Empezar

El shell está en vista previa pública. Instálalo, configura tu conexión de Cosmos DB y habilita el servidor MCP. Desde allí, cualquier host de agente compatible con MCP puede descubrir y usar las herramientas.

Post original: Announcing the Public Preview of Azure Cosmos DB Shell: Open-Source Power Meets AI-Driven Database Automation

Tu Agente de IA Tiene un Problema de Identidad (Y Aquí Está la Plantilla que lo Resuelve)

Emiliano Montesdeoca — Wed, 20 May 2026 00:00:00 +0000

Hay un momento en cada proyecto de agente de IA que va más o menos así: la demo funciona perfectamente, el agente interpreta el lenguaje natural, llama a las API correctas, devuelve los datos correctos. Entonces empiezas a pensar en los usuarios reales.

¿Qué impide que la sesión del agente de un usuario vea los datos de otro usuario? ¿Qué pasa si el agente es engañado a través de inyección de prompts? ¿Qué pasa si llama a una herramienta de una manera inesperada?

Estos no son casos extremos. Son decisiones de diseño que debes tomar antes de lanzar.

Una nueva plantilla azd de Curity y Microsoft te da una referencia funcional para exactamente este problema.

El Problema Central: Autenticación ≠ Autorización

La mayoría de las muestras de agentes gestionan bien la autenticación de usuarios. Gestionan mal la autorización. Saber quién es el usuario no te dice qué datos debería ver.

Una aplicación cliente tradicional hace llamadas de API predecibles. Un agente de IA es no determinista — interpreta el lenguaje natural y decide a quién llamar. Puede ser creativo. También puede estar equivocado. Y si es manipulado a través de inyección de prompts, necesitas reglas que no dependan de que la IA se comporte bien.

La solución que demuestra esta plantilla: tokens de corta duración que transportan exactamente la información correcta para cada salto.

Cómo Funciona la Cadena de Tokens

La plantilla usa tokens de acceso OAuth 2.0 con intercambio de tokens para reducir los permisos en cada paso. Un token de usuario se intercambia dos veces antes de llegar al servidor MCP:

Primer intercambio — reduce el ámbito y convierte el token opaco en un JWT
Segundo intercambio — añade la identidad del agente y una nueva audiencia para el salto del servidor MCP

Cómo luce el token del servidor MCP:

{
 "scope": "stocks/read",
 "sub": "62c839b8...",
 "aud": "https://mcp.demo.example",
 "customer_id": "178",
 "region": "USA"
}

El customer_id está integrado en el token por el servidor de autorización, no se pasa como un parámetro que controla el agente. La API comprueba el token, no las instrucciones del agente.

Esto significa: incluso si alguien engaña al agente para que intente obtener los datos de otro cliente, el token no lo autorizará.

Qué Despliega la Plantilla

Con unos pocos comandos azd obtienes:

Un agente backend en Microsoft Foundry (C#, SDK de Microsoft A2A y MCP)
Un servidor MCP que expone una API de cartera de muestra
Curity Identity Server como servidor de autorización, junto con Entra ID para la autenticación
Pasarelas de API externas e internas que gestionan el intercambio de tokens y el registro de auditoría
Bicep para toda la infraestructura Azure: Container Apps, VNet, ACR, Azure AI Foundry, Key Vault, Azure SQL Database, almacenamiento

Todo el patrón es inspeccionable y personalizable.

El Principio de Diseño que Vale la Pena Adoptar

Incluso si no usas Curity, el patrón es transferible: los agentes nunca deberían tener acceso permanente a la API. Cada acción debería usar un token de corta duración con el mínimo ámbito necesario para esa llamada específica, emitido para la identidad específica del agente, llevando las afirmaciones que la API necesita para tomar decisiones de autorización.

Esto resiste agentes creativos, errores e inyección de prompts de maneras que “asegúrate de que el agente no haga cosas malas” nunca lo hará.

Conclusión

Los patrones de seguridad para agentes de IA todavía se están definiendo en toda la industria. Esta plantilla es una de las implementaciones de referencia más completas que he visto — cubre el flujo de autorización real, no solo la autenticación.

Post original: Least privilege AI agents: A new azd template from Curity and Microsoft

Endpoints Privados, VNets, NSGs — Aspire Gestiona la Red Ahora

Emiliano Montesdeoca — Tue, 19 May 2026 00:00:00 +0000

He visto este escenario demasiadas veces. La aplicación está lista. La demo es excelente. Luego aparece la lista de verificación de seguridad: saca el almacenamiento de internet público, ejecuta dentro de una VNet, proporciona IPs de salida para la lista de autorización del socio, demuestra que solo las subredes correctas hablan con los servicios correctos.

En ese punto el modelo de aplicación y el modelo de infraestructura comienzan a divergir de maneras que son dolorosas de mantener.

El nuevo soporte de redes empresariales de Azure para Aspire aborda esto directamente. Describes la forma de la red junto a los recursos que la usan, en tu AppHost.

Los Bloques de Construcción

Aquí está para qué sirve cada concepto de red de Azure, resumido:

Característica	Úsala cuando	Por qué importa
Red virtual	Necesitas un espacio de direcciones privado	El límite de red para subredes, endpoints privados y enrutamiento
Subred	Necesitas separar cargas de trabajo dentro de la VNet	Cada parte del sistema obtiene su propio rango de direcciones y superficie de política
Subred delegada	Un servicio de plataforma (como ACA) necesita gestionar una subred	Permite que el servicio coloque infraestructura gestionada en tu VNet de forma segura
Puerta de enlace NAT	Necesitas IPs públicas de salida predecibles	Dirección estable para listas de autorización y auditoría
Endpoint privado	Quieres un recurso PaaS accesible privadamente	Pone una IP privada para ese servicio dentro de tu VNet, elimina la exposición pública
NSG	Necesitas reglas de tráfico a nivel de subred	Permitir/denegar explícito para tráfico entrante y saliente por subred

Describiéndolo en tu AppHost

El cambio clave aquí es que estás modelando la red junto a los recursos que la usan, no en un archivo Bicep separado que se aleja del modelo de aplicación con el tiempo.

Desde el AppHost, puedes:

Crear VNets y subredes con AddVirtualNetwork() y AddSubnet()
Adjuntar una puerta de enlace NAT a subredes para IPs de salida estables
Crear endpoints privados para almacenamiento, Key Vault, SQL y otros servicios PaaS
Definir NSGs con reglas de seguridad de entrada y salida
Configurar Perímetros de Seguridad de Red para políticas entre recursos

El resultado es que cuando ejecutas azd up, la infraestructura coincide con lo que el modelo de aplicación dice que necesita. No lo que dice una plantilla mantenida manualmente.

Por Qué Importa para Aplicaciones Reales

Algunas cosas que se vuelven significativamente más fáciles una vez que la red se modela en Aspire:

Endpoints privados para Key Vault y almacenamiento — describes WithPrivateEndpoint() en esos recursos, y Aspire maneja la configuración de zonas DNS y el adjunto de endpoints. La aplicación nunca cambia.

IPs de salida consistentes — agrega una puerta de enlace NAT a la subred relevante y cada solicitud de salida de tu aplicación pasa por una IP conocida y estable. Los socios pueden autorizarla. Los auditores pueden rastrearla.

Reglas NSG desde el código — en lugar de hacer clic en el portal o mantener un fragmento de Bicep, tus reglas de seguridad viven en el AppHost junto a los recursos que protegen.

Este es el tipo de integración que no hace que las demos sean emocionantes pero hace que los sistemas de producción sean mantenibles.

Conclusión

La seguridad de red apareciendo tarde en el ciclo de vida del proyecto es un problema resuelto si la modelas junto con la aplicación desde el principio. El soporte de redes empresariales de Aspire hace eso posible sin requerir un seguimiento de infraestructura separado.

Detalles completos en la publicación original: Securing Azure apps with Aspire enterprise networking

Aspire 13.3: Soporte de Kubernetes, Registros del Navegador y la Habilidad Aspireify

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

Cinco semanas no es mucho tiempo para una versión, pero Aspire 13.3 no lo parece. Los elementos principales son significativos: despliegue de Kubernetes y AKS de primera clase con Helm, una habilidad de incorporación asistida por agente llamada Aspireify, captura de registros del navegador directamente en el dashboard y resultados de comandos estructurados. Además, 45 nuevas características, 134 mejoras y 93 correcciones de errores.

Vamos a los puntos destacados.

Aspireify: Incorporación Asistida por Agente

Agregar Aspire a un proyecto existente suena simple — coloca un AppHost, listo. En la práctica implica mucha arqueología: qué puertos importan, qué variables de entorno son dependencias reales, qué servicios de Docker Compose deben mapearse a integraciones de Aspire.

La nueva habilidad Aspireify le da a tu agente de código un flujo de trabajo guiado exactamente para esto. Cuando aspire init crea un AppHost esqueleto, la habilidad Aspireify ayuda al agente a inspeccionar el repositorio, entender cómo ya funciona y conectar el AppHost para adaptarse a la aplicación — no al revés.

La postura predeterminada es “minimizar los cambios en tu código.” Si tu aplicación ya lee DATABASE_URL, el agente lo mapea con WithEnvironment() en lugar de pedirte que reescribas tu configuración. Si un puerto está codificado de forma fija, la habilidad le indica al agente cuándo preservarlo.

Este es el tipo de herramientas de IA que realmente ahorran tiempo en lugar de generar más trabajo por revisar.

Despliegue de Kubernetes y AKS de Primera Clase

Esta es una que ha estado en la lista de deseos durante un tiempo. Aspire 13.3 incluye soporte de despliegue de Kubernetes y AKS de primera clase con Helm. Ahora puedes apuntar a AKS como destino de despliegue directamente desde las herramientas de Aspire.

Para los equipos que ya ejecutan cargas de trabajo de producción en AKS, esto cierra una brecha significativa. Tu modelo de aplicación de Aspire ahora tiene un camino limpio desde el desarrollo local hasta Kubernetes sin necesidad de escribir manualmente gráficos Helm.

Registros del Navegador en el Dashboard

Esta es una de esas características que parecen pequeñas hasta que estás depurando un problema de frontend.

La nueva API WithBrowserLogs() adjunta un recurso de navegador rastreado a cualquier recurso capaz de endpoints. Aspire lanza Chromium usando un pipe CDP privado y transmite registros de consola, solicitudes de red y errores directamente al flujo de registros del recurso:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

El AppHost de TypeScript admite lo mismo:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

Errores de consola, solicitudes de red fallidas, excepciones del lado del cliente — todo visible en el mismo dashboard donde ya estás observando trazas y métricas. Sin necesidad de cambiar de pestaña a las DevTools del navegador para las cosas básicas.

Resultados de Comandos Estructurados

Los comandos de recursos recibieron una mejora significativa. Hasta ahora, los comandos devolvían éxito/fracaso. Ahora devuelven resultados estructurados: texto, JSON o markdown que fluye a través del modelo, la interfaz del dashboard, la CLI y las herramientas MCP.

El dashboard une todo esto con un nuevo centro de notificaciones en el encabezado. Los resultados de los comandos aparecen como notificaciones con marca de tiempo con renderización de markdown y una acción “Ver respuesta”.

Esto hace que los comandos de recursos sean verdaderamente componibles. Una integración ahora puede exponer un comando que devuelve una salida significativa — como una URL de túnel — en lugar de simplemente cambiar el estado en algún lugar.

Conclusión

Aspire 13.3 vale la actualización aunque sea solo por el soporte de Kubernetes. Los registros del navegador y los resultados de comandos estructurados parecen el tipo de mejoras de calidad de vida que se acumulan rápidamente en el flujo de trabajo de desarrollo cotidiano.

Notas de versión completas: What’s New in Aspire 13.3

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 se celebra del 11 al 15 de mayo de 2026 en el Barbican Centre de Londres. La conferencia principal de 3 días es de martes a jueves, con talleres opcionales de día completo el lunes y el viernes.

Con 78 sesiones y 14 talleres, es una de las conferencias más completas para desarrolladores en Europa.

Temas

Pensamiento Arquitectónico
Código Funcional en C# 13
Diseño Serverless
IA Semántica
Azure Kubernetes Services
Estrategias Lean DevOps
The Model Context Protocol (MCP)
IA Agéntica en .NET
Refactorizando el Monolito
Programar Más Rápido con LLMs
Criptografía en un Mundo Post-Cuántico
Desarrollo Local First

Ponentes

Elenco de primer nivel incluyendo a Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm y Raju Gandhi.

Entradas e información

El 98% de los asistentes de SDD 2025 calificaron la experiencia general como buena, muy buena o excelente.

Eliminando el Trabajo Tedioso de la Migración con Agentic Platform Engineering

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Removing the Monkey Work of Migration with Agentic Platform Engineering — un recorrido de Git-Ape (herramienta git de ingeniería de plataformas agéntica) que migra un repositorio Terraform real de AWS a Azure, centrándose en la extracción de intención en lugar de una conversión línea por línea.

La entrada: contoso-migration

La fuente es un proyecto Terraform real (contoso-migration) que despliega una aplicación Next.js en AWS — EC2 para cómputo, ALB para balanceo de carga, S3 para artefactos y claves IAM para identidad. Costo: ~34 $/mes. El objetivo no es reproducir la misma infraestructura en Azure; es descubrir qué intenta hacer realmente el despliegue y reconstruirlo con servicios nativos de Azure.

Paso 1: Validación y autenticación

Git-Ape comienza validando todas las herramientas CLI requeridas — az, aws, gh, jq, git — y confirmando las sesiones de autenticación activas antes de tocar nada. Sin ejecuciones parciales.

Paso 2: Extracción de intención

El agente lee todo el repositorio fuente a través de la API de GitHub y extrae la intención de despliegue: tiempo de ejecución (Node.js), tipo de cómputo, patrón de ingress, manejo de artefactos, modelo de identidad, red y monitoreo. Este es el paso clave — está construyendo un modelo semántico de lo que hace el despliegue, no qué palabras clave de Terraform utiliza.

Paso 3: Mapeo de servicios

Los servicios de AWS se mapean a equivalentes de Azure:

EC2 → App Service (Linux, Node 20 LTS)
ALB → Balanceo de carga integrado de App Service
Roles/claves IAM → Managed Identity
Terraform → Bicep + GitHub Actions

Paso 4: Agente crítico

Antes de generar la salida, se ejecuta un agente crítico que detecta dos problemas bloqueantes:

Anti-patrón de build al inicio — el Terraform original ejecutaba npm install && npm run build en EC2 al arrancar. Solución: construir en CI, desplegar un artefacto listo.
Blob Storage innecesario — S3 se usaba para la preparación de artefactos que podría eliminarse con CI/CD adecuado. El agente crítico lo eliminó por completo.

Paso 5: Salida generada

El resultado son ~80 líneas de Bicep en lugar de las 200+ líneas originales de Terraform. El agente creó un nuevo repositorio GitHub con infra/main.bicep y .github/workflows/deploy.yml y eliminó todos los archivos específicos de AWS.

Comparación de postura de seguridad

La migración también produjo una mejora significativa de seguridad:

AWS original	Salida Azure
Solo HTTP	Solo HTTPS, TLS 1.2
SSH abierto a 0.0.0.0/0	Sin exposición SSH
Claves de acceso IAM	OIDC + Managed Identity
Sin monitoreo	Application Insights

Costo: ~13 $/mes vs los 34 $/mes originales.

Qué lo diferencia de un convertidor de sintaxis

El paso del agente crítico es lo que separa esto de una traducción mecánica. Detectó patrones que habrían funcionado en AWS pero serían incorrectos en Azure — y los corrigió en lugar de replicarlos. La salida no es “AWS en sintaxis de Azure”; es un despliegue nativo de Azure que logra el mismo objetivo de manera más limpia.

Consulta el recorrido completo para ver la traza completa del agente y los archivos generados.

SQL MCP Server en Azure App Service — Sin Contenedores

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Esta publicación fue traducida automáticamente. Para la versión original, haz clic aquí.

Seré honesto contigo: cada vez que veo “requiere un contenedor” en un tutorial, una pequeña parte de mí suspira. Los contenedores son geniales, hasta que tu equipo no tiene una estrategia de contenedores, y de repente una funcionalidad que parecía simple está bloqueada por una sobrecarga de orquestación que no habías planeado.

Por eso esto me llamó la atención. El SQL MCP Server ahora puede ejecutarse en Azure App Service — sin Docker, sin Kubernetes, solo la misma configuración de Data API Builder (DAB) que expone tu base de datos SQL a través de MCP, REST y GraphQL.

¿Qué es el SQL MCP Server?

Contexto rápido si aún no lo conoces. El SQL MCP Server se sitúa entre tu agente de IA y tu base de datos SQL. En lugar de darle a tu agente acceso directo a la base de datos (lo cual es terrible idea), expone tus tablas y vistas como una capa de abstracción — entidades con permisos definidos.

Está construido sobre Data API builder, lo que significa que un único archivo de configuración gestiona MCP y REST y GraphQL simultáneamente. Tu agente habla con el endpoint MCP. Tu aplicación tradicional habla con REST o GraphQL. Misma config, mismo runtime, superficies diferentes.

Eso es genuinamente útil. No estás manteniendo dos capas de API separadas.

El Problema del Contenedor (y la Solución)

El modelo de despliegue original del SQL MCP Server era con contenedores. Funciona bien en muchos equipos, pero no en todos. Muchos equipos .NET estandarizan en Azure App Service o VMs. Requerir un runtime de contenedor solo para exponer un endpoint SQL agrega fricción que nadie pidió.

El nuevo tutorial muestra cómo saltarte el contenedor por completo. Todo funciona con un comando dab start, alojado en App Service como un proceso web .NET 8 estándar.

Aquí está el flujo de configuración local en pocas palabras:

# Instalar Data API builder
dotnet tool install microsoft.dataapibuilder --prerelease -g

# Inicializar la configuración
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Agregar una entidad
dab add products --source dbo.products --permissions "authenticated:*"

# Configurar el proveedor de auth de App Service
dab configure --runtime.host.authentication.provider AppService

# Iniciar el servidor
dab start

En este punto tienes MCP en /mcp, REST y GraphQL desde el mismo proceso, y nada corriendo en un contenedor.

Autenticación Sin Claves de API Compartidas

Esta es la parte que más aprecio. Cuando despliegas en App Service, configuras Microsoft Entra ID como proveedor de autenticación. Sin secretos compartidos en archivos de configuración, sin claves de API que rotar.

La cadena de conexión permanece en una variable de entorno de App Service (no en dab-config.json), y el endpoint MCP está protegido por autenticación de plataforma. Si ya estás alineado con Entra ID en tus cargas de trabajo de Azure — lo cual probablemente sea el caso si usas agentes de Azure AI Foundry — esto encaja naturalmente.

Para el desarrollo local, cambias al modo Simulator y transporte STDIO. Vuelves al modo AppService cuando despliegas. Limpio y explícito.

Despliegue en App Service

El despliegue real es trabajo estándar con Azure CLI:

# Crear el plan de App Service
az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

# Crear la aplicación web (runtime .NET 8)
az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

# Configurar el comando de inicio
az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

Luego despliega tu proyecto DAB usando el método de despliegue que tu equipo ya usa — VS Code, GitHub Actions, Zip Deploy. El detalle clave: es un despliegue de código, no de contenedor. Sin imagen que construir, publicar ni gestionar.

Por qué Importa para los Desarrolladores .NET

Si estás construyendo agentes de IA en .NET — ya sea con el Microsoft Agent Framework, Semantic Kernel, o agentes hospedados en Azure AI Foundry — eventualmente tu agente necesita hablar con una base de datos. El SQL MCP Server te da una manera estructurada de hacer eso sin exponer cadenas de conexión en bruto ni escribir una capa de API personalizada.

Ejecutarlo en App Service cierra la brecha para equipos que no trabajan con contenedores. Es la misma configuración de DAB, la misma auth de Entra, el mismo protocolo MCP — solo en infraestructura que ya conoces.

Consulta el tutorial completo en el post original del blog y el repositorio de muestra en GitHub.

Conclusión

El SQL MCP Server en App Service es una opción pragmática sólida para equipos .NET que quieren dar a sus agentes acceso estructurado a datos SQL sin una estrategia de contenedores. La combinación del modelo de entidades de DAB, la auth integrada de Entra en App Service, y el comando de inicio dab start resulta en un despliegue simple de explicar y fácil de operar.

Pruébalo. Tus agentes apreciarán la superficie de API limpia. Tu equipo de operaciones apreciará no tener que lidiar con registros de contenedores.

SQL Server 2025 como Base de Datos Lista para Agentes: Seguridad, Backup y MCP en un Solo Motor

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

He seguido la serie Polyglot Tax de Aditya Badramraju con mucho interés. Las partes 1-3 construyeron un caso convincente para SQL Server 2025 como una base de datos genuinamente multi-modelo. La parte 4 cierra la serie con las partes que realmente determinan si confiarías en esta arquitectura en producción.

Un Modelo de Seguridad para Todos los Modelos de Datos

CREATE SECURITY POLICY TenantIsolation
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID) ON dbo.Customers,
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID) ON dbo.Events,
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID) ON dbo.Relationships,
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID) ON dbo.Embeddings
WITH (STATE = ON);

Una política, una prueba. Para un auditor que pregunta “demuestra que el Tenant A no puede ver los datos del Tenant B”, esto es oro.

Backup Unificado = Recuperación Atómica

RESTORE DATABASE MultiModelApp
FROM URL = 'https://storage.blob.core.windows.net/backups/MultiModelApp.bak'
WITH STOPAT = '2026-02-01 10:30:00';

En un stack políglota, coordinar la recuperación de cinco bases de datos es una pesadilla de consistencia. Con una sola base de datos y un log de transacciones, la recuperación es atómica por definición.

Integración MCP: Agentes Sin Middleware Codificado a Mano

SQL Server 2025 soporta el SQL MCP Server directamente. Los agentes llaman herramientas, el motor impone aislamiento de tenant y enmascaramiento de columnas automáticamente.

Resumiendo

Para desarrolladores .NET construyendo aplicaciones con agentes en Azure SQL, esta arquitectura merece consideración seria. Post original de Aditya Badramraju: The Polyglot Tax – Part 4.

Azure SDK Abril 2026: AI Foundry 2.0 y Lo Que Deben Saber los Desarrolladores .NET

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Los lanzamientos mensuales del SDK son fáciles de ignorar. Este tiene algunas cosas que vale la pena atender — especialmente si construyes con AI Foundry, Cosmos DB en Java, o haces aprovisionamiento de infraestructura desde código .NET.

Azure.AI.Projects 2.0.0 — Cambios Breaking que Tienen Sentido

El paquete NuGet Azure.AI.Projects alcanza la versión estable 2.0.0 con cambios arquitectónicos significativos:

Divisiones de namespace: Evaluaciones movidas a Azure.AI.Projects.Evaluation, operaciones de memoria a Azure.AI.Projects.Memory
Tipos renombrados: Insights → ProjectInsights, Schedules → ProjectSchedules, etc.
Convenciones de nomenclatura: Propiedades booleanas siguen consistentemente la convención Is*

Estos son los cambios breaking que duelen una vez y luego se sienten correctos para siempre.

Cosmos DB Java: Corrección Crítica de Seguridad (RCE)

Esta es seria. La biblioteca Java Cosmos DB versión 4.79.0 incluye una corrección crítica para una vulnerabilidad de Ejecución Remota de Código (CWE-502).

Si tienes servicios Java usando Azure Cosmos DB, actualiza a 4.79.0 inmediatamente.

Nuevas Bibliotecas de Provisioning para .NET

Varias bibliotecas estables de Provisioning llegan a 1.0.0:

Resumiendo

Lo más destacado para desarrolladores .NET es Azure.AI.Projects 2.0.0 alcanzando estabilidad. Post original: Azure SDK Release (April 2026).

El Azure MCP Server Ahora es un .mcpb — Instálalo sin Ningún Runtime

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

¿Sabes qué era molesto de configurar servidores MCP? Necesitabas un runtime. Node.js para la versión npm, Python para pip/uvx, .NET SDK para la variante dotnet, Docker si querías contenedores. Solo para conectar una herramienta a tu cliente IA.

El Azure MCP Server acaba de cambiar eso. Ahora está disponible como .mcpb — un MCP Bundle — y la configuración es arrastrar y soltar.

¿Qué es un MCP Bundle?

Piénsalo como una extensión de VS Code (.vsix) o una extensión de navegador (.crx), pero para servidores MCP. Un archivo .mcpb es un archivo ZIP autónomo que incluye el binario del servidor y todas sus dependencias. Todo lo necesario para ejecutarlo en tu plataforma, empaquetado junto.

El resultado: descargas un archivo, lo abres en un cliente compatible y el servidor funciona. Sin runtime que instalar, sin package.json que gestionar, sin conflictos de versiones.

Cómo instalarlo

1. Descarga el bundle para tu plataforma

Ve a la página de GitHub Releases y descarga el archivo .mcpb para tu OS y arquitectura. Asegúrate de elegir el correcto — osx-arm64 para Apple Silicon, osx-x64 para Mac Intel, etc.

2. Instala en Claude Desktop

La forma más fácil: arrastra y suelta el archivo .mcpb en la ventana de Claude Desktop mientras estás en la página de configuración de Extensiones (☰ → Archivo → Configuración → Extensiones). Revisa los detalles del servidor, haz clic en Instalar y confirma.

3. Autentícate en Azure

az login

Eso es todo. El Azure MCP Server usa tus credenciales de Azure existentes.

Qué puedes hacer con él

Una vez instalado, tienes acceso a más de 100 herramientas de servicios Azure directamente desde tu cliente IA:

Consultar y administrar Cosmos DB, Storage, Key Vault, App Service, Foundry
Generar comandos az CLI para cualquier tarea
Crear plantillas Bicep y Terraform
Obtener recomendaciones de arquitectura y diagnósticos

Prueba prompts como:

“Lista todos los grupos de recursos en mi suscripción”
“Genera una plantilla Bicep para una app web con base de datos SQL”

¿Qué método de instalación usar?

Método	Ideal para
`.mcpb`	Usuarios de Claude Desktop que quieren cero configuración
Extensión VS Code	Desarrolladores en VS Code + GitHub Copilot
npm/npx	Desarrolladores que ya tienen Node.js
Docker	Pipelines CI/CD y contenedores

Para empezar

Descarga: GitHub Releases
Repositorio: aka.ms/azmcp
Docs: aka.ms/azmcp/docs

Consulta el post completo para consejos de solución de problemas.

GPT-5.5 Ya Está Aquí en Azure Foundry — Lo que los Desarrolladores .NET Necesitan Saber

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Microsoft acaba de anunciar que GPT-5.5 ya está disponible en Microsoft Foundry. Si has estado construyendo agentes en Azure, esta es la actualización que esperabas.

La progresión de GPT-5

No es solo un incremento de versión:

GPT-5: unificó razonamiento y velocidad en un solo sistema
GPT-5.4: razonamiento multi-paso más robusto, capacidades agénticas tempranas para empresas
GPT-5.5: razonamiento de largo contexto más profundo, ejecución agéntica más fiable, mayor eficiencia de tokens

Qué cambió realmente

Mejor codificación agéntica: GPT-5.5 mantiene el contexto a través de grandes bases de código, diagnostica fallos arquitectónicos y anticipa requisitos de pruebas. El modelo razona sobre qué más afecta una corrección antes de actuar.

Eficiencia de tokens: Salidas de mayor calidad con menos tokens y menos reintentos. Esto se traduce directamente en menor costo y latencia en producción.

Análisis de largo contexto: Maneja documentos extensos, bases de código y historiales multi-sesión sin perder el hilo.

Precios

Modelo	Entrada ($/M tokens)	Entrada en caché	Salida ($/M tokens)
GPT-5.5	$5.00	$0.50	$30.00
GPT-5.5 Pro	$30.00	$3.00	$180.00

Por qué importa Foundry

Foundry Agent Service permite definir agentes en YAML o conectarlos con Microsoft Agent Framework, GitHub Copilot SDK, LangGraph o el SDK de OpenAI Agents — y ejecutarlos como agentes hospedados aislados con sistema de archivos persistente, identidad de Microsoft Entra y precios de escala a cero.

Cómo empezar

// C# — solo actualiza el nombre del modelo
AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "Eres un asistente útil.", name: "MiAgente");

Consulta el anuncio completo para los detalles completos.

Foundry Toolboxes: Un único endpoint para todas las herramientas de tus agentes

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Esta publicación fue traducida automáticamente. Para la versión original, haz clic aquí.

Aquí hay un problema que parece aburrido hasta que lo sufres en carne propia: tu organización está construyendo múltiples agentes de IA, cada uno necesita herramientas, y cada equipo las conecta desde cero. La misma integración de búsqueda web, la misma config de Azure AI Search, la misma conexión al servidor MCP de GitHub — pero en otro repositorio, por otro equipo, con otras credenciales y sin ninguna gobernanza compartida.

Microsoft Foundry acaba de lanzar Toolboxes en preview pública, y es una respuesta directa a ese problema.

¿Qué es un Toolbox?

Un Toolbox es un bundle de herramientas con nombre, reutilizable, que defines una vez en Foundry y expones a través de un único endpoint compatible con MCP. Cualquier runtime de agente que hable MCP puede consumirlo — no estás bloqueado en Foundry Agents.

La propuesta es simple: build once, consume anywhere. Define las herramientas, configura la autenticación de forma centralizada (OAuth passthrough, identidad administrada de Entra), publica el endpoint. Cada agente que necesite esas herramientas se conecta al endpoint y las obtiene todas.

Sin configuración por herramienta. Sin gestión de credenciales por agente.

Los cuatro pilares (dos disponibles hoy)

Pilar	Estado	Qué hace
Discover	Próximamente	Encuentra herramientas aprobadas sin buscar manualmente
Build	Disponible hoy	Agrupa herramientas en un bundle reutilizable
Consume	Disponible hoy	Un único endpoint MCP expone todas las herramientas
Govern	Próximamente	Auth centralizada + observabilidad en todas las llamadas

Hoy el foco está en Build y Consume. Suficiente para eliminar la fricción más inmediata.

Empezando en la práctica

El SDK es Python primero por ahora. Comienzas creando un AIProjectClient y luego construyes un toolbox:

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

Luego creas una versión del toolbox con las herramientas que quieres agrupar:

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Buscar en documentación y responder a issues de GitHub.",
 tools=[
 {"type": "web_search", "description": "Buscar documentación pública"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Una vez publicado, Foundry te da un endpoint unificado que cualquier runtime MCP puede consumir. Un punto de conexión, todas las herramientas.

No estás bloqueado en Foundry Agents

Los Toolboxes se crean y gestionan en Foundry, pero la superficie de consumo es el protocolo MCP abierto. Puedes usarlos desde agentes personalizados con Microsoft Agent Framework o LangGraph, GitHub Copilot y otros IDEs compatibles con MCP, o cualquier runtime que hable MCP.

Por qué importa ahora

La ola de multi-agentes está llegando a producción. Los equipos están construyendo 5, 10, 20 agentes — y el problema de la configuración de herramientas escala rápido. Cada nuevo agente es una nueva superficie para configuración duplicada, credenciales desactualizadas y comportamiento inconsistente.

Los Toolboxes no resuelven la gobernanza y el discovery todavía (esos pilares están por venir), pero la base de Build + Consume es suficiente para empezar a centralizar. Cuando llegue el pilar Govern, tendrás una capa de herramientas observable y controlada centralmente para toda tu flota de agentes.

Conclusión

Esto es pronto — preview pública, SDK Python primero, con Discover y Govern todavía por llegar. Pero el modelo es sólido, y el diseño nativo de MCP significa que funciona con las herramientas que ya estás construyendo. Echa un vistazo al anuncio oficial para empezar.

azd + GitHub Copilot: Configuración de proyectos con IA y resolución inteligente de errores

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

¿Conoces ese momento en que quieres desplegar una app existente en Azure y te quedas mirando un azure.yaml en blanco, intentando recordar si tu API Express debería usar Container Apps o App Service? Ese momento acaba de volverse mucho más corto.

El Azure Developer CLI (azd) ahora se integra con GitHub Copilot de dos formas muy concretas: scaffolding asistido por IA durante azd init, y resolución inteligente de errores cuando los despliegues fallan. Ambas funciones se quedan completamente en tu terminal, que es exactamente donde quiero que estén.

Configuración con Copilot durante azd init

Cuando ejecutas azd init, ahora aparece la opción “Set up with GitHub Copilot (Preview)”. Selecciónala y Copilot analiza tu codebase para generar el azure.yaml, las plantillas de infraestructura y los módulos Bicep — basándose en tu código real, no en suposiciones.

azd init
# Selecciona: "Set up with GitHub Copilot (Preview)"

Para que funcione necesitas:

azd 1.23.11 o superior — comprueba con azd version o actualiza con azd update
Una suscripción activa de GitHub Copilot (Individual, Business o Enterprise)
GitHub CLI (gh) — azd pedirá login si es necesario

Lo que me parece genuinamente útil es que funciona en los dos sentidos. ¿Construyendo desde cero? Copilot te ayuda a configurar los servicios Azure correctos desde el principio. ¿Tienes una app existente que llevas tiempo sin desplegar? Apunta Copilot hacia ella y genera la configuración sin que tengas que reestructurar nada.

Lo que hace realmente

Imagina que tienes una API Express en Node.js con dependencia de PostgreSQL. En lugar de decidir manualmente entre Container Apps o App Service, y luego escribir Bicep desde cero, Copilot detecta tu stack y genera:

Un azure.yaml con los ajustes correctos de language, host y build
Un módulo Bicep para Azure Container Apps
Un módulo Bicep para Azure Database for PostgreSQL

Y hace comprobaciones previas antes de tocar nada — verifica que tu directorio git esté limpio, pide consentimiento para las herramientas del servidor MCP. Nada ocurre sin que sepas exactamente qué va a cambiar.

Resolución de errores potenciada por Copilot

Los errores de despliegue son inevitables. Parámetros faltantes, problemas de permisos, disponibilidad de SKUs — y el mensaje de error raramente te dice lo único que realmente necesitas saber: cómo solucionarlo.

Sin Copilot, el ciclo es: copiar el error → buscar en docs → leer tres respuestas irrelevantes de Stack Overflow → ejecutar algunos comandos az CLI → volver a intentarlo y rezar. Con Copilot integrado en azd, ese ciclo se colapsa. Cuando cualquier comando azd falla, ofrece inmediatamente cuatro opciones:

Explain — descripción en lenguaje natural de qué salió mal
Guidance — instrucciones paso a paso para solucionarlo
Diagnose and Guide — análisis completo + Copilot aplica la solución (con tu aprobación) + reintento opcional
Skip — gestionarlo tú mismo

Lo clave: Copilot ya tiene contexto sobre tu proyecto, el comando que falló y la salida del error. Sus sugerencias son específicas para tu situación, no documentación genérica.

Ejemplos reales donde brilla

Proveedor de recursos no registrado:

ERROR: deployment failed: MissingSubscriptionRegistration:
The subscription is not registered to use namespace 'Microsoft.App'.

Esto falla a cualquiera que despliega en una suscripción nueva. Copilot puede registrar el proveedor y relanzar el despliegue automáticamente.

SKU no disponible:

ERROR: deployment failed: SkuNotAvailable:
The requested VM size 'Standard_D2s_v3' is not available in location 'westus'.

Copilot explica qué tamaño de VM o región está bloqueado y sugiere alternativas disponibles en tu suscripción.

Colisión de nombre de cuenta de almacenamiento:

ERROR: deployment failed: StorageAccountAlreadyTaken:
The storage account named 'myappstorage' is already taken.

La unicidad global le pasa a todo el mundo al menos una vez. Copilot sugiere añadir el nombre del entorno o un sufijo aleatorio a tus parámetros Bicep.

Configurar un comportamiento predeterminado

Si siempre quieres la misma opción, salta el prompt interactivo:

azd config set copilot.errorHandling.category troubleshoot

Opciones: explain, guidance, troubleshoot, fix, skip. También puedes habilitar auto-fix y reintento:

azd config set copilot.errorHandling.fix allow

Vuelve al modo interactivo en cualquier momento:

azd config unset copilot.errorHandling.category

Por qué importa esto para los desarrolladores .NET

Si estás construyendo en Azure — ya sea una app .NET Aspire, una API en contenedor, o cualquier otra cosa — azd es la herramienta que debes conocer. Esta integración con Copilot elimina la última barrera de fricción que antes hacía que necesitaras una chuleta para empezar.

La pieza de scaffolding es genial para proyectos brownfield. Tienes una app ASP.NET Core funcionando localmente perfectamente, pero llevarla a Azure siempre ha requerido algo de conocimiento de infraestructura. Ahora Copilot tiende ese puente. Y la función de resolución de errores es algo que desearía haber tenido la última vez que pasé 45 minutos depurando un error SkuNotAvailable en tres regiones diferentes.

Conclusión

Esta es exactamente el tipo de integración de Copilot que aporta valor real — no IA por el gusto de la IA, sino IA que entiende tu contexto y te ahorra tiempo real. Pruébalo ejecutando azd update para obtener la última versión, y usa azd init en tu próximo proyecto. El equipo está trabajando en funciones más profundas incluyendo personalización de infraestructura asistida por Copilot, así que ahora es un buen momento para apuntarte a la investigación de usuarios.

Lee el anuncio original aquí.

El RFT de Foundry ahora es más barato e inteligente — Esto es lo que cambió

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

Si estás desarrollando aplicaciones .NET que dependen de modelos fine-tuneados, las actualizaciones de Foundry de este mes merecen tu atención. El Reinforcement Fine-Tuning ahora es más accesible y significativamente más barato.

Los detalles completos están en el anuncio oficial, pero aquí va el resumen práctico.

Entrenamiento Global para o4-mini

o4-mini es el modelo preferido para cargas de trabajo pesadas en razonamiento y agentes. La gran noticia: ahora puedes lanzar trabajos de fine-tuning desde más de 13 regiones de Azure con tarifas de entrenamiento por token más bajas en comparación con el entrenamiento Standard. Misma infraestructura, misma calidad, mayor alcance.

Si tu equipo está distribuido geográficamente, esto importa. Ya no estás limitado a un puñado de regiones para entrenar.

Aquí está la llamada a la API REST para iniciar un trabajo de entrenamiento global:

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

Ese flag trainingType: globalstandard es la diferencia clave.

Nuevos Evaluadores de Modelo: Familia GPT-4.1

Los evaluadores definen la señal de recompensa contra la cual tu modelo optimiza. Hasta ahora, los evaluadores basados en modelo estaban limitados a un conjunto más pequeño de modelos. Ahora tienes tres nuevas opciones: GPT-4.1, GPT-4.1-mini y GPT-4.1-nano.

¿Cuándo deberías usar evaluadores de modelo en lugar de determinísticos? Cuando la salida de tu tarea es abierta, cuando necesitas puntuación parcial en múltiples dimensiones, o cuando estás construyendo flujos de trabajo con agentes donde la corrección de las llamadas a herramientas depende del contexto semántico.

La cuestión es que la estrategia de niveles es práctica:

GPT-4.1-nano para iteraciones iniciales. Bajo costo, ciclos de retroalimentación rápidos.
GPT-4.1-mini una vez que tu rúbrica de evaluación sea estable y necesites mayor fidelidad.
GPT-4.1 para evaluación en producción o rúbricas complejas donde cada decisión de puntuación cuenta.

Incluso puedes mezclar tipos de evaluadores en un solo trabajo de RFT. Usa string-match para la dimensión de “respuesta correcta” y un evaluador de modelo para evaluar la calidad del razonamiento. Esa flexibilidad es honestamente lo que lo hace útil para cargas de trabajo reales.

El Problema del Formato de Datos de RFT

Esto confunde a mucha gente. El formato de datos de RFT es diferente al de SFT. El último mensaje en cada fila debe tener rol User o Developer — no Assistant. La respuesta esperada va en una clave de nivel superior como reference_answer que el evaluador referencia directamente.

Si has estado haciendo supervised fine-tuning y quieres cambiar a RFT, necesitas reestructurar tus datos de entrenamiento. No te saltes este paso o tus trabajos fallarán silenciosamente.

Por Qué Esto Importa para Desarrolladores .NET

Si estás llamando modelos fine-tuneados desde tus aplicaciones .NET a través del SDK de Azure OpenAI, un entrenamiento más barato significa que puedes iterar de forma más agresiva. Las opciones de evaluadores de modelo significan que puedes hacer fine-tuning para tareas con matices — no solo escenarios de coincidencia exacta. Y la guía de mejores prácticas en GitHub te ahorrará tiempo real de depuración.

Empieza pequeño. De diez a cien muestras. Evaluador simple. Valida el ciclo. Luego escala.

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 se celebra el 18 de abril de 2026 en Kinépolis Diversia en Alcobendas, Madrid. Es el mayor evento de la comunidad Azure en España, reuniendo a 38 ponentes en 3 tracks paralelos que cubren agentes de IA, networking en Azure, Cosmos DB, Fabric, IoT, seguridad y mucho más.

El evento transcurre de 08:30 a 18:30 e incluye keynote, pausas para café, almuerzo y una sesión de cierre con preguntas.

Puntos destacados de la agenda

Domando Agentes de IA: gobernanza, herramientas y APIs con Azure AI Foundry y Azure API Management
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: sistemas multi-agente en acción
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Entradas

La inscripción es una donación simbólica — el precio completo de la entrada se destina directamente a Plan International, apoyando los derechos de los niños y la igualdad en todo el mundo. Aforo limitado, así que reserva tu plaza pronto.

Azure Tour 2026

Además de Madrid, el Global Azure Tour 2026 también incluye paradas en Zaragoza, Tenerife y Sevilla.

Tus experimentos de IA en Azure están quemando dinero — Así es como solucionarlo

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

Si estás construyendo aplicaciones con IA en Azure ahora mismo, probablemente hayas notado algo: tu factura de la nube se ve diferente a como solía ser. No solo más alta — más rara. Con picos. Difícil de predecir.

Microsoft acaba de publicar un excelente artículo sobre principios de optimización de costos en la nube que siguen importando, y honestamente, el momento no podría ser mejor. Porque las cargas de trabajo de IA han cambiado las reglas del juego en cuanto a costos.

Por qué las cargas de trabajo de IA pegan diferente

La cosa es esta. Las cargas de trabajo tradicionales de .NET son relativamente predecibles. Conoces tu nivel de App Service, conoces tus DTUs de SQL, puedes estimar el gasto mensual con bastante precisión. ¿Cargas de trabajo de IA? No tanto.

Estás probando múltiples modelos para ver cuál encaja. Estás levantando infraestructura con GPU para fine-tuning. Estás haciendo llamadas a la API de Azure OpenAI donde el consumo de tokens varía enormemente dependiendo de la longitud del prompt y el comportamiento del usuario. Cada experimento cuesta dinero real, y podrías ejecutar docenas antes de dar con el enfoque correcto.

Esa imprevisibilidad es lo que hace que la optimización de costos sea crítica — no como algo secundario, sino desde el día uno.

Gestión vs. optimización — conoce la diferencia

Una distinción del artículo que creo que los desarrolladores pasan por alto: hay una diferencia entre gestión de costos y optimización de costos.

La gestión es seguimiento y reportes. Configuras presupuestos en Azure Cost Management, recibes alertas, ves dashboards. Eso es lo básico.

La optimización es donde realmente tomas decisiones. ¿Realmente necesitas ese tier S3, o el S1 manejaría tu carga? ¿Esa instancia de compute siempre encendida está ociosa los fines de semana? ¿Podrías usar instancias spot para tus trabajos de entrenamiento?

Como desarrolladores .NET, tendemos a enfocarnos en el código y dejar las decisiones de infraestructura al “equipo de operaciones”. Pero si estás desplegando en Azure, esas decisiones también son tus decisiones.

Qué es lo que realmente funciona

Basándome en el artículo y en mi propia experiencia, esto es lo que marca la diferencia:

Sabe qué estás gastando y dónde. Etiqueta tus recursos. En serio. Si no puedes distinguir qué proyecto o experimento se está comiendo tu presupuesto, no puedes optimizar nada. Azure Cost Management con etiquetado adecuado es tu mejor aliado.

Establece límites antes de experimentar. Usa Azure Policy para restringir SKUs costosos en entornos de dev/test. Establece límites de gasto en tus despliegues de Azure OpenAI. No esperes a que llegue la factura para darte cuenta de que alguien dejó un clúster de GPU corriendo todo el fin de semana.

Ajusta el tamaño continuamente. ¿Esa VM que elegiste durante el prototipado? Probablemente no sea la correcta para producción. Azure Advisor te da recomendaciones — realmente míralas. Revisa mensualmente, no anualmente.

Piensa en el ciclo de vida. Los recursos de desarrollo deberían apagarse. Los entornos de prueba no necesitan correr 24/7. Usa políticas de apagado automático. Para cargas de trabajo de IA específicamente, considera opciones serverless donde pagas por ejecución en lugar de mantener el compute encendido.

Mide el valor, no solo el costo. Esta es fácil de olvidar. Un modelo que cuesta más pero entrega resultados significativamente mejores podría ser la decisión correcta. El objetivo no es gastar lo menos posible — es gastar inteligentemente.

La conclusión

La optimización de costos en la nube no es una limpieza de una sola vez. Es un hábito. Y con las cargas de trabajo de IA haciendo que el gasto sea menos predecible que nunca, construir ese hábito temprano te ahorra sorpresas dolorosas más adelante.

Si eres un desarrollador .NET construyendo sobre Azure, empieza a tratar tu factura de la nube como tratas tu código — revísala regularmente, refactoriza cuando se ponga desordenada, y nunca despliegues sin entender lo que te va a costar.

Las herramientas Azure MCP ahora vienen integradas en Visual Studio 2022 — Sin extensión necesaria

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

Si has estado usando las herramientas Azure MCP en Visual Studio a través de la extensión separada, ya conoces el proceso — instalar el VSIX, reiniciar, cruzar los dedos para que no se rompa, gestionar incompatibilidades de versiones. Esa fricción se acabó.

Yun Jung Choi anunció que las herramientas Azure MCP ahora se incluyen directamente como parte de la carga de trabajo de desarrollo Azure en Visual Studio 2022. Sin extensión. Sin VSIX. Sin el baile de reiniciar.

Qué significa esto realmente

A partir de Visual Studio 2022 versión 17.14.30, el Azure MCP Server viene incluido con la carga de trabajo de desarrollo Azure. Si ya tienes esa carga de trabajo instalada, solo necesitas activarlo en GitHub Copilot Chat y listo.

Más de 230 herramientas en 45 servicios de Azure — accesibles directamente desde la ventana de chat. Lista tus cuentas de almacenamiento, despliega una app ASP.NET Core, diagnostica problemas en App Service, consulta Log Analytics — todo sin abrir una pestaña del navegador.

Por qué esto importa más de lo que parece

La cosa con las herramientas de desarrollo es esta: cada paso extra es fricción, y la fricción mata la adopción. Tener MCP como extensión separada significaba incompatibilidades de versiones, fallos en la instalación, y una cosa más que mantener actualizada. Integrarlo en la carga de trabajo significa:

Una sola vía de actualización a través del Visual Studio Installer
Sin desviaciones de versión entre la extensión y el IDE
Siempre actualizado — el MCP Server se actualiza con las versiones regulares de VS

Para equipos que estandarizan en Azure, esto es muy importante. Instalas la carga de trabajo una vez, activas las herramientas, y están ahí para cada sesión.

Qué puedes hacer con esto

Las herramientas cubren todo el ciclo de vida del desarrollo a través de Copilot Chat:

Aprender — pregunta sobre servicios de Azure, buenas prácticas, patrones de arquitectura
Diseñar y desarrollar — obtén recomendaciones de servicios, configura el código de tu aplicación
Desplegar — aprovisiona recursos y despliega directamente desde el IDE
Solucionar problemas — consulta logs, verifica el estado de los recursos, diagnostica problemas en producción

Un ejemplo rápido — escribe esto en Copilot Chat:

List my storage accounts in my current subscription.

Copilot llama a las herramientas Azure MCP detrás de escena, consulta tus suscripciones, y devuelve una lista formateada con nombres, ubicaciones y SKUs. Sin necesidad del portal.

Cómo activarlo

Actualiza a Visual Studio 2022 17.14.30 o superior
Asegúrate de tener instalada la carga de trabajo Azure development
Abre GitHub Copilot Chat
Haz clic en el botón Select tools (el icono de las dos llaves)
Activa Azure MCP Server

Eso es todo. Se mantiene activado entre sesiones.

Una advertencia

Las herramientas están desactivadas por defecto — necesitas activarlas manualmente. Y las herramientas específicas de VS 2026 no están disponibles en VS 2022. La disponibilidad de herramientas también depende de los permisos de tu suscripción de Azure, igual que en el portal.

El panorama general

Esto es parte de una tendencia clara: MCP se está convirtiendo en el estándar para exponer herramientas de la nube en los IDEs de desarrollo. Ya hemos visto el lanzamiento estable de Azure MCP Server 2.0 e integraciones de MCP en VS Code y otros editores. Tenerlo integrado en el sistema de cargas de trabajo de Visual Studio es la progresión natural.

Para los que somos desarrolladores .NET y vivimos en Visual Studio, esto elimina una razón más para cambiar de contexto al portal de Azure. Y sinceramente, mientras menos cambio de pestañas, mejor.

¿Dónde deberías alojar tus agentes de IA en Azure? Una guía práctica de decisión

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Si estás construyendo agentes de IA con .NET ahora mismo, probablemente hayas notado algo: hay muchas formas de alojarlos en Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — y todos suenan razonables hasta que realmente necesitas elegir uno. Microsoft acaba de publicar una guía completa sobre alojamiento de agentes IA en Azure que aclara esto, y quiero desglosarlo desde la perspectiva práctica de un desarrollador .NET.

Las seis opciones de un vistazo

Así es como yo resumiría el panorama:

Opción	Ideal para	Tú gestionas
Container Apps	Control total de contenedores sin complejidad K8s	Observabilidad, estado, ciclo de vida
AKS	Cumplimiento empresarial, multi-clúster, redes personalizadas	Todo (ese es el punto)
Azure Functions	Tareas de agentes cortas y dirigidas por eventos	Casi nada — serverless puro
App Service	Agentes HTTP simples, tráfico predecible	Despliegue, configuración de escalado
Foundry Agents	Agentes sin código vía portal/SDK	Casi nada
Foundry Hosted Agents	Agentes con framework personalizado e infra gestionada	Solo tu código de agente

Las primeras cuatro son computación de propósito general — puedes ejecutar agentes en ellas, pero no fueron diseñadas para eso. Las dos últimas son nativas de agentes: entienden conversaciones, llamadas a herramientas y ciclos de vida de agentes como conceptos de primera clase.

Foundry Hosted Agents — el punto ideal para desarrolladores .NET de agentes

Esto es lo que me llamó la atención. Foundry Hosted Agents se sitúan justo en el medio: obtienes la flexibilidad de ejecutar tu propio código (Semantic Kernel, Agent Framework, LangGraph — lo que sea) pero la plataforma gestiona infraestructura, observabilidad y gestión de conversaciones.

La pieza clave es el Hosting Adapter — una capa de abstracción fina que conecta tu framework de agentes con la plataforma Foundry. Para Microsoft Agent Framework, se ve así:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

Esa es toda tu historia de hosting. El adapter gestiona traducción de protocolos, streaming vía server-sent events, historial de conversación y trazado OpenTelemetry — todo automáticamente. Sin middleware personalizado, sin plomería manual.

Desplegar es genuinamente simple

He desplegado agentes en Container Apps antes y funciona, pero terminas escribiendo mucho código de pegamento para gestión de estado y observabilidad. Con Hosted Agents y azd, el despliegue es:

# Instalar la extensión de agente IA
azd ext install azure.ai.agents

# Inicializar desde una plantilla
azd ai agent init

# Construir, subir, desplegar — listo
azd up

Ese único azd up construye tu contenedor, lo sube a ACR, provisiona el proyecto Foundry, despliega endpoints de modelo e inicia tu agente. Cinco pasos colapsados en un solo comando.

Gestión de conversaciones integrada

Esta es la parte que ahorra más tiempo en producción. En lugar de construir tu propio almacén de estado de conversación, Hosted Agents lo gestionan nativamente:

# Crear una conversación persistente
conversation = openai_client.conversations.create()

# Primer turno
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Segundo turno — el contexto se preserva
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Sin Redis. Sin almacén de sesiones Cosmos DB. Sin middleware personalizado para serialización de mensajes. La plataforma simplemente lo gestiona.

Mi framework de decisión

Después de revisar las seis opciones, aquí está mi modelo mental rápido:

¿Necesitas cero infraestructura? → Foundry Agents (portal/SDK, sin contenedores)
¿Tienes código de agente personalizado pero quieres hosting gestionado? → Foundry Hosted Agents
¿Necesitas tareas de agente cortas dirigidas por eventos? → Azure Functions
¿Necesitas máximo control de contenedores sin K8s? → Container Apps
¿Necesitas cumplimiento estricto y multi-clúster? → AKS
¿Tienes un agente HTTP simple con tráfico predecible? → App Service

Para la mayoría de desarrolladores .NET que construyen con Semantic Kernel o Microsoft Agent Framework, Hosted Agents es probablemente el punto de partida correcto. Obtienes scale-to-zero, OpenTelemetry integrado, gestión de conversaciones y flexibilidad de framework — sin gestionar Kubernetes ni montar tu propia pila de observabilidad.

Para terminar

El panorama de alojamiento de agentes en Azure está madurando rápido. Si estás empezando un nuevo proyecto de agente IA hoy, consideraría seriamente Foundry Hosted Agents antes de recurrir a Container Apps o AKS por costumbre. La infraestructura gestionada ahorra tiempo real, y el patrón de hosting adapter te permite mantener tu elección de framework.

Echa un vistazo a la guía completa de Microsoft y al repositorio de ejemplos de Foundry para ejemplos funcionales.

Aspire 13.2 incorpora MongoDB EF Core y Azure Data Lake — Dos integraciones que vale la pena probar

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Aspire 13.2 acaba de llegar con dos nuevas integraciones de bases de datos que merecen tu atención: MongoDB Entity Framework Core y Azure Data Lake Storage. Si querías usar EF Core con MongoDB en una app de Aspire, o necesitabas conectar cargas de trabajo de data lake con service discovery, esta versión trae ambas cosas.

MongoDB se encuentra con EF Core en Aspire

Esta es la que más me entusiasma. Aspire ha soportado MongoDB desde hace tiempo, pero siempre fue con el driver directo — sin EF Core, sin DbContext, sin consultas LINQ contra tus documentos. Ahora tienes la experiencia completa de EF Core con MongoDB, además de los health checks automáticos y el service discovery de Aspire.

Configurarlo sigue el patrón típico de Aspire. En tu AppHost:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

Luego en tu proyecto consumidor, añade la integración de EF Core:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

Y registra tu DbContext:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

A partir de ahí, es EF Core estándar. Define tus entidades, usa tu DbContext como lo harías con cualquier otro proveedor. La integración se encarga del connection pooling, trazas de OpenTelemetry y health checks en segundo plano.

Para desarrolladores .NET que han estado usando MongoDB con el driver directo y configurando connection strings manualmente, esto es una mejora de calidad de vida muy bienvenida. Obtienes la abstracción completa de EF Core sin perder el service discovery de Aspire.

Azure Data Lake Storage se une a la fiesta

La segunda gran adición es una integración de Azure Data Lake Storage (ADLS). Si estás construyendo pipelines de datos, procesos ETL o plataformas de analítica, ahora puedes conectar recursos de Data Lake de la misma forma que conectarías cualquier otra dependencia de Aspire.

En el AppHost:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

En el proyecto consumidor:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Sin gestión manual de connection strings, sin buscar credenciales. Aspire aprovisiona los recursos y los inyecta. Para los que construimos apps .NET cloud-native que tocan tanto datos operacionales como cargas de trabajo analíticas, esto hace que el data lake se sienta como un ciudadano de primera clase en el modelo de Aspire.

Las pequeñas correcciones que importan

Más allá de las funcionalidades principales, hay algunas mejoras de calidad de vida que vale la pena mencionar:

Corrección del connection string de MongoDB — la barra diagonal antes del nombre de la base de datos ahora se maneja correctamente. Si habías implementado un workaround, ya puedes eliminarlo
Exports de SQL Server — Aspire.Hosting.SqlServer ahora exporta opciones de configuración adicionales del servidor para un control más granular
Actualizaciones de emuladores — emulador de ServiceBus 2.0.0, emulador de App Configuration 1.0.2, y el emulador preview de CosmosDB ahora incluye una verificación de disponibilidad
Azure Managed Redis — ahora usa rediss:// (Redis Secure) por defecto, así que las conexiones están cifradas desde el inicio

Esa última es sutil pero importante — Redis cifrado por defecto significa una cosa menos que configurar en producción.

Para cerrar

Aspire 13.2 es una versión incremental, pero las integraciones de MongoDB EF Core y Data Lake llenan vacíos reales. Si estabas esperando soporte adecuado de EF Core con MongoDB en Aspire, o necesitabas que Data Lake fuera una dependencia de primera clase, actualiza a 13.2 y pruébalas. El comando aspire add genera todo lo que necesitas.

Lee las notas de la versión completas para más detalles, y consulta la galería de integraciones para la lista completa.

azd update — Un solo comando para gobernar todos tus gestores de paquetes

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

¿Conoces ese mensaje de “Hay una nueva versión de azd disponible” que aparece cada pocas semanas? ¿Ese que ignoras porque no recuerdas si instalaste azd con winget, Homebrew o ese script de curl que ejecutaste hace seis meses? Bueno, eso por fin tiene solución.

Microsoft acaba de lanzar azd update — un único comando que actualiza Azure Developer CLI a la última versión sin importar cómo lo instalaste originalmente. Windows, macOS, Linux — da igual. Un solo comando.

Cómo funciona

azd update

Eso es todo. Si quieres acceso anticipado a nuevas funcionalidades, puedes cambiar a la build diaria de insiders:

azd update --channel daily
azd update --channel stable

El comando detecta tu método de instalación actual y usa el mecanismo de actualización apropiado internamente. Se acabó el “espera, ¿usé winget o choco en esta máquina?”

El pequeño detalle

azd update viene a partir de la versión 1.23.x. Si estás en una versión anterior, necesitarás hacer una última actualización manual usando tu método de instalación original. Después de eso, azd update se encarga de todo en adelante.

Comprueba tu versión actual con azd version. Si necesitas una instalación desde cero, la documentación de instalación te cubre.

Por qué importa

Es una pequeña mejora de calidad de vida, pero para los que usamos azd a diario para desplegar agentes de IA y apps de Aspire en Azure, estar actualizado significa menos momentos de “ese bug ya estaba corregido en la última versión”. Una cosa menos en la que pensar.

Lee el anuncio completo y el análisis más detallado de Jon Gallant para más contexto.

Azure Smart Tier ya está en GA — Optimización automática de costes en Blob Storage sin reglas de ciclo de vida

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Si alguna vez dedicaste tiempo a ajustar las políticas de ciclo de vida de Azure Blob Storage y luego las viste desmoronarse cuando cambiaron los patrones de acceso, esto te interesa. Microsoft acaba de anunciar la disponibilidad general de smart tier para Azure Blob y Data Lake Storage — una capacidad de tiering completamente administrada que mueve automáticamente los objetos entre los niveles hot, cool y cold según el uso real.

Qué hace realmente smart tier

El concepto es sencillo: smart tier evalúa continuamente el último tiempo de acceso de cada objeto en tu cuenta de almacenamiento. Los datos accedidos frecuentemente se quedan en hot, los datos inactivos pasan a cool después de 30 días, y luego a cold tras otros 60 días. Cuando se accede de nuevo a los datos, se promueven de vuelta a hot inmediatamente. El ciclo se reinicia.

Sin reglas de ciclo de vida que configurar. Sin predicciones de patrones de acceso. Sin ajustes manuales.

Durante la preview, Microsoft reportó que más del 50% de la capacidad gestionada por smart tier se movió automáticamente a niveles más fríos según los patrones reales de acceso. Es una reducción de costes significativa para cuentas de almacenamiento grandes.

Por qué esto importa para los desarrolladores .NET

Si estás construyendo aplicaciones que generan logs, telemetría, datos analíticos, o cualquier tipo de patrimonio de datos creciente — y seamos honestos, ¿quién no? — los costes de almacenamiento se acumulan rápido. El enfoque tradicional era escribir políticas de gestión de ciclo de vida, probarlas, y luego reajustarlas cuando los patrones de acceso de tu aplicación cambiaban. Smart tier elimina todo ese flujo de trabajo.

Algunos escenarios prácticos donde esto ayuda:

Telemetría y logs de aplicaciones — hot cuando estás depurando, rara vez accedidos después de unas semanas
Pipelines de datos y salidas de ETL — accedidos intensamente durante el procesamiento, luego mayormente cold
Contenido generado por usuarios — las subidas recientes están en hot, el contenido más antiguo se enfría gradualmente
Datos de backup y archivo — accedidos ocasionalmente por cumplimiento, mayormente inactivos

Cómo configurarlo

Habilitar smart tier es una configuración de una sola vez:

Cuentas nuevas: Selecciona smart tier como el nivel de acceso predeterminado durante la creación de la cuenta de almacenamiento (se requiere redundancia zonal)
Cuentas existentes: Cambia el nivel de acceso de blob de tu configuración actual a smart tier

Los objetos menores de 128 KiB se quedan en hot y no incurren en la tarifa de monitoreo. Para todo lo demás, pagas las tarifas estándar de capacidad hot/cool/cold sin cargos por transición de nivel, sin penalizaciones por eliminación temprana, y sin costes de recuperación de datos. Una tarifa mensual de monitoreo por objeto cubre la orquestación.

El compromiso que debes conocer

Las reglas de tiering de smart tier son estáticas (30 días → cool, 90 días → cold). Si necesitas umbrales personalizados — digamos, mover a cool después de 7 días para una carga de trabajo específica — las reglas de ciclo de vida siguen siendo el camino a seguir. Y no mezcles ambos: evita usar reglas de ciclo de vida sobre objetos gestionados por smart tier, ya que pueden entrar en conflicto.

Conclusión

Esto no es revolucionario, pero resuelve un dolor de cabeza operacional real. Si gestionas cuentas de blob storage en crecimiento y estás cansado de mantener políticas de ciclo de vida, habilita smart tier y deja que Azure se encargue. Está disponible hoy en casi todas las regiones zonales de la nube pública.

Las Agent Skills en .NET se volvieron muy flexibles

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

Si has estado construyendo agentes con el Microsoft Agent Framework, ya conoces la dinámica: defines skills, las conectas a un provider y dejas que el agente decida cuál invocar. Lo nuevo es cómo creas esas skills — y el salto en flexibilidad es importante.

La última actualización introduce tres patrones de autoría para agent skills: basadas en archivos, basadas en clases y definidas en código inline. Las tres se conectan a un único AgentSkillsProviderBuilder, lo que significa que puedes mezclar y combinar sin lógica de enrutamiento ni código especial. Te explico cada una y cuándo usarla.

Skills basadas en archivos: el punto de partida

Las skills basadas en archivos son exactamente lo que suenan — un directorio en disco con un archivo SKILL.md, scripts opcionales y documentos de referencia. Es la forma más directa de darle nuevas capacidades a tu agente:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

El frontmatter del SKILL.md declara el nombre y descripción, y la sección de instrucciones le dice al agente cómo usar los scripts y referencias:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

Luego lo conectas con SubprocessScriptRunner.RunAsync para la ejecución de scripts:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

El agente descubre la skill automáticamente e invoca el script de provisión cuando necesita verificar el estado de las cuentas. Limpio y simple.

Skills basadas en clases: distribuir vía NuGet

Aquí es donde se pone interesante para los equipos. Las skills basadas en clases derivan de AgentClassSkill<T> y usan atributos como [AgentSkillResource] y [AgentSkillScript] para que el framework descubra todo por reflexión:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

Lo mejor es que un equipo puede empaquetar esto como un paquete NuGet. Lo agregas a tu proyecto, lo metes en el builder y funciona junto a tus skills basadas en archivos sin coordinación:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Ambas skills aparecen en el system prompt del agente. El agente decide cuál usar según la conversación — sin código de enrutamiento.

Skills inline: el puente rápido

¿Conoces ese momento cuando otro equipo está construyendo exactamente la skill que necesitas, pero no la tendrán lista hasta el próximo sprint? AgentInlineSkill es tu puente:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

Agrégala al builder igual que las demás:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Cuando el paquete NuGet finalmente salga, intercambias la skill inline por la basada en clases. El agente no nota la diferencia.

Pero las skills inline no son solo para puentes. También son la opción correcta cuando necesitas generar skills dinámicamente en runtime — piensa en una skill por unidad de negocio cargada desde configuración — o cuando un script necesita capturar estado local que no pertenece a un contenedor DI.

Aprobación de scripts: humano en el bucle

Para los que construimos agentes de producción en .NET, esta es la parte que realmente desbloquea las conversaciones de despliegue. Algunos scripts tienen consecuencias reales — inscribir a alguien en beneficios, consultar infraestructura de producción. Activa UseScriptApproval y el agente se pausa antes de ejecutar cualquier script:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

Cuando el agente quiere ejecutar un script, devuelve una solicitud de aprobación. Tu app recoge la decisión — aprobar o rechazar — y el agente continúa. En entornos regulados, esta es la diferencia entre “podemos desplegar esto” y “legal dice que no.”

Por qué esta combinación importa

El verdadero poder no está en ningún patrón individual — está en la composición. Puedes:

Empezar pequeño con una skill basada en archivos, iterar en las instrucciones y publicarla sin escribir C#
Distribuir skills reutilizables como paquetes NuGet que otros equipos pueden agregar con una línea
Cubrir huecos con skills inline cuando necesitas algo ya
Filtrar directorios compartidos con predicados para que tu agente solo cargue lo que debe
Agregar supervisión humana para scripts que tocan sistemas de producción

Todo esto se compone a través de AgentSkillsProviderBuilder. Sin enrutamiento especial, sin lógica condicional, sin verificaciones de tipo de skill.

Para cerrar

Las agent skills en .NET ahora tienen un modelo de autoría genuinamente flexible. Ya sea que seas un desarrollador solo prototipando con skills basadas en archivos o un equipo enterprise distribuyendo capacidades empaquetadas vía NuGet, los patrones encajan. Y el mecanismo de aprobación de scripts lo hace listo para producción en entornos donde necesitas ese checkpoint humano.

Echa un vistazo al anuncio original, la documentación de Agent Skills en Microsoft Learn y los ejemplos en .NET en GitHub para ponerte manos a la obra.

Azure MCP Server 2.0 Acaba de Llegar — La Automatización Agentic en la Nube Auto-Alojada ya Está Aquí

Emiliano Montesdeoca — Sat, 11 Apr 2026 00:00:00 +0000

Si has estado construyendo algo con MCP y Azure últimamente, probablemente ya sepas que la experiencia local funciona bien. Conecta un servidor MCP, deja que tu agente de IA hable con recursos de Azure, y continúa. Pero en el momento en que necesitas compartir esa configuración entre un equipo? Ahí es donde las cosas se complicaban.

Ya no más. Azure MCP Server acaba de alcanzar 2.0 estable, y la característica principal es exactamente lo que los equipos empresariales han estado pidiendo: soporte para servidor MCP remoto auto-alojado.

¿Qué es Azure MCP Server?

Un repaso rápido. Azure MCP Server implementa la especificación del Protocolo de Contexto del Modelo y expone capacidades de Azure como herramientas estructuradas y detectables que los agentes de IA pueden invocar. Piénsalo como un puente estandarizado entre tu agente y Azure — provisioning, implementación, monitoreo, diagnósticos, todo a través de una interfaz consistente.

Los números hablan por sí solos: 276 herramientas MCP en 57 servicios de Azure. Esa es una cobertura seria.

Lo importante: implementaciones remotas auto-alojadas

Aquí está la cosa. Ejecutar MCP localmente en tu máquina está bien para desarrollo y experimentos. Pero en un escenario de equipo real, necesitas:

Acceso compartido para desarrolladores y sistemas de agentes internos
Configuración centralizada (contexto de tenant, valores predeterminados de suscripción, telemetría)
Límites de red y políticas empresariales
Integración en tuberías CI/CD

Azure MCP Server 2.0 aborda todo esto. Puedes desplegarlo como un servicio interno administrado centralmente con transporte basado en HTTP, autenticación adecuada y gobernanza consistente.

Para autenticación, tienes dos opciones sólidas:

Identidad Administrada — cuando se ejecuta junto a Microsoft Foundry
Flujo On-Behalf-Of (OBO) — delegación de OpenID Connect que llama a APIs de Azure usando el contexto del usuario conectado

Ese flujo OBO es particularmente interesante para nosotros los desarrolladores .NET. Significa que tus flujos de trabajo agentic pueden operar con los permisos reales del usuario, no con alguna cuenta de servicio con excesivos privilegios. Principio de privilegio mínimo, integrado desde el principio.

Endurecimiento de seguridad

Esto no es solo un lanzamiento de características — también es uno de seguridad. El lanzamiento 2.0 añade:

Validación de extremos más fuerte
Protecciones contra patrones de inyección en herramientas orientadas a consultas
Controles de aislamiento más estrictos para entornos de desarrollo

Si vas a exponer MCP como un servicio compartido, estas salvaguardas importan. Mucho.

¿Dónde puedes usarlo?

La historia de compatibilidad con clientes es amplia. Azure MCP Server 2.0 funciona con:

IDEs: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
Agentes CLI: GitHub Copilot CLI, Claude Code
Independiente: servidor local para configuraciones simples
Remoto auto-alojado: la nueva estrella de 2.0

Además hay soporte de nube soberana para Azure US Government y Azure operado por 21Vianet, que es crítico para implementaciones reguladas.

Por qué esto importa para desarrolladores .NET

Si estás construyendo aplicaciones agentic con .NET — ya sea Semantic Kernel, Microsoft Agent Framework, u orquestación propia — Azure MCP Server 2.0 te da una forma lista para producción de dejar que tus agentes interactúen con la infraestructura de Azure. Sin wrappers REST personalizados. Sin patrones de integración específicos del servicio. Solo MCP.

Combinado con la API fluida para MCP Apps que salió hace unos días, el ecosistema .NET MCP está madurando rápidamente.

Empezando

Elige tu ruta:

Repositorio de GitHub — código fuente, documentación, todo
Imagen de Docker — implementación contenedorizada
Extensión de VS Code — integración con IDE
Guía de auto-alojamiento — la característica insignia de 2.0

Resumiendo

Azure MCP Server 2.0 es exactamente el tipo de actualización de infraestructura que no se ve llamativa en una demostración pero lo cambia todo en la práctica. MCP remoto auto-alojado con autenticación adecuada, endurecimiento de seguridad y soporte de nube soberana significa que MCP está listo para equipos reales construyendo flujos de trabajo agentic reales en Azure. Si has estado esperando la señal de “listo para empresas” — esto es.

Conecta tus servidores MCP en Azure Functions a Foundry Agents — Así es como

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Esto es algo que me encanta del ecosistema MCP: construyes tu servidor una vez y funciona en todas partes. VS Code, Visual Studio, Cursor, ChatGPT — cada cliente MCP puede descubrir y usar tus herramientas. Ahora, Microsoft está añadiendo otro consumidor a esa lista: los agentes de Foundry.

Lily Ma del equipo de Azure SDK publicó una guía práctica sobre cómo conectar servidores MCP desplegados en Azure Functions con agentes de Microsoft Foundry. Si ya tienes un servidor MCP, esto es puro valor agregado — no necesitas reconstruir nada.

Por qué esta combinación tiene sentido

Azure Functions te da infraestructura escalable, autenticación integrada y facturación serverless para alojar servidores MCP. Microsoft Foundry te da agentes de IA que pueden razonar, planificar y tomar acciones. Conectar ambos significa que tus herramientas personalizadas — consultar una base de datos, llamar a una API de negocio, ejecutar lógica de validación — se convierten en capacidades que los agentes de IA empresariales pueden descubrir y usar de forma autónoma.

El punto clave: tu servidor MCP se mantiene igual. Solo estás añadiendo Foundry como otro consumidor. Las mismas herramientas que funcionan en tu configuración de VS Code ahora potencian un agente de IA con el que tu equipo o clientes interactúan.

Opciones de autenticación

Aquí es donde el post realmente aporta valor. Cuatro métodos de autenticación según tu escenario:

Método	Caso de uso
Basado en clave (predeterminado)	Desarrollo o servidores sin autenticación Entra
Microsoft Entra	Producción con identidades administradas
Passthrough de identidad OAuth	Producción donde cada usuario se autentica individualmente
Sin autenticación	Desarrollo/pruebas o solo datos públicos

Para producción, Microsoft Entra con identidad del agente es el camino recomendado. El passthrough de identidad OAuth es para cuando el contexto del usuario importa — el agente pide a los usuarios que inicien sesión, y cada solicitud lleva el token propio del usuario.

Configurándolo

El flujo general:

Despliega tu servidor MCP en Azure Functions — hay ejemplos disponibles para .NET, Python, TypeScript y Java
Habilita la autenticación MCP integrada en tu function app
Obtén tu URL de endpoint — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Añade el servidor MCP como herramienta en Foundry — navega a tu agente en el portal, añade una nueva herramienta MCP, proporciona endpoint y credenciales

Luego pruébalo en el playground de Agent Builder enviando un prompt que active una de tus herramientas.

Mi opinión

La historia de composabilidad aquí se está volviendo realmente fuerte. Construye tu servidor MCP una vez en .NET (o Python, TypeScript, Java), despliégalo en Azure Functions, y cada cliente compatible con MCP puede usarlo — herramientas de programación, apps de chat, y ahora agentes de IA empresariales. Es un patrón de “escribe una vez, usa en todas partes” que realmente funciona.

Para desarrolladores .NET específicamente, la extensión MCP de Azure Functions hace esto sencillo. Defines tus herramientas como Azure Functions, despliegas, y tienes un servidor MCP de nivel producción con toda la seguridad y escalabilidad que Azure Functions proporciona.

Para cerrar

Si tienes herramientas MCP ejecutándose en Azure Functions, conectarlas a agentes de Foundry es una victoria rápida — tus herramientas personalizadas se convierten en capacidades de IA empresarial con autenticación adecuada y sin cambios de código en el servidor.

Lee la guía completa para instrucciones paso a paso sobre cada método de autenticación, y consulta la documentación detallada para configuraciones de producción.

Construyendo UIs Multi-Agente en Tiempo Real Que No Se Sientan Como una Caja Negra

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

La verdad sobre los sistemas multi-agente: se ven increíbles en las demos. Tres agentes pasándose trabajo, resolviendo problemas, tomando decisiones. Luego intentas ponerlo frente a usuarios reales y… silencio. Un indicador girando. Sin idea de qué agente está haciendo qué ni por qué el sistema se pausó. Eso no es un producto — es un problema de confianza.

El equipo de Microsoft Agent Framework acaba de publicar un fantástico tutorial sobre cómo combinar flujos MAF con AG-UI, un protocolo abierto para transmitir eventos de ejecución de agentes a un frontend mediante Server-Sent Events. Y sinceramente, este es el puente que nos hacía falta.

Por qué esto importa para desarrolladores .NET

Si estás construyendo apps potenciadas por IA, probablemente ya te topaste con esta pared. Tu orquestación backend funciona perfecto — los agentes se pasan tareas, las herramientas se ejecutan, las decisiones se toman. Pero el frontend no tiene ni idea de lo que pasa detrás de escena. AG-UI resuelve esto definiendo un protocolo estándar para transmitir eventos de agentes (piensa en RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_*) directamente a tu capa de UI por SSE.

La demo que construyeron es un flujo de soporte al cliente con tres agentes: un agente de triaje que enruta solicitudes, un agente de reembolsos que maneja temas de dinero, y un agente de pedidos que gestiona reemplazos. Cada agente tiene sus propias herramientas, y la topología de handoff está definida explícitamente — nada de “descúbrelo desde el prompt”.

La topología de handoff es la verdadera estrella

Lo que me llamó la atención es cómo HandoffBuilder te permite declarar un grafo dirigido de enrutamiento entre agentes:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

Cada add_handoff crea una arista dirigida con una descripción en lenguaje natural. El framework genera herramientas de handoff para cada agente basándose en esta topología. Así que las decisiones de enrutamiento están fundamentadas en tu estructura de orquestación, no solo en lo que al LLM se le ocurra hacer. Eso es un cambio enorme para la confiabilidad en producción.

Human-in-the-loop que realmente funciona

La demo muestra dos patrones de interrupción que cualquier app de agentes del mundo real necesita:

Interrupciones de aprobación de herramientas — cuando un agente llama a una herramienta marcada con approval_mode="always_require", el flujo se pausa y emite un evento. El frontend renderiza un modal de aprobación con el nombre de la herramienta y sus argumentos. Sin bucles de reintento que quemen tokens — solo un flujo limpio de pausa-aprobación-reanudación.

Interrupciones de solicitud de información — cuando un agente necesita más contexto del usuario (como un ID de pedido), se pausa y pregunta. El frontend muestra la pregunta, el usuario responde, y la ejecución se reanuda exactamente donde se detuvo.

Ambos patrones se transmiten como eventos estándar de AG-UI, así que tu frontend no necesita lógica personalizada por agente — simplemente renderiza cualquier evento que llegue por la conexión SSE.

Conectarlo todo es sorprendentemente simple

La integración entre MAF y AG-UI se reduce a una sola llamada de función:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

El workflow_factory crea un flujo nuevo por hilo, así cada conversación obtiene estado aislado. El endpoint maneja toda la plomería SSE automáticamente. Si ya estás usando FastAPI (o puedes añadirlo como una capa ligera), esto tiene prácticamente cero fricción.

Mi opinión

Para nosotros los desarrolladores .NET, la pregunta inmediata es: “¿Puedo hacer esto en C#?” El Agent Framework está disponible tanto para .NET como para Python, y el protocolo AG-UI es agnóstico de lenguaje (solo es SSE). Así que aunque esta demo específica usa Python y FastAPI, el patrón se traduce directamente. Podrías montar una API mínima de ASP.NET Core con endpoints SSE siguiendo el mismo esquema de eventos de AG-UI.

La conclusión más importante es que las UIs multi-agente se están convirtiendo en una preocupación de primera clase, no algo que se deja para después. Si estás construyendo cualquier cosa donde los agentes interactúan con humanos — soporte al cliente, flujos de aprobación, procesamiento de documentos — esta combinación de orquestación MAF y transparencia AG-UI es el patrón a seguir.

Para cerrar

AG-UI + Microsoft Agent Framework te da lo mejor de ambos mundos: orquestación multi-agente robusta en el backend y visibilidad en tiempo real en el frontend. No más interacciones de agentes como cajas negras.

Revisa el tutorial completo y el repositorio del protocolo AG-UI para profundizar más.

La evaluación de modernización de GitHub Copilot es la mejor herramienta de migración que aún no estás usando

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Migrar una aplicación legacy de .NET Framework a .NET moderno es una de esas tareas que todos saben que deberían hacer pero nadie quiere empezar. Nunca es solo “cambiar el target framework.” Son APIs que desaparecieron, paquetes que ya no existen, modelos de hosting que funcionan completamente diferente, y un millón de pequeñas decisiones sobre qué containerizar, qué reescribir y qué dejar como está.

Jeffrey Fritz acaba de publicar una inmersión profunda en la evaluación de modernización de GitHub Copilot, y honestamente, es el mejor tooling de migración que he visto para .NET. No por la generación de código — eso ya es estándar. Por el documento de evaluación que produce.

No es solo un motor de sugerencias de código

La extensión de VS Code sigue un modelo de Evaluar → Planificar → Ejecutar. La fase de evaluación analiza todo tu código base y produce un documento estructurado que captura todo: qué necesita cambiar, qué recursos de Azure aprovisionar, qué modelo de despliegue usar. Todo lo posterior — infraestructura como código, containerización, manifiestos de despliegue — fluye de lo que la evaluación encuentra.

La evaluación se almacena en .github/modernize/assessment/ en tu proyecto. Cada ejecución produce un reporte independiente, así que acumulas un historial y puedes rastrear cómo evoluciona tu postura de migración a medida que corriges issues.

Dos formas de empezar

Evaluación Recomendada — el camino rápido. Elige entre dominios curados (Actualización Java/.NET, Cloud Readiness, Seguridad) y obtén resultados significativos sin tocar configuración. Genial para una primera mirada a dónde está tu aplicación.

Evaluación Personalizada — el camino dirigido. Configura exactamente qué analizar: cómputo objetivo (App Service, AKS, Container Apps), SO objetivo, análisis de containerización. Elige múltiples destinos Azure para comparar enfoques de migración lado a lado.

Esa vista de comparación es genuinamente útil. Una app con 3 issues obligatorios para App Service podría tener 7 para AKS. Ver ambos ayuda a decidir el hosting antes de comprometerse con un camino de migración.

El desglose de issues es accionable

Cada issue viene con un nivel de criticidad:

Obligatorio — debe corregirse o la migración falla
Potencial — podría impactar la migración, necesita juicio humano
Opcional — mejoras recomendadas, no bloquean la migración

Y cada issue enlaza a archivos afectados y números de línea, proporciona una descripción detallada de qué está mal y por qué importa para tu plataforma objetivo, da pasos concretos de remediación (no solo “arregla esto”), e incluye enlaces a documentación oficial.

Puedes asignar issues individuales a desarrolladores y tienen todo lo que necesitan para actuar. Esa es la diferencia entre una herramienta que te dice “hay un problema” y una que te dice cómo resolverlo.

Las rutas de actualización cubiertas

Para .NET específicamente:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Cada ruta de actualización tiene reglas de detección que saben qué APIs fueron eliminadas, qué patrones no tienen equivalente directo, y qué issues de seguridad necesitan atención.

Para equipos que gestionan múltiples aplicaciones, también hay un CLI que soporta evaluaciones batch multi-repo — clona todos los repos, evalúalos todos, obtén reportes por app más una vista de portafolio agregada.

Mi opinión

Si estás sentado sobre aplicaciones legacy de .NET Framework (y seamos honestos, la mayoría de los equipos empresariales lo están), esta es la herramienta con la que empezar. Solo el documento de evaluación vale el tiempo — convierte un vago “deberíamos modernizar” en una lista concreta y priorizada de elementos de trabajo con caminos claros hacia adelante.

El flujo de trabajo colaborativo también es inteligente: exporta evaluaciones, compártelas con tu equipo, impórtalas sin re-ejecutar. ¿Revisiones de arquitectura donde los que toman decisiones no son los que ejecutan las herramientas? Cubierto.

Para cerrar

La evaluación de modernización de GitHub Copilot transforma la migración de .NET de un proyecto aterrador e indefinido en un proceso estructurado y rastreable. Empieza con una evaluación recomendada para ver dónde estás, luego usa evaluaciones personalizadas para comparar destinos Azure y construir tu plan de migración.

Lee el walkthrough completo y descarga la extensión de VS Code para probarlo en tu propio código.

La Ingeniería de Plataformas Agéntica Se Está Haciendo Real — Git-APE Muestra Cómo

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

La ingeniería de plataformas ha sido uno de esos términos que suena genial en conferencias pero que normalmente significa “construimos un portal interno y un wrapper de Terraform.” La verdadera promesa — infraestructura self-service que realmente sea segura, gobernada y rápida — siempre ha estado a unos pasos de distancia.

El equipo de Azure acaba de publicar la Parte 2 de su serie sobre ingeniería de plataformas agéntica, y esta es sobre la implementación práctica. Lo llaman Git-APE (sí, el acrónimo es intencional), y es un proyecto open source que usa agentes de GitHub Copilot más servidores Azure MCP para convertir solicitudes en lenguaje natural en infraestructura validada y desplegada.

Qué hace Git-APE realmente

La idea central: en vez de que los desarrolladores aprendan módulos de Terraform, naveguen por UIs de portales o abran tickets al equipo de plataforma, hablan con un agente de Copilot. El agente interpreta la intención, genera Infrastructure-as-Code, la valida contra políticas y despliega — todo dentro de VS Code.

Aquí está la configuración:

git clone https://github.com/Azure/git-ape
cd git-ape

Abre el workspace en VS Code, y los archivos de configuración del agente son descubiertos automáticamente por GitHub Copilot. Interactúas con el agente directamente:

@git-ape deploy a function app with storage in West Europe

El agente usa Azure MCP Server internamente para interactuar con los servicios de Azure. La configuración de MCP en las opciones de VS Code habilita capacidades específicas:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Por qué esto importa

Para los que construimos en Azure, esto cambia la conversación de ingeniería de plataformas de “cómo construimos un portal” a “cómo describimos nuestras barreras de seguridad como APIs.” Cuando la interfaz de tu plataforma es un agente de IA, la calidad de tus restricciones y políticas se convierte en el producto.

El blog de la Parte 1 planteó la teoría: APIs bien descritas, esquemas de control y barreras explícitas hacen las plataformas agent-ready. La Parte 2 lo demuestra funcionando con herramientas reales. El agente no genera recursos ciegamente — valida contra mejores prácticas, respeta convenciones de nomenclatura y aplica las políticas de tu organización.

La limpieza es igual de sencilla:

@git-ape destroy my-resource-group

Mi opinión

Seré honesto — esta es más sobre el patrón que sobre la herramienta específica. Git-APE en sí es una demo/arquitectura de referencia. Pero la idea subyacente — agentes como la interfaz de tu plataforma, MCP como protocolo, GitHub Copilot como host — es hacia donde se dirige la experiencia del desarrollador empresarial.

Si eres un equipo de plataforma buscando cómo hacer tu herramienta interna amigable para agentes, no hay mejor punto de partida. Y si eres un desarrollador .NET preguntándote cómo se conecta esto con tu mundo: el Azure MCP Server y los agentes de GitHub Copilot funcionan con cualquier carga de trabajo de Azure. Tu API ASP.NET Core, tu stack .NET Aspire, tus microservicios contenerizados — todo puede ser el objetivo de un flujo de despliegue agéntico.

Para cerrar

Git-APE es una mirada temprana pero concreta a la ingeniería de plataformas agéntica en la práctica. Clona el repo, prueba la demo y empieza a pensar en cómo las APIs y políticas de tu plataforma necesitarían verse para que un agente las use de forma segura.

Lee el post completo para el walkthrough y videos de demostración.

Microsoft Foundry Marzo 2026 — GPT-5.4, Agent Service GA y la Renovación del SDK Que lo Cambia Todo

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Los posts mensuales de “Novedades en Microsoft Foundry” suelen ser una mezcla de mejoras incrementales y alguna que otra característica destacada. ¿La edición de marzo 2026? Básicamente son todas características destacadas. Foundry Agent Service llega a GA, GPT-5.4 se lanza para producción, el SDK recibe una versión estable importante, y Fireworks AI trae inferencia de modelos abiertos a Azure. Vamos a desglosar lo que importa para los desarrolladores .NET.

Foundry Agent Service está listo para producción

Esta es la grande. El runtime de agentes de nueva generación está disponible de forma general — construido sobre la API de Responses de OpenAI, compatible a nivel de protocolo con los agentes de OpenAI, y abierto a modelos de múltiples proveedores. Si estás construyendo con la API de Responses hoy, migrar a Foundry añade seguridad empresarial, redes privadas, RBAC de Entra, trazabilidad completa y evaluación sobre tu lógica de agentes existente.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

Adiciones clave: redes privadas de extremo a extremo, expansión de autenticación MCP (incluyendo passthrough de OAuth), vista previa de Voice Live para agentes de voz a voz, y agentes alojados en 6 nuevas regiones.

GPT-5.4 — confiabilidad sobre inteligencia pura

GPT-5.4 no se trata de ser más inteligente. Se trata de ser más confiable. Razonamiento más sólido en interacciones largas, mejor adherencia a instrucciones, menos fallos en medio de flujos de trabajo, y capacidades integradas de uso de computadora. Para agentes en producción, esa confiabilidad importa mucho más que las puntuaciones en benchmarks.

Modelo	Precio (por M tokens)	Ideal Para
GPT-5.4 (≤272K)	$2.50 / $15 salida	Agentes en producción, código, flujos de documentos
GPT-5.4 Pro	$30 / $180 salida	Análisis profundo, razonamiento científico
GPT-5.4 Mini	Económico	Clasificación, extracción, llamadas ligeras a herramientas

La jugada inteligente es una estrategia de enrutamiento: GPT-5.4 Mini maneja el trabajo de alto volumen y baja latencia mientras GPT-5.4 se encarga de las solicitudes con razonamiento pesado.

El SDK finalmente es estable

El SDK azure-ai-projects lanzó versiones estables en todos los lenguajes — Python 2.0.0, JS/TS 2.0.0, Java 2.0.0 y .NET 2.0.0 (1 de abril). La dependencia de azure-ai-agents desapareció — todo vive bajo AIProjectClient. Instala con pip install azure-ai-projects y el paquete incluye openai y azure-identity como dependencias directas.

Para los desarrolladores .NET, esto significa un único paquete NuGet para toda la superficie de Foundry. No más malabarismo con SDKs de agentes separados.

Fireworks AI trae modelos abiertos a Azure

Quizás la adición más interesante arquitectónicamente: Fireworks AI procesando más de 13 billones de tokens diarios a ~180K solicitudes/segundo, ahora disponible a través de Foundry. DeepSeek V3.2, gpt-oss-120b, Kimi K2.5 y MiniMax M2.5 en el lanzamiento.

La verdadera historia es trae-tus-propios-pesos — sube pesos cuantizados o ajustados desde cualquier lugar sin cambiar la pila de servicio. Despliega mediante pago por token sin servidor o throughput provisionado.

Otros destacados

Phi-4 Reasoning Vision 15B — razonamiento multimodal para gráficos, diagramas y diseños de documentos
Evaluaciones GA — evaluadores listos para usar con monitoreo continuo de producción canalizado a Azure Monitor
Procesamiento Prioritario (Preview) — carril de cómputo dedicado para cargas de trabajo sensibles a la latencia
Voice Live — runtime de voz a voz que se conecta directamente a los agentes de Foundry
Tracing GA — inspección de trazas de agentes de extremo a extremo con ordenamiento y filtrado
Deprecación de PromptFlow — migración a Microsoft Framework Workflows para enero de 2027

Conclusión

Marzo 2026 es un punto de inflexión para Foundry. Agent Service GA, SDKs estables en todos los lenguajes, GPT-5.4 para agentes de producción confiables, e inferencia de modelos abiertos vía Fireworks AI — la plataforma está lista para cargas de trabajo serias.

Lee el resumen completo y construye tu primer agente para empezar.

SQL MCP Server — La forma correcta de darle acceso a bases de datos a los agentes de IA

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Seamos honestos: la mayoría de los servidores MCP de bases de datos disponibles hoy son aterradores. Toman una consulta en lenguaje natural, generan SQL al vuelo y lo ejecutan contra tus datos de producción. ¿Qué podría salir mal? (Todo. Todo podría salir mal.)

El equipo de Azure SQL acaba de presentar SQL MCP Server, y toma un enfoque fundamentalmente diferente. Construido como una característica de Data API builder (DAB) 2.0, da a los agentes de IA acceso estructurado y determinista a operaciones de base de datos — sin NL2SQL, sin exponer tu esquema, y con RBAC completo en cada paso.

¿Por qué no NL2SQL?

Esta es la decisión de diseño más interesante. Los modelos no son deterministas, y las consultas complejas son las más propensas a producir errores sutiles. Las consultas exactas que los usuarios esperan que la IA genere son también las que necesitan más escrutinio cuando se producen de forma no determinista.

En su lugar, SQL MCP Server usa un enfoque NL2DAB. El agente trabaja con la capa de abstracción de entidades de Data API builder y su constructor de consultas integrado para producir T-SQL preciso y bien formado de manera determinista. Mismo resultado para el usuario, pero sin el riesgo de JOINs alucinados o exposición accidental de datos.

Siete herramientas, no setecientas

SQL MCP Server expone exactamente siete herramientas DML, sin importar el tamaño de la base de datos:

describe_entities — descubrir entidades y operaciones disponibles
create_record — insertar filas
read_records — consultar tablas y vistas
update_record — modificar filas
delete_record — eliminar filas
execute_entity — ejecutar procedimientos almacenados
aggregate_records — consultas de agregación

Esto es inteligente porque las ventanas de contexto son el espacio de pensamiento del agente. Inundarlas con cientos de definiciones de herramientas deja menos espacio para el razonamiento. Siete herramientas fijas mantienen al agente enfocado en pensar en lugar de navegar.

Cada herramienta puede habilitarse o deshabilitarse individualmente:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

Empezando en tres comandos

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

Eso es un SQL MCP Server funcionando y exponiendo tu tabla Customers. La capa de abstracción de entidades significa que puedes crear alias para nombres y columnas, limitar campos por rol, y controlar exactamente lo que ven los agentes — sin exponer detalles internos del esquema.

La historia de seguridad es sólida

Aquí es donde la madurez de Data API builder da frutos:

RBAC en cada capa — cada entidad define qué roles pueden leer, crear, actualizar o eliminar, y qué campos son visibles
Integración con Azure Key Vault — cadenas de conexión y secretos gestionados de forma segura
Microsoft Entra + OAuth personalizado — autenticación de nivel producción
Content Security Policy — los agentes interactúan a través de un contrato controlado, no SQL crudo

La abstracción del esquema es particularmente importante. Los nombres internos de tus tablas y columnas nunca se exponen al agente. Defines entidades, alias y descripciones que tienen sentido para la interacción con IA — no tu diagrama ERD de la base de datos.

Multi-base de datos y multi-protocolo

SQL MCP Server soporta Microsoft SQL, PostgreSQL, Azure Cosmos DB y MySQL. Y como es una característica de DAB, obtienes endpoints REST, GraphQL y MCP simultáneamente desde la misma configuración. Mismas definiciones de entidades, mismas reglas RBAC, misma seguridad — en los tres protocolos.

La auto-configuración en DAB 2.0 puede incluso inspeccionar tu base de datos y construir la configuración dinámicamente, si te resulta cómodo menos abstracción para prototipado rápido.

Mi opinión

Así es como debería funcionar el acceso empresarial a bases de datos para agentes de IA. No “hey LLM, escríbeme algo de SQL y YOLO contra producción.” En su lugar: una capa de entidades bien definida, generación determinista de consultas, RBAC en cada paso, caché, monitoreo y telemetría. Es aburrido de la mejor manera posible.

Para desarrolladores .NET, la historia de integración es limpia — DAB es una herramienta .NET, el MCP Server se ejecuta como contenedor, y funciona con Azure SQL, que la mayoría ya estamos usando. Si estás construyendo agentes de IA que necesitan acceso a datos, empieza aquí.

Para cerrar

SQL MCP Server es gratuito, de código abierto y se ejecuta en cualquier lugar. Es el enfoque prescriptivo de Microsoft para dar acceso seguro a bases de datos a los agentes de IA. Consulta el post completo y la documentación para empezar.

azd ahora te permite ejecutar y depurar agentes IA localmente — Esto es lo que cambió en marzo 2026

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Siete versiones en un mes. Eso es lo que el equipo del Azure Developer CLI (azd) publicó en marzo 2026, y la función estrella es la que estaba esperando: un bucle local de ejecución y depuración para agentes IA.

PC Chan publicó el resumen completo, y aunque hay mucho contenido, déjame filtrarlo a lo que realmente importa para desarrolladores .NET que construyen apps con IA.

Ejecutar y depurar agentes IA sin desplegar

Esta es la grande. La nueva extensión azure.ai.agents añade un conjunto de comandos que te dan una experiencia de bucle interno adecuada para agentes IA:

azd ai agent run — inicia tu agente localmente
azd ai agent invoke — le envía mensajes (local o desplegado)
azd ai agent show — muestra el estado del contenedor y su salud
azd ai agent monitor — transmite logs del contenedor en tiempo real

Antes, probar un agente IA significaba desplegarlo en Microsoft Foundry cada vez que hacías un cambio. Ahora puedes iterar localmente, probar el comportamiento de tu agente, y solo desplegarlo cuando estés listo. Si has estado construyendo agentes con el Microsoft Agent Framework o Semantic Kernel, esto cambia tu flujo de trabajo diario.

El comando invoke funciona tanto contra agentes locales como desplegados, lo que significa que puedes usar el mismo flujo de pruebas sin importar dónde esté corriendo el agente. Ese es el tipo de detalle que te ahorra mantener dos conjuntos de scripts de prueba.

GitHub Copilot configura tu proyecto azd

azd init ahora ofrece una opción “Set up with GitHub Copilot (Preview)”. En lugar de responder prompts manualmente sobre la estructura de tu proyecto, un agente Copilot genera la configuración por ti. Verifica que el directorio de trabajo esté limpio antes de modificar archivos y pide consentimiento de herramientas MCP por adelantado.

Cuando un comando falla, azd ahora ofrece troubleshooting asistido por IA: elige una categoría (explicar, guiar, solucionar o saltar), deja que el agente sugiera una corrección, y reintenta — todo sin salir de la terminal. Para configuraciones de infraestructura complejas, eso ahorra tiempo real.

Container App Jobs y mejoras de despliegue

Algunas funciones de despliegue que vale la pena mencionar:

Container App Jobs: azd ahora despliega Microsoft.App/jobs a través de la configuración existente host: containerapp. Tu plantilla Bicep determina si el destino es un Container App o un Job — sin configuración extra.
Timeouts configurables: Nueva flag --timeout en azd deploy y un campo deployTimeout en azure.yaml. Sin más adivinanzas sobre el límite predeterminado de 1200 segundos.
Fallback de build remoto: Cuando falla el build remoto en ACR, azd hace fallback automático a Docker/Podman local.
Validación preflight local: Los parámetros de Bicep se validan localmente antes de desplegar, detectando parámetros faltantes sin un viaje de ida y vuelta a Azure.

Pulido en la experiencia de desarrollador

Algunas mejoras más pequeñas que se suman:

Detección automática de pnpm/yarn para proyectos JS/TS
Soporte para pyproject.toml para paquetes Python
Directorios de plantillas locales — azd init --template ahora acepta rutas del sistema de archivos para iteración offline
Mejores mensajes de error en modo --no-prompt — todos los valores faltantes reportados de una vez con comandos de resolución
Variables de entorno de build inyectadas en todos los subprocesos de build (.NET, Node.js, Java, Python)

La última es sutil pero importante: tu build .NET ahora tiene acceso a las variables de entorno de azd, lo que significa que puedes hacer inyección de configuración en tiempo de compilación sin scripting adicional.

Para cerrar

El bucle de depuración local de agentes IA es la estrella de esta versión, pero la acumulación de mejoras de despliegue y refinamiento de DX hace que azd se sienta más maduro que nunca. Si estás desplegando apps .NET en Azure — especialmente agentes IA — esta actualización vale la pena.

Revisa las notas completas de la versión para todos los detalles, o comienza con la instalación de azd.

KubeCon Europe 2026: Lo que los desarrolladores .NET deberían saber de verdad

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

Esta publicación fue traducida automáticamente. Para la versión original, haz clic aquí.

¿Conoces esa sensación cuando cae un post de anuncios enorme y estás scrolleando pensando “genial, pero qué cambia esto realmente para mí”? Eso me pasa cada temporada de KubeCon.

Microsoft acaba de publicar su resumen completo de KubeCon Europe 2026 — escrito por el mismísimo Brendan Burns — y sinceramente, hay sustancia real aquí. No solo checkboxes de features, sino mejoras operacionales que cambian cómo manejas las cosas en producción.

Te resumo lo que realmente importa para nosotros los desarrolladores .NET.

mTLS sin el impuesto del service mesh

Aquí va la cosa sobre los service meshes: todo el mundo quiere las garantías de seguridad, nadie quiere la carga operacional. AKS por fin está cerrando esa brecha.

Azure Kubernetes Application Network te da TLS mutuo, autorización basada en identidad de aplicación y telemetría de tráfico — sin desplegar un mesh pesado con sidecars. Combinado con Cilium mTLS en Advanced Container Networking Services, tienes comunicación encriptada pod-a-pod usando certificados X.509 y SPIRE para gestión de identidades.

¿Qué significa esto en la práctica? Tus APIs de ASP.NET Core hablando con workers en segundo plano, tus servicios gRPC llamándose entre sí — todo encriptado y verificado a nivel de red, sin cambios en el código de la aplicación. Eso es enorme.

Para equipos migrando desde ingress-nginx, también hay Application Routing con Meshless Istio con soporte completo de Kubernetes Gateway API. Sin sidecars. Basado en estándares. Y lanzaron herramientas ingress2gateway para migración incremental.

Observabilidad de GPU que no es un añadido secundario

Si estás ejecutando inferencia de IA junto a tus servicios .NET (y seamos honestos, ¿quién no está empezando a hacerlo?), probablemente has topado con el punto ciego del monitoreo de GPU. Tenías dashboards geniales de CPU/memoria y luego… nada para GPUs sin configuración manual de exportadores.

AKS ahora expone métricas de GPU nativamente en Prometheus y Grafana gestionados. Mismo stack, mismos dashboards, mismo pipeline de alertas. Sin exportadores custom, sin agentes de terceros.

En el lado de red, añadieron visibilidad por flujo para tráfico HTTP, gRPC y Kafka con una experiencia one-click en Azure Monitor. IPs, puertos, workloads, dirección de flujo, decisiones de políticas — todo en dashboards integrados.

Y aquí viene la que me hizo mirar dos veces: agentic container networking añade una UI web donde puedes hacer preguntas en lenguaje natural sobre el estado de red de tu cluster. “¿Por qué el pod X no llega al servicio Y?” → diagnósticos de solo lectura desde telemetría en vivo. Eso es genuinamente útil a las 2 AM.

Networking cross-cluster que no requiere un doctorado

Multi-cluster en Kubernetes históricamente ha sido una experiencia de “trae tu propio pegamento de red”. Azure Kubernetes Fleet Manager ahora incluye networking cross-cluster mediante Cilium cluster mesh gestionado:

Conectividad unificada entre clusters AKS
Registro global de servicios para descubrimiento cross-cluster
Configuración gestionada centralmente, no repetida por cluster

Si estás corriendo microservicios .NET en varias regiones por resiliencia o cumplimiento, esto reemplaza mucho pegamento custom frágil. El Servicio A en West Europe puede descubrir y llamar al Servicio B en East US a través del mesh, con políticas de routing y seguridad consistentes.

Upgrades que no requieren valentía

Seamos honestos — los upgrades de Kubernetes en producción son estresantes. “Actualizar y rezar” ha sido la estrategia de facto para demasiados equipos, y es la razón principal por la que los clusters se quedan atrás en versiones.

Dos nuevas capacidades cambian esto:

Blue-green agent pool upgrades crean un pool de nodos paralelo con la nueva configuración. Valida el comportamiento, mueve tráfico gradualmente y mantén un camino limpio de rollback. No más mutaciones in-place en nodos de producción.

Agent pool rollback te permite revertir un pool de nodos a su versión anterior de Kubernetes e imagen de nodo después de que un upgrade sale mal — sin reconstruir el cluster.

Juntos, finalmente dan a los operadores control real sobre el ciclo de vida de upgrades. Para equipos .NET, esto importa porque la velocidad de la plataforma controla directamente qué tan rápido puedes adoptar nuevos runtimes, parches de seguridad y capacidades de red.

Los workloads de IA se convierten en ciudadanos de primera clase de Kubernetes

El trabajo upstream en open-source es igualmente importante. Dynamic Resource Allocation (DRA) acaba de llegar a GA en Kubernetes 1.36, haciendo del scheduling de GPU una feature de primera clase en lugar de un workaround.

Algunos proyectos que vale la pena seguir:

Proyecto	Qué hace
AI Runway	API común de Kubernetes para inferencia — despliega modelos sin saber K8s, con descubrimiento en HuggingFace y estimaciones de costo
HolmesGPT	Troubleshooting agéntico para cloud-native — ahora proyecto CNCF Sandbox
Dalec	Builds declarativos de imágenes de contenedor con generación de SBOM — menos CVEs en la etapa de build

La dirección es clara: tu API .NET, tu capa de orquestación con Semantic Kernel y tus workloads de inferencia deberían correr todos en un modelo de plataforma consistente. Estamos llegando ahí.

Por dónde empezaría esta semana

Si estás evaluando estos cambios para tu equipo, esta es mi lista honesta de prioridades:

Observabilidad primero — habilita métricas de GPU y logs de flujo de red en un cluster no-prod. Mira lo que te has estado perdiendo.
Prueba blue-green upgrades — testea el workflow de rollback antes de tu próximo upgrade de cluster en producción. Construye confianza en el proceso.
Pilotea networking con identidad — elige un path de servicio interno y habilita mTLS con Cilium. Mide el overhead (spoiler: es mínimo).
Evalúa Fleet Manager — si corres más de dos clusters, el networking cross-cluster se paga solo en reducción de pegamento custom.

Experimentos pequeños, feedback rápido. Esa es siempre la jugada.

Para cerrar

Los anuncios de KubeCon pueden ser abrumadores, pero esta tanda genuinamente mueve la aguja para equipos .NET en AKS. Mejor seguridad de red sin overhead de mesh, observabilidad real de GPU, upgrades más seguros y bases más fuertes para infraestructura de IA.

Si ya estás en AKS, es un gran momento para ajustar tu baseline operacional. Y si estás planeando mover workloads .NET a Kubernetes — la plataforma acaba de ponerse significativamente más lista para producción.

SQL MCP Server, Copilot en SSMS y un Database Hub con agentes de IA: Lo que realmente importa de SQLCon 2026

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft acaba de arrancar SQLCon 2026 junto con FabCon en Atlanta, y hay mucho que desempacar. El anuncio original cubre de todo, desde planes de ahorro hasta funciones de compliance empresarial. Yo me voy a saltar las diapositivas de precios enterprise y enfocarme en lo que importa si eres un desarrollador construyendo cosas con Azure SQL e IA.

SQL MCP Server está en public preview

Este es el titular para mí. Azure SQL Database Hyperscale ahora tiene un SQL MCP Server en public preview que te permite conectar de forma segura tus datos SQL a agentes de IA y Copilots usando el Model Context Protocol.

Si has estado siguiendo la ola de MCP — y honestamente, es difícil no verla ahora mismo — esto es importante. En lugar de construir pipelines de datos personalizados para alimentar a tus agentes de IA con contexto de tu base de datos, tienes un protocolo estandarizado para exponer datos SQL directamente. Tus agentes pueden consultar, razonar y actuar sobre información de base de datos en tiempo real.

Para los que estamos construyendo agentes de IA con Semantic Kernel o el Microsoft Agent Framework, esto abre un camino de integración limpio. ¿Tu agente necesita verificar inventario? ¿Buscar un registro de cliente? ¿Validar un pedido? MCP le da una forma estructurada de hacerlo sin que tengas que escribir código a medida para cada escenario.

GitHub Copilot en SSMS 22 ya está en GA

Si pasas algo de tiempo en SQL Server Management Studio — y seamos honestos, la mayoría todavía lo hacemos — GitHub Copilot ya está disponible de forma general en SSMS 22. La misma experiencia de Copilot que ya usas en VS Code y Visual Studio, pero para T-SQL.

El valor práctico es directo: asistencia por chat para escribir queries, refactorizar stored procedures, resolver problemas de rendimiento y manejar tareas de administración. Nada revolucionario en concepto, pero tenerlo ahí mismo en SSMS significa que no necesitas cambiar de contexto a otro editor solo para obtener ayuda de IA con tu trabajo de base de datos.

Los índices vectoriales recibieron una mejora seria

Azure SQL Database ahora tiene índices vectoriales más rápidos y capaces con soporte completo de insert, update y delete. Eso significa que tus datos vectoriales se mantienen actualizados en tiempo real — sin necesidad de reindexar por lotes.

Esto es lo nuevo:

Cuantización para tamaños de índice más pequeños sin perder demasiada precisión
Filtrado iterativo para resultados más precisos
Integración más ajustada con el optimizador de queries para rendimiento predecible

Si estás haciendo retrieval-augmented generation (RAG) con Azure SQL como tu almacén vectorial, estas mejoras son directamente útiles. Puedes mantener tus vectores junto con tus datos relacionales en la misma base de datos, lo que simplifica tu arquitectura significativamente comparado con ejecutar una base de datos vectorial separada.

Las mismas mejoras vectoriales también están disponibles en SQL database en Fabric, ya que ambos corren sobre el mismo motor SQL por debajo.

Database Hub en Fabric: gestión agéntica

Este es más orientado al futuro, pero es interesante. Microsoft anunció el Database Hub en Microsoft Fabric (acceso anticipado), que te da una vista unificada de Azure SQL, Cosmos DB, PostgreSQL, MySQL y SQL Server vía Arc.

El ángulo interesante no es solo la vista unificada — es el enfoque agéntico para la gestión. Agentes de IA monitorean continuamente tu estate de bases de datos, te muestran qué cambió, explican por qué importa y sugieren qué hacer. Es un modelo human-in-the-loop donde el agente hace el trabajo pesado y tú tomas las decisiones.

Para equipos que gestionan más de un puñado de bases de datos, esto podría genuinamente reducir el ruido operacional. En lugar de saltar entre portales y revisar métricas manualmente, el agente te trae la señal.

Qué significa esto para desarrolladores .NET

El hilo que conecta todos estos anuncios es claro: Microsoft está integrando agentes de IA en cada capa del stack de bases de datos. No como un truco, sino como una capa práctica de herramientas.

Si estás construyendo apps .NET respaldadas por Azure SQL, esto es lo que yo haría:

Prueba el SQL MCP Server si estás construyendo agentes de IA. Es la forma más limpia de darles acceso a base de datos sin plomería personalizada.
Activa Copilot en SSMS si no lo has hecho — ganancia de productividad gratis para el trabajo diario con SQL.
Investiga los índices vectoriales si estás haciendo RAG y actualmente tienes un almacén vectorial separado. Consolidar en Azure SQL significa un servicio menos que gestionar.

Para cerrar

El anuncio completo tiene más — planes de ahorro, asistentes de migración, funciones de compliance — pero la historia para desarrolladores está en el MCP Server, las mejoras vectoriales y la capa de gestión agéntica. Estas son las piezas que cambian cómo construyes, no solo cómo presupuestas.

Revisa el anuncio completo de Shireesh Thota para la foto completa, y regístrate para el acceso anticipado del Database Hub si quieres probar la nueva experiencia de gestión.

Del portátil a producción: desplegando agentes de IA en Microsoft Foundry con dos comandos

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

¿Conoces esa brecha entre “funciona en mi máquina” y “está desplegado y sirviendo tráfico”? Para agentes de IA, esa brecha ha sido dolorosamente amplia. Necesitas provisionar recursos, desplegar modelos, configurar identidad, montar monitoreo — y eso es antes de que alguien pueda realmente llamar a tu agente.

El Azure Developer CLI acaba de convertir esto en un asunto de dos comandos.

El nuevo flujo de trabajo `azd ai agent`

Déjame mostrarte cómo se ve esto realmente. Tienes un proyecto de agente de IA — digamos un agente concierge de hotel. Funciona localmente. Quieres que corra en Microsoft Foundry.

azd ai agent init
azd up

Eso es todo. Dos comandos. azd ai agent init genera la infraestructura como código en tu repositorio, y azd up provisiona todo en Azure y publica tu agente. Obtienes un enlace directo a tu agente en el portal de Foundry.

Qué pasa por debajo

El comando init genera plantillas Bicep reales e inspeccionables en tu repositorio:

Un Foundry Resource (contenedor de nivel superior)
Un Foundry Project (donde vive tu agente)
Configuración de despliegue de modelo (GPT-4o, etc.)
Identidad administrada con asignaciones de roles RBAC apropiadas
azure.yaml para el mapa de servicios
agent.yaml con metadatos del agente y variables de entorno

La parte clave: todo esto es tuyo. Es Bicep versionado en tu repositorio. Puedes inspeccionarlo, personalizarlo y hacer commit junto con el código de tu agente. Sin cajas negras mágicas.

El ciclo interno de desarrollo

Lo que realmente me gusta es la historia de desarrollo local. Cuando estás iterando sobre la lógica del agente, no quieres redesplegar cada vez que cambias un prompt:

azd ai agent run

Esto inicia tu agente localmente. Combínalo con azd ai agent invoke para enviar prompts de prueba, y tienes un ciclo de retroalimentación rápido. Editar código, reiniciar, invocar, repetir.

El comando invoke es inteligente con el enrutamiento también — cuando un agente local está corriendo, lo apunta automáticamente. Cuando no, apunta al endpoint remoto.

Monitoreo en tiempo real

Esta es la característica que me convenció. Una vez que tu agente está desplegado:

azd ai agent monitor --follow

Cada petición y respuesta que fluye a través de tu agente se transmite a tu terminal en tiempo real. Para depurar problemas en producción, esto es invaluable. Sin buscar en log analytics, sin esperar a que las métricas se agreguen — ves lo que está pasando ahora mismo.

El set completo de comandos

Aquí la referencia rápida:

Comando	Qué hace
`azd ai agent init`	Genera un proyecto de agente Foundry con IaC
`azd up`	Provisiona recursos Azure y despliega el agente
`azd ai agent invoke`	Envía prompts al agente remoto o local
`azd ai agent run`	Ejecuta el agente localmente para desarrollo
`azd ai agent monitor`	Transmite logs en tiempo real del agente publicado
`azd ai agent show`	Verifica la salud y estado del agente
`azd down`	Limpia todos los recursos Azure

Por qué esto importa para desarrolladores .NET

Aunque el ejemplo del anuncio está basado en Python, la historia de infraestructura es agnóstica al lenguaje. Tu agente .NET obtiene el mismo scaffolding Bicep, la misma configuración de identidad administrada, el mismo pipeline de monitoreo. Y si ya estás usando azd para tus apps .NET Aspire o despliegues Azure, esto encaja directamente en tu flujo de trabajo existente.

La brecha de despliegue para agentes de IA ha sido uno de los mayores puntos de fricción en el ecosistema. Pasar de un prototipo funcional a un endpoint de producción con identidad, networking y monitoreo adecuados no debería requerir una semana de trabajo DevOps. Ahora requiere dos comandos y unos minutos.

Para cerrar

azd ai agent está disponible ahora. Si has estado posponiendo el despliegue de tus agentes de IA porque la configuración de infraestructura parecía demasiado trabajo, dale una oportunidad. Revisa el tutorial completo para el paso a paso completo incluyendo integración de app de chat frontend.

El MCP Server de Azure DevOps llega a Microsoft Foundry: Qué significa para tus agentes de IA

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

MCP (Model Context Protocol) está teniendo su momento. Si has estado siguiendo el ecosistema de agentes de IA, probablemente hayas notado que los servidores MCP están apareciendo por todas partes — dándoles a los agentes la capacidad de interactuar con herramientas y servicios externos a través de un protocolo estandarizado.

Ahora el MCP Server de Azure DevOps está disponible en Microsoft Foundry, y esta es una de esas integraciones que te hace pensar en las posibilidades prácticas.

Qué está pasando realmente aquí

Microsoft ya lanzó el MCP Server de Azure DevOps como public preview — ese es el servidor MCP en sí. Lo nuevo es la integración con Foundry. Ahora puedes agregar el MCP Server de Azure DevOps a tus agentes de Foundry directamente desde el catálogo de herramientas.

Para los que no están familiarizados con Foundry todavía: es la plataforma unificada de Microsoft para construir y gestionar aplicaciones y agentes impulsados por IA a escala. Acceso a modelos, orquestación, evaluación, despliegue — todo en un solo lugar.

Configurándolo

La configuración es sorprendentemente sencilla:

En tu agente de Foundry, ve a Add Tools > Catalog
Busca “Azure DevOps”
Selecciona el Azure DevOps MCP Server (preview) y haz clic en Create
Ingresa el nombre de tu organización y conecta

Eso es todo. Tu agente ahora tiene acceso a las herramientas de Azure DevOps.

Controlando a qué puede acceder tu agente

Esta es la parte que aprecio: no estás atrapado con un enfoque de todo o nada. Puedes especificar qué herramientas están disponibles para tu agente. Así que si solo quieres que lea work items pero no toque pipelines, puedes configurar eso. Principio de mínimo privilegio, aplicado a tus agentes de IA.

Esto importa para escenarios empresariales donde no quieres que un agente accidentalmente dispare un pipeline de despliegue porque alguien le pidió que “ayude con el release.”

Por qué esto es interesante para equipos .NET

Piensa en lo que esto habilita en la práctica:

Asistentes de planificación de sprint — agentes que pueden obtener work items, analizar datos de velocidad y sugerir capacidad de sprint
Bots de code review — agentes que entienden el contexto de tu PR porque realmente pueden leer tus repos y work items vinculados
Respuesta a incidentes — agentes que pueden crear work items, consultar despliegues recientes y correlacionar bugs con cambios recientes
Onboarding de desarrolladores — “¿En qué debería trabajar?” obtiene una respuesta real respaldada por datos reales del proyecto

Para equipos .NET que ya usan Azure DevOps para sus pipelines de CI/CD y gestión de proyectos, tener un agente de IA que pueda interactuar directamente con esos sistemas es un paso significativo hacia la automatización útil (no solo chatbot-como-servicio).

El panorama más amplio de MCP

Esto es parte de una tendencia más amplia: los servidores MCP se están convirtiendo en la forma estándar en que los agentes de IA interactúan con el mundo exterior. Los estamos viendo para GitHub, Azure DevOps, bases de datos, APIs SaaS — y Foundry se está convirtiendo en el hub donde todas estas conexiones se unen.

Si estás construyendo agentes en el ecosistema .NET, vale la pena prestar atención a MCP. El protocolo está estandarizado, las herramientas están madurando, y la integración con Foundry lo hace accesible sin tener que conectar manualmente las conexiones del servidor.

Para cerrar

El MCP Server de Azure DevOps en Foundry está en preview, así que espera que evolucione. Pero el flujo de trabajo principal es sólido: conectar, configurar acceso a herramientas, y dejar que tus agentes trabajen con tus datos de DevOps. Si ya estás en el ecosistema de Foundry, esto está a unos pocos clics. Dale una oportunidad y ve qué flujos de trabajo puedes construir.

Revisa el anuncio completo para la configuración paso a paso y más detalles.

Foundry Agent Service está en GA: Lo que realmente importa para constructores de agentes .NET

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Seamos honestos — construir un prototipo de agente IA es la parte fácil. La parte difícil es todo lo que viene después: ponerlo en producción con aislamiento de red adecuado, ejecutar evaluaciones que realmente signifiquen algo, manejar requisitos de cumplimiento, y no romper cosas a las 2 AM.

El Foundry Agent Service acaba de llegar a GA, y esta versión está enfocada como un láser en esa brecha del “todo lo que viene después”.

Construido sobre la Responses API

El titular: el Foundry Agent Service de nueva generación está construido sobre la OpenAI Responses API. Si ya estás construyendo con ese protocolo, migrar a Foundry requiere cambios mínimos de código. Lo que ganas: seguridad empresarial, redes privadas, RBAC con Entra, trazabilidad completa y evaluación — sobre tu lógica de agente existente.

La arquitectura es intencionalmente abierta. No estás atado a un proveedor de modelos ni a un framework de orquestación. Usa DeepSeek para planificación, OpenAI para generación, LangGraph para orquestación — el runtime maneja la capa de consistencia.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Redes privadas: el bloqueador empresarial eliminado

Esta es la característica que desbloquea la adopción empresarial. Foundry ahora soporta redes privadas completas de extremo a extremo con BYO VNet:

Sin egress público — el tráfico del agente nunca toca internet público
Inyección de contenedores/subredes en tu red para comunicación local
Conectividad de herramientas incluida — servidores MCP, Azure AI Search, agentes de datos Fabric, todos operan sobre rutas privadas

Ese último punto es crítico. No son solo las llamadas de inferencia las que se mantienen privadas — cada invocación de herramienta y llamada de recuperación también permanece dentro del límite de tu red. Para equipos que operan bajo políticas de clasificación de datos que prohíben el enrutamiento externo, esto era lo que faltaba.

Autenticación MCP hecha correctamente

Las conexiones a servidores MCP ahora soportan el espectro completo de patrones de autenticación:

Método de auth	Cuándo usarlo
Basado en clave	Acceso compartido simple para herramientas internas de toda la organización
Entra Agent Identity	Servicio a servicio; el agente se autentica como él mismo
Entra Managed Identity	Aislamiento por proyecto; sin gestión de credenciales
OAuth Identity Passthrough	Acceso delegado por usuario; el agente actúa en nombre de los usuarios

OAuth Identity Passthrough es el interesante. Cuando los usuarios necesitan dar a un agente acceso a sus datos personales — su OneDrive, su organización de Salesforce, una API SaaS con alcance por usuario — el agente actúa en su nombre con flujos OAuth estándar. Sin identidad de sistema compartida pretendiendo ser todos.

Voice Live: voz a voz sin la fontanería

Agregar voz a un agente solía significar unir STT, LLM y TTS — tres servicios, tres saltos de latencia, tres superficies de facturación, todo sincronizado a mano. Voice Live colapsa eso en una única API administrada con:

Detección semántica de actividad de voz y fin de turno (entiende significado, no solo silencio)
Supresión de ruido y cancelación de eco del lado del servidor
Soporte de interrupción (los usuarios pueden interrumpir a mitad de respuesta)

Las interacciones de voz pasan por el mismo runtime de agente que el texto. Mismos evaluadores, mismas trazas, misma visibilidad de costos. Para soporte al cliente, servicio en campo o escenarios de accesibilidad, esto reemplaza lo que antes requería un pipeline de audio personalizado.

Evaluaciones: de checkbox a monitoreo continuo

Aquí es donde Foundry se pone serio sobre la calidad en producción. El sistema de evaluación ahora tiene tres capas:

Evaluadores incorporados — coherencia, relevancia, fundamentación, calidad de recuperación, seguridad. Conecta a un dataset o tráfico en vivo y obtén puntuaciones.
Evaluadores personalizados — codifica tu propia lógica de negocio, estándares de tono y reglas de cumplimiento específicas del dominio.
Evaluación continua — Foundry muestrea tráfico de producción en vivo, ejecuta tu suite de evaluadores y muestra resultados en dashboards. Configura alertas de Azure Monitor para cuando la fundamentación baje o los umbrales de seguridad se superen.

Todo se publica en Azure Monitor Application Insights. Calidad del agente, salud de la infraestructura, costo y telemetría de la aplicación — todo en un solo lugar.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Seis nuevas regiones para agentes hospedados

Los agentes hospedados ahora están disponibles en East US, North Central US, Sweden Central, Southeast Asia, Japan East y más. Esto importa para requisitos de residencia de datos y para comprimir la latencia cuando tu agente corre cerca de sus fuentes de datos.

Por qué esto importa para desarrolladores .NET

Aunque los ejemplos de código en el anuncio de GA son Python-first, la infraestructura subyacente es agnóstica al lenguaje — y el SDK de .NET para azure-ai-projects sigue los mismos patrones. La Responses API, el framework de evaluación, las redes privadas, la autenticación MCP — todo esto está disponible desde .NET.

Si has estado esperando a que los agentes IA pasen de “demo genial” a “realmente puedo enviar esto al trabajo”, esta versión GA es la señal. Redes privadas, autenticación adecuada, evaluación continua y monitoreo de producción son las piezas que faltaban.

Para cerrar

Foundry Agent Service está disponible ahora. Instala el SDK, abre el portal, y empieza a construir. La guía de inicio rápido te lleva de cero a un agente en ejecución en minutos.

Para el análisis técnico completo con todos los ejemplos de código, revisa el anuncio de GA.

Respuestas en segundo plano en Microsoft Agent Framework: Se acabó la ansiedad por timeouts

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Si has construido algo con modelos de razonamiento como o3 o GPT-5.2, conoces el dolor. Tu agente empieza a pensar en una tarea compleja, el cliente se queda esperando, y en algún punto entre “todo está bien” y “¿se habrá colgado?” tu conexión se corta por timeout. ¿Todo ese trabajo? Perdido.

Microsoft Agent Framework acaba de lanzar respuestas en segundo plano — y honestamente, esta es una de esas funcionalidades que deberían haber existido desde el primer día.

El problema con las llamadas bloqueantes

En un patrón tradicional de petición-respuesta, tu cliente se bloquea hasta que el agente termine. Eso funciona bien para tareas rápidas. Pero cuando le pides a un modelo de razonamiento que haga investigación profunda, análisis de múltiples pasos, o genere un informe de 20 páginas? Estás mirando minutos de tiempo real. Durante esa ventana:

Las conexiones HTTP pueden expirar
Los cortes de red matan toda la operación
Tu usuario se queda mirando un spinner preguntándose si algo está pasando

Las respuestas en segundo plano le dan la vuelta a esto.

Cómo funcionan los tokens de continuación

En lugar de bloquear, lanzas la tarea del agente y recibes un token de continuación. Piénsalo como un ticket de recogida en un taller de reparaciones — no te quedas parado en el mostrador esperando, vuelves cuando está listo.

El flujo es directo:

Envía tu petición con AllowBackgroundResponses = true
Si el agente soporta procesamiento en segundo plano, recibes un token de continuación
Consulta a tu ritmo hasta que el token vuelva null — eso significa que el resultado está listo

Aquí está la versión .NET:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Consultar hasta completar
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Si el agente completa inmediatamente (tareas simples, modelos que no necesitan procesamiento en segundo plano), no se devuelve ningún token de continuación. Tu código simplemente funciona — sin manejo especial necesario.

Streaming con reanudación: la verdadera magia

El polling está bien para escenarios de disparar y olvidar, pero ¿qué pasa cuando quieres progreso en tiempo real? Las respuestas en segundo plano también soportan streaming con reanudación incorporada.

Cada actualización del stream lleva su propio token de continuación. Si tu conexión se cae a mitad del stream, retomas exactamente donde lo dejaste:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simular una interrupción de red
}

// Reanudar desde exactamente donde lo dejamos
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

El agente sigue procesando en el servidor independientemente de lo que pase con tu cliente. Eso es tolerancia a fallos incorporada sin que tú escribas lógica de reintentos o circuit breakers.

Cuándo usar esto realmente

No toda llamada al agente necesita respuestas en segundo plano. Para completaciones rápidas, estás añadiendo complejidad sin razón. Pero aquí es donde brillan:

Tareas de razonamiento complejo — análisis de múltiples pasos, investigación profunda, cualquier cosa que haga a un modelo de razonamiento realmente pensar
Generación de contenido largo — informes detallados, documentos de múltiples partes, análisis extenso
Redes poco fiables — clientes móviles, despliegues en el edge, VPNs corporativas inestables
Patrones UX asíncronos — envía una tarea, ve a hacer otra cosa, vuelve por los resultados

Para nosotros los desarrolladores .NET construyendo apps empresariales, ese último es particularmente interesante. Piensa en una app Blazor donde un usuario solicita un informe complejo — lanzas la tarea del agente, les muestras un indicador de progreso, y les dejas seguir trabajando. Sin gimnasia con WebSockets, sin infraestructura de colas personalizada, solo un token y un bucle de polling.

Para cerrar

Las respuestas en segundo plano están disponibles ahora tanto en .NET como en Python a través de Microsoft Agent Framework. Si estás construyendo agentes que hacen algo más complejo que simple Q&A, vale la pena añadir esto a tu toolkit. El patrón de token de continuación mantiene las cosas simples mientras resuelve un problema de producción muy real.

Revisa la documentación completa para la referencia completa de la API y más ejemplos.

Azure | The .NET Blog

Microsoft Foundry Abril 2026: Foundry Local GA, GPT-5.5, CodeAct con Hyperlight

Foundry Local Está Disponible de Forma General

GPT-5.5

Trazado de Agent Framework en Foundry

CodeAct con Hyperlight (Alpha)

Panel de Monitoreo de Agentes (Vista Previa)

Evaluadores Personalizados de Evaluación Continua (Vista Previa)

Inventario de Agentes en el Plano de Control

Tu Agente MAF Local Acaba de Tener un Hogar en Producción

Lo Que Foundry Hosted Agents Realmente Hace

La Diferencia en el Código Es Mínima

Dos Protocolos, Un Agente

El Flujo de Despliegue con azd

Conclusión

Foundry Local 1.1: Transcripción en Tiempo Real, Embeddings y la API de Respuestas

Transcripción de Audio en Vivo

Embeddings de Texto

API de Respuestas

Mejoras en el Tamaño del Paquete

Por Qué Esto Importa

Cosmos DB Shell Está en Vista Previa Pública — Y Tiene un Servidor MCP Integrado

Qué lo Hace Diferente de Otras CLIs de Base de Datos

La Base de Código Abierto Importa

Tres Escenarios que Se Vuelven Más Fáciles

Para Empezar

Tu Agente de IA Tiene un Problema de Identidad (Y Aquí Está la Plantilla que lo Resuelve)

El Problema Central: Autenticación ≠ Autorización

Cómo Funciona la Cadena de Tokens

Qué Despliega la Plantilla

El Principio de Diseño que Vale la Pena Adoptar

Conclusión

Endpoints Privados, VNets, NSGs — Aspire Gestiona la Red Ahora

Los Bloques de Construcción

Describiéndolo en tu AppHost

Por Qué Importa para Aplicaciones Reales

Conclusión

Aspire 13.3: Soporte de Kubernetes, Registros del Navegador y la Habilidad Aspireify

Aspireify: Incorporación Asistida por Agente

Despliegue de Kubernetes y AKS de Primera Clase

Registros del Navegador en el Dashboard

Resultados de Comandos Estructurados

Conclusión

SDD Conference 2026

Temas

Ponentes

Entradas e información

Eliminando el Trabajo Tedioso de la Migración con Agentic Platform Engineering

La entrada: contoso-migration

Paso 1: Validación y autenticación

Paso 2: Extracción de intención

Paso 3: Mapeo de servicios

Paso 4: Agente crítico

Paso 5: Salida generada

Comparación de postura de seguridad

Qué lo diferencia de un convertidor de sintaxis

SQL MCP Server en Azure App Service — Sin Contenedores

¿Qué es el SQL MCP Server?

El Problema del Contenedor (y la Solución)

Autenticación Sin Claves de API Compartidas

Despliegue en App Service

Por qué Importa para los Desarrolladores .NET

Conclusión

SQL Server 2025 como Base de Datos Lista para Agentes: Seguridad, Backup y MCP en un Solo Motor

Un Modelo de Seguridad para Todos los Modelos de Datos

Backup Unificado = Recuperación Atómica

Integración MCP: Agentes Sin Middleware Codificado a Mano

Resumiendo

Azure SDK Abril 2026: AI Foundry 2.0 y Lo Que Deben Saber los Desarrolladores .NET

Azure.AI.Projects 2.0.0 — Cambios Breaking que Tienen Sentido

Cosmos DB Java: Corrección Crítica de Seguridad (RCE)

Nuevas Bibliotecas de Provisioning para .NET

Resumiendo

El Azure MCP Server Ahora es un .mcpb — Instálalo sin Ningún Runtime

¿Qué es un MCP Bundle?

Cómo instalarlo

Qué puedes hacer con él

¿Qué método de instalación usar?

Para empezar

GPT-5.5 Ya Está Aquí en Azure Foundry — Lo que los Desarrolladores .NET Necesitan Saber

El Flujo de Despliegue con `azd`