The .NET Blog

NDC Oslo 2026

Mon, 14 Sep 2026 00:00:00 +0000

NDC Oslo 2026 se celebra del 14 al 18 de septiembre de 2026 en Oslo Spektrum, Oslo, Noruega.

NDC Oslo es una de las conferencias de desarrolladores más grandes y respetadas de Europa, cubriendo todo, desde .NET y cloud hasta seguridad, arquitectura, IA y más. La edición 2026 está actualmente en fase de reservas, con una programación masiva en preparación.

En números

160 sesiones (en reserva)
150 ponentes (en reserva)
15 talleres (en reserva)
5 días — talleres + conferencia

Ponentes confirmados

La lista de ponentes se está completando, con nombres confirmados como:

Nick Chapsas
Maddy Montaquila
Troy Hunt
Kevlin Henney
Venkat Subramaniam
Jeff Fritz
Philippe De Ryck
Nhlanhla Lucky Nkosi
Aleksander Stensby

Entradas

Las entradas Early Bird están disponibles — la oferta Early Bird finaliza el 22 de mayo de 2026.

La convocatoria de ponencias (CFP) también está abierta.

Otros eventos NDC en 2026

NDC Sydney — 22–24 de abril, 2026
NDC Toronto — 5–8 de mayo, 2026
NDC Copenhagen — 1–4 de junio, 2026
NDC AI — 8–10 de junio, 2026
NDC TechTown — 21–24 de septiembre, 2026

Enlaces

.NET Day Switzerland 2026

Tue, 25 Aug 2026 00:00:00 +0000

.NET Day Switzerland 2026 se celebra el 25 de agosto de 2026 en Arena Cinemas Sihlcity (Kalanderplatz 8, 8045 Zúrich).

Es una conferencia comunitaria independiente y sin fines de lucro para desarrolladores, arquitectos y expertos, donde se habla de .NET, C#, ASP.NET Core, Azure y el ecosistema de desarrollo de Microsoft en general. Todos los ponentes y el personal colaboran de forma voluntaria, y cualquier excedente de la venta de entradas se destina a caridad o a la comunidad .NET suiza.

Qué incluye

Sesiones de alta calidad con expertos internacionales
Networking con otros participantes
Comida, snacks y bebidas durante las pausas, el almuerzo y el aperitivo
Oportunidades profesionales a través de interacciones con patrocinadores
Conversaciones directas con los ponentes durante las pausas

Entradas

Tipo	Precio	Disponibilidad
Very Early Bird (1–30 Abr)	299 CHF	Máx. 100 entradas
Early Bird	399 CHF	Máx. 100 entradas
Regular	449 CHF	Hasta agotar

Los ponentes y el programa aún no se han anunciado — la convocatoria está abierta en Sessionize.

Organizadores

Enlaces

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.

Actualización de Abril del Azure DevOps MCP Server: Consultas WIQL, Auth PAT y MCP Apps Experimental

Emiliano Montesdeoca — Mon, 27 Apr 2026 00:00:00 +0000

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

El Azure DevOps MCP Server sigue mejorando. La actualización de abril de Dan Hellem cubre tanto los servidores local como remoto, y hay algunas adiciones genuinamente útiles.

Soporte de Consultas WIQL

La nueva herramienta wit_query_by_wiql permite ejecutar consultas Work Item Query Language directamente desde tu cliente MCP. Tus sesiones de Copilot pueden ahora obtener conjuntos precisos de work items sin filtrar manualmente.

Personal Access Tokens en el Servidor Local

El servidor MCP local ahora soporta autenticación PAT — importante para escenarios de integración donde la autenticación interactiva no está disponible.

Anotaciones MCP en el Servidor Remoto

Etiquetas de metadatos para herramientas de solo lectura, destructivas y de mundo abierto — fundamentales para la fiabilidad de los agentes.

Consolidación de Herramientas Wiki

5 herramientas separadas de wiki → 2 herramientas más capaces. Menos herramientas = mejor rendimiento del LLM.

Experimental: MCP Apps

Flujos de trabajo empaquetados que se ejecutan dentro del entorno del servidor MCP. La idea es correcta — más composición de flujos de trabajo en la capa MCP, menos encadenamiento ad-hoc de herramientas.

Post original de Dan Hellem: Azure DevOps MCP Server April Update.

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.

¿Dónde Recuerda las Cosas tu Agente? Guía Práctica sobre el Almacenamiento del Historial de Chat

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

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

Cuando construyes un agente IA, dedicas la mayor parte de tu energía al modelo, las herramientas y los prompts. La pregunta de dónde vive el historial de conversación parece un detalle de implementación — pero es una de las decisiones arquitectónicas más importantes que tomarás.

Determina si los usuarios pueden bifurcar conversaciones, deshacer respuestas, reanudar sesiones después de un reinicio, y si tus datos salen alguna vez de tu infraestructura. El equipo de Agent Framework publicó un análisis en profundidad y vale la pena entender el panorama completo.

Dos patrones fundamentales

Gestionado por el servicio: el servicio de IA almacena el estado de la conversación. Tu app mantiene una referencia (un ID de hilo, un ID de respuesta) y el servicio incluye automáticamente el historial relevante en cada solicitud. Más simple de configurar. Menos control.

Gestionado por el cliente: tu app mantiene el historial completo y envía mensajes relevantes con cada solicitud. El servicio no tiene estado. Controlas todo.

Gestionado por servicio: lineal vs bifurcación

Lineal (hilo único): los mensajes forman una secuencia ordenada. Puedes añadir pero no bifurcar. Ideal para chatbots y flujos simples. Malo para “inténtalo de nuevo” o exploración paralela.

Con capacidad de bifurcación: cada respuesta tiene un ID único, y las nuevas solicitudes pueden referenciar cualquier respuesta anterior como punto de continuación. Esto es lo que soporta la API de Responses (Microsoft Foundry, Azure OpenAI, OpenAI). Permite bifurcar conversaciones y construir flujos de “deshacer”.

Cómo Agent Framework abstrae esto

// C# — funciona igual independientemente del proveedor
AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Me llamo Alice.", session);
var second = await agent.RunAsync("¿Cuál es mi nombre?", session);

# Python
session = agent.create_session()
first = await agent.run("Me llamo Alice.", session=session)
second = await agent.run("¿Cuál es mi nombre?", session=session)

La sesión maneja las diferencias subyacentes. Este desacoplamiento es valioso para experimentar con diferentes proveedores sin reescribir tu código.

Referencia rápida de proveedores

Proveedor	Almacenamiento	Modelo	Compactación
OpenAI/Azure Chat Completions	Cliente	N/A	Tú
Foundry Agent Service	Servicio	Lineal	Servicio
Responses API (por defecto)	Servicio	Bifurcación	Servicio
Responses API (`store=false`)	Cliente	N/A	Tú
Anthropic Claude, Ollama	Cliente	N/A	Tú

Cómo elegir

¿Necesitas bifurcación o “deshacer”? → Responses API gestionado por servicio
¿Necesitas soberanía total de datos? → Gestionado por cliente con proveedor respaldado por base de datos
¿Es un chatbot sencillo? → Lineal gestionado por servicio está bien
¿Necesitas portabilidad entre proveedores? → Gestionado por cliente da portabilidad

Lee el post completo para el árbol de decisión completo y los detalles de la API de Conversations.

.NET 10 Se Incluye con Ubuntu 26.04 LTS — Qué hay de Nuevo

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

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

Es el día de Ubuntu LTS. Ubuntu 26.04 (Resolute Raccoon) llegó hoy, y como con cada Ubuntu LTS, incluye el último .NET LTS — en este caso, .NET 10.

LTS sobre LTS — cinco años de soporte para el OS, alineados con la ventana de soporte a largo plazo de .NET 10.

Instala .NET 10 en dos comandos

sudo apt update
sudo apt install dotnet-sdk-10.0

.NET es uno de los toolchains oficialmente soportados en Ubuntu — no un add-on de terceros.

Pruébalo de inmediato

docker run --rm -it ubuntu:resolute
apt update
apt install -y dotnet-sdk-10.0
dotnet run - << 'EOF'
using System.Runtime.InteropServices;
Console.WriteLine($"Hello {RuntimeInformation.OSDescription} from .NET {RuntimeInformation.FrameworkDescription}");
EOF

Contenedores: actualiza `-noble` a `-resolute`

La migración es de una línea:

sed -i "s/noble/resolute/g" Dockerfile

Todos los sabores de imagen existentes — incluyendo Chiseled — están disponibles.

Native AOT: arranque en 3ms, binario de 1.4MB

apt install -y dotnet-sdk-aot-10.0 clang
dotnet publish app.cs
# artifacts/app/app — binario nativo de 1.4MB
# real 0m0.003s

Para cargas de trabajo cloud-native donde el tiempo de arranque en frío importa — Functions, contenedores, serverless — esto es un cambio real.

¿Necesitas .NET 8 o 9?

apt install -y software-properties-common
add-apt-repository ppa:dotnet/backports
apt install -y dotnet-sdk-8.0

El post completo tiene más detalles sobre cgroup v2, post-quantum cryptography y Linux 7.0.

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).

CodeAct en Agent Framework: Cómo Reducir la Latencia de tu Agente a la Mitad

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

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

Hay un momento en todo proyecto de agentes en que miras el trace y piensas: “¿por qué tarda tanto esto?” El modelo está bien. Las herramientas funcionan. Pero hay siete round trips para obtener un resultado que podría calcularse de una sola vez.

Ese es exactamente el problema que resuelve CodeAct — y el equipo de Agent Framework acaba de publicar soporte alpha para ello a través de un nuevo paquete agent-framework-hyperlight.

¿Qué es CodeAct?

El patrón CodeAct es elegantemente simple: en lugar de darle al modelo una lista de herramientas y dejar que las llame una por una, le das una única herramienta execute_code y le permites expresar el plan completo como un programa Python corto. El agente escribe el código una vez, el sandbox lo ejecuta, y obtienes de vuelta un único resultado consolidado.

Un plan de cinco pasos que antes requería cinco turnos del modelo ahora se convierte en un turno execute_code que contiene un script Python que llama a tus herramientas vía call_tool(...).

El benchmark del repositorio lo hace concreto. Ocho usuarios, docenas de pedidos, cinco herramientas (listar usuarios, obtener pedidos, tasa de descuento, tasa de impuesto, calcular total de línea). Mismo modelo, mismas herramientas, mismo prompt — solo cableado diferente:

Cableado	Tiempo	Tokens
Tradicional	27.81s	6.890
CodeAct	13.23s	2.489
Mejora	52,4%	63,9%

Eso no es un micro-benchmark. Es una carga de trabajo realista con overhead de orquestación real.

La pieza de seguridad: micro-VMs de Hyperlight

Aquí está lo que me entusiasmó realmente: la seguridad ha sido históricamente el talón de Aquiles de CodeAct. Si estás ejecutando código generado por el modelo, ¿exactamente dónde se ejecuta? ¿Contra tu proceso? ¿En un contenedor compartido?

El paquete agent-framework-hyperlight resuelve esto con micro-VMs de Hyperlight. Cada llamada execute_code obtiene su propia micro-VM recién creada — con su propia memoria, sin acceso al sistema de archivos del host más allá de lo que montes explícitamente, y sin acceso a la red más allá de los dominios que permitas. El arranque se mide en milisegundos. El aislamiento es prácticamente gratuito.

Tus herramientas siguen ejecutándose en el host (son tu código, con tu acceso). El pegamento generado por el modelo — el Python que decide qué herramientas llamar y en qué orden — se ejecuta en el sandbox. Esa es la división correcta.

Cómo conectarlo

La configuración mínima es sencilla:

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

result = await agent.run(
 "Get the weather for Seattle and Amsterdam and compare them."
)

El proveedor registra execute_code en cada ejecución e inyecta las instrucciones de CodeAct en el prompt del sistema automáticamente.

Mezclando CodeAct con herramientas que requieren aprobación

Aquí se pone interesante. No todas las herramientas deberían ejecutarse dentro del sandbox sin aprobación. Puede que quieras aprobar send_email o charge_credit_card individualmente. El framework maneja esto de forma limpia:

@tool(approval_mode="always_require")
def send_email(to: str, subject: str, body: str) -> str:
 """Send an email. Requires approval on every call."""
 ...

agent = Agent(
 client=client,
 name="MixedToolsAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
 tools=[send_email], # invocado directamente, con aprobación
)

Herramientas en el proveedor → el modelo las alcanza vía call_tool(...) dentro del sandbox, baratas y encadenables.
Herramientas directamente en el agente → el modelo las llama como herramientas de primera clase, la aprobación aplica individualmente.

Cuándo usar CodeAct (y cuándo no)

Usa CodeAct cuando:

La tarea encadena muchas llamadas pequeñas a herramientas (búsquedas, joins, cálculos, formateo)
Te importa la latencia y el costo de tokens
Quieres aislamiento fuerte por llamada en código generado por el modelo por defecto
Las herramientas son baratas y seguras para invocar en secuencia

Quédate con el tool-calling tradicional cuando:

El agente solo hace una o dos llamadas a herramientas por turno
Cada llamada a herramienta tiene efectos secundarios que quieres aprobar individualmente
Las descripciones de herramientas son escasas o ambiguas — CodeAct depende de buenos docstrings

Pruébalo ahora

pip install agent-framework-hyperlight --pre
# o
uv add --prerelease=allow agent-framework-hyperlight

Los ejemplos están en python/packages/hyperlight/samples/. El ejemplo de benchmark es el mejor punto de partida.

Vale la pena mencionar: Linux y Windows son compatibles hoy. El soporte para macOS está en camino. Un equivalente para .NET también está llegando.

Resumiendo

CodeAct no es magia — es un patrón sensato que era demasiado arriesgado de usar sin sandboxing adecuado. Hyperlight cambia esa ecuación. Aislamiento en micro-VM por llamada, arranque en milisegundos, mejora de latencia del 50%+ en las cargas de trabajo adecuadas. Vale la pena experimentar.

Consulta el post completo en el blog de Agent Framework para cobertura más profunda sobre montajes de sistema de archivos, política de red y el cableado independiente de HyperlightExecuteCodeTool.

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.

VS Code 1.118: Copilot CLI Obtiene Nombres de Sesión, Insignias de Modelo y TypeScript 7.0 Nightly

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

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

Visual Studio Code 1.118 es un lanzamiento pequeño y enfocado — principalmente refinamientos de Copilot CLI — pero hay algunas cosas a destacar.

Copilot CLI: las sesiones tienen nombres reales

Las APIs de título de sesión del SDK de Copilot CLI ahora se usan como fuente de verdad para los nombres de sesión. Antes obtenías etiquetas auto-generadas; ahora las sesiones muestran el nombre real del SDK. Mejora de calidad de vida que hace mucho menos confusa la navegación entre múltiples sesiones de agente.

Cambia de sesión más rápido con atajos de teclado

La app de Agents ahora tiene Ctrl+1, Ctrl+2, etc. asignados para cambiar rápidamente entre sesiones. Si estás ejecutando múltiples sesiones de Copilot CLI en paralelo, esto elimina mucho clic con el ratón.

Insignias de modelo en el chat

Las respuestas de Copilot CLI en el panel de chat ahora muestran una insignia de modelo — puedes ver de un vistazo qué modelo manejó cada solicitud.

Selección automática de modelo en Copilot CLI

La selección automática de modelo — previamente disponible en otras partes de Copilot — ahora funciona también en el agente Copilot CLI.

Opt-in a TypeScript 7.0 nightly

Ahora puedes optar por probar los nightly de TypeScript 7.0 directamente desde la configuración de VS Code. TypeScript 7.0 es un lanzamiento importante (la beta llegó hace unos días), y el path de opt-in facilita la prueba sin cambiar tu instalación global de TypeScript.

Bajo el capó: limpieza de `node-pty`

El SDK de Copilot CLI ahora resuelve node-pty desde VS Code via hostRequire en lugar de copiar binarios a la carpeta prebuilds del SDK. Cambio interno que simplifica la distribución.

Consulta las notas de versión completas.

Aspire 13.2: Soporte para Bun, Mejores Contenedores y Menos Fricción en el Debug

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

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

Si llevas tiempo construyendo backends .NET con frontends JavaScript en Aspire, la versión 13.2 es el tipo de actualización que mejora tu día sin anunciar grandes cambios. Sin nuevos paradigmas llamativos. Solo mejoras sólidas a cosas que eran levemente molestas.

Bun es Ahora Ciudadano de Primera Clase

La característica principal: soporte para Bun en apps Vite. Una llamada fluida, listo.

await builder
 .addViteApp("frontend", "./frontend")
 .withBun();

Si tu equipo ya usa Bun — con sus tiempos de instalación dramáticamente más rápidos — Aspire ya no te hace pelear contra la corriente.

Yarn es Más Confiable

Los usuarios de Yarn reciben algo igualmente importante: menos fallos misteriosos. Aspire 13.2 mejora la fiabilidad de withYarn() con addViteApp().

Mejoras en Contenedores

Pull Policy Explícita

const worker = await builder.addContainer("worker", "myorg/worker:latest")
 .withImagePullPolicy(ImagePullPolicy.Never);

Perfecto para flujos donde construyes imágenes localmente y quieres que Compose use exactamente esa sin ir al registry.

PostgreSQL 18+ Funciona Correctamente

PostgreSQL 18 cambió su estructura interna de directorios, lo que rompía silenciosamente el mapeo de volúmenes. Aspire 13.2 lo corrige.

Mejoras de Depuración

DebuggerDisplayAttribute en tipos core — valores útiles en el debugger en lugar de árboles de objetos
Mensajes de error más claros para WaitFor
BeforeResourceStartedEvent se dispara en el momento correcto

Resumiendo

Aspire 13.2 es una versión de calidad enfocada. Vale la pena actualizar, especialmente si usas PostgreSQL 18 con volúmenes de datos.

Post original de David Pine: Aspire 13.2: Bun Support and Container Enhancements.

¿68 Minutos al Día Re-Explicando Código a Copilot? Hay una Solución

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

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

¿Conoces ese momento en que tu sesión de Copilot llega al /compact y el agente olvida completamente lo que estabas haciendo? Pasas los siguientes cinco minutos re-explicando la estructura de archivos, el test fallido, los tres enfoques que ya intentaste. Y luego vuelve a pasar. Y otra vez.

Desi Villanueva lo midió: 68 minutos al día — solo en re-orientación. No escribiendo código. No revisando PRs. Solo poniéndole al día a la IA en cosas que ya sabía.

Resulta que hay una razón concreta por la que esto pasa, y una solución concreta.

La Mentira de la Ventana de Contexto

Tu agente viene con un número grande en la caja. 200K tokens. Suena masivo. En la práctica es un techo, no una garantía.

Aquí está la matemática real:

200K de contexto total
Menos ~65K para herramientas MCP cargadas al inicio (~33%)
Menos ~10K para archivos de instrucciones como AGENTS.md o copilot-instructions.md

Eso te deja aproximadamente 125K antes de escribir una sola palabra. Y empeora — los LLMs no se degradan de forma gradual al llenarse el contexto. Tienen un tope al llegar al 60% de capacidad. El modelo empieza a perder cosas mencionadas hace 30 turnos, contradice respuestas anteriores, alucina nombres de archivos que declaró con confianza hace 10 minutos. La industria llama a esto el problema del “lost in the middle”.

Límite efectivo: 45K tokens antes de que la calidad se degrade. Eso son tal vez 20-30 turnos de conversación activa antes de que el agente empiece a derivar. Por eso estás usando /compact cada 45 minutos — no porque hayas llenado 200K tokens, sino porque el modelo ya está “podrido” a los 120K.

El Impuesto de la Compactación

Cada /compact te cuesta el estado de flujo. Llevas 30 minutos en una sesión de depuración. El agente conoce la estructura de archivos, el test fallido, la hipótesis. Luego llega la advertencia.

Ignorarla → el agente se vuelve progresivamente más tonto, alucina el estado anterior
Ejecutar /compact → el agente tiene un resumen de 2 párrafos de una investigación de 30 minutos

De cualquier manera pierdes. De cualquier manera estás narrando tu propio proyecto como si fuera un empleado nuevo en su primer día.

La parte cruel: la memoria ya existe. Copilot CLI escribe cada sesión en una base de datos SQLite local en ~/.copilot/session-store.db — cada archivo tocado, cada turno, cada checkpoint. Todo está en el disco. El agente simplemente no puede leerlo.

auto-memory: Una Capa de Recall, No un Sistema de Memoria

Esa es la idea central detrás de auto-memory: no construyas un nuevo sistema de memoria — construye una capa de consulta de solo lectura sobre el que ya existe.

pip install auto-memory

~1.900 líneas de Python. Cero dependencias. Se instala en 30 segundos.

En lugar de inundar el contexto con resultados de grep, le das al agente acceso quirúrgico a lo que realmente importa:

Operación	Tokens	Qué obtienes
`grep -r "auth" src/`	~5.000–10.000	500 resultados, la mayoría irrelevantes
`find . -name "*.py"`	~2.000	Todos los archivos Python, sin contexto
Re-orientación del agente	~2.000	Tú explicando lo que ya debería saber
`auto-memory files --json --limit 10`	~50	Los 10 archivos que tocaste ayer

Una mejora de 200x. El agente se salta la excavación arqueológica y va directo a lo que importa.

¿Por Qué Importa Esto para Desarrolladores .NET?

Si usas GitHub Copilot CLI para trabajo con .NET — scaffolding de servicios, depuración de queries EF Core, iterando en componentes Blazor — el problema del context rot golpea igual de fuerte. Soluciones complejas con múltiples proyectos y librerías compartidas son exactamente el tipo de código donde el agente pierde el hilo más rápido.

Resumiendo

El context rot es una restricción arquitectónica real, no un bug que se parchará. auto-memory lo soluciona dándole a tu agente un mecanismo de recall barato y preciso en lugar de re-exploración costosa y ruidosa. Si haces desarrollo serio asistido por IA con GitHub Copilot CLI, vale la pena el install de 30 segundos.

Échale un vistazo: auto-memory en GitHub. Post original de Desi Villanueva: I Wasted 68 Minutes a Day Re-Explaining My Code.

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.

Hooks de azd en Python, TypeScript y .NET: adiós a los scripts de shell

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í.

Si alguna vez has tenido un proyecto completamente en .NET y aun así tuviste que escribir scripts Bash solo para los hooks de azd, conoces bien ese dolor. ¿Por qué cambiar a sintaxis de shell en un paso de pre-provisioning cuando todo lo demás en el proyecto es C#?

Esa frustración tiene solución oficial. La Azure Developer CLI acaba de lanzar soporte multi-lenguaje para hooks, y es exactamente tan bueno como suena.

Hooks, brevemente, por si no los conoces

Los hooks son scripts que se ejecutan en puntos clave del ciclo de vida de azd — antes del provisioning, después del despliegue, y más. Se definen en azure.yaml y permiten inyectar lógica personalizada sin modificar la CLI.

Antes solo se admitían Bash y PowerShell. Ahora puedes usar Python, JavaScript, TypeScript o .NET — y azd se encarga del resto automáticamente.

Cómo funciona la detección

Simplemente apuntas el hook a un archivo y azd infiere el lenguaje por la extensión:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Eso es todo. Sin config adicional. Si la extensión es ambigua, puedes añadir kind: python (o el que corresponda) para especificarlo explícitamente.

Detalles importantes por lenguaje

Python

Coloca un requirements.txt o pyproject.toml junto al script (o en cualquier directorio padre) y azd crea un entorno virtual, instala dependencias y ejecuta el script:

hooks/
├── setup.py
└── requirements.txt

Sin gestión manual de virtualenv. azd busca hacia arriba desde el script el archivo de proyecto más cercano.

JavaScript y TypeScript

El mismo patrón — pon un package.json cerca del script y azd ejecutará npm install primero. Para TypeScript, usa npx tsx sin paso de compilación ni tsconfig.json:

hooks/
├── seed.ts
└── package.json

¿Quieres usar pnpm o yarn? Hay una opción config.packageManager para eso.

.NET

Dos modos disponibles:

Modo proyecto: Si hay un .csproj junto al script, azd ejecuta dotnet restore y dotnet build automáticamente.
Modo single-file: En .NET 10+, puedes poner un archivo .cs independiente y se ejecuta directamente con dotnet run script.cs. Sin archivo de proyecto.

hooks:
 postprovision:
 run: ./hooks/migrate.cs

Si ya estás en .NET 10, el modo single-file es la opción más limpia para scripts simples de migración o seeding. Sin scaffolding, sin .csproj que mantener.

Config por ejecutor

Cada lenguaje soporta un bloque config opcional para ajustar los valores por defecto:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postdeploy:
 run: ./hooks/seed.py
 config:
 virtualEnvName: .venv
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

También puedes mezclar formatos en el mismo bloque hooks: — distintos lenguajes para distintos eventos del ciclo de vida, overrides por plataforma para Windows vs. Linux, lo que necesites.

Por qué importa para desarrolladores .NET

La respuesta aburrida es “consistencia”. Pero en la práctica va más allá. Los hooks eran el último lugar de un proyecto basado en azd que te obligaba a usar otro lenguaje. Ahora todo el pipeline de despliegue — código de app, scripts de infraestructura y hooks del ciclo de vida — puede vivir en un solo lenguaje.

Más concreto: puedes reutilizar tus utilidades .NET existentes en los hooks. ¿Tienes una librería compartida para gestión de esquemas de base de datos? Simplemente referencíala en el proyecto del hook. ¿Tienes un script Python de seeding que ya escribiste? Ponlo directamente en azure.yaml.

Conclusión

Es uno de esos cambios que parecen pequeños pero que eliminan mucha fricción del día a día con azd. El soporte multi-lenguaje para hooks ya está disponible — revisa el post oficial para la documentación completa y el repositorio de azd en GitHub para probarlo en tu próximo proyecto.

Windows App Dev CLI v0.3: F5 desde la terminal y automatización de UI para 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í.

La experiencia F5 de Visual Studio es fantástica. Pero tener que abrir VS solo para lanzar y depurar una app Windows empaquetada es excesivo cuando estás en un pipeline de CI, ejecutando un workflow automatizado, o — cada vez más — cuando un agente de IA está haciendo las pruebas.

Windows App Development CLI v0.3 acaba de salir y lo aborda directamente con dos funciones destacadas: winapp run y winapp ui.

winapp run: F5 desde cualquier sitio

winapp run toma una carpeta de app sin empaquetar y un manifiesto, y hace todo lo que VS hace en un debug launch: registra un paquete loose, lanza la app y preserva el LocalState entre re-deploys.

# Construye tu app, luego ejecútala como app empaquetada
winapp run ./bin/Debug

Funciona para WinUI, WPF, WinForms, Console, Avalonia y más. Los modos están pensados tanto para desarrolladores como para workflows automatizados:

--detach: Lanza y devuelve el control a la terminal inmediatamente. Perfecto para CI/automation.
--unregister-on-exit: Limpia el paquete registrado al cerrar la app. Ejecuciones de test limpias.
--debug-output: Captura mensajes OutputDebugString y excepciones en tiempo real. Añade --symbols para PDBs del Microsoft Symbol Server.

Nuevo paquete NuGet: dotnet run para apps empaquetadas

Para desarrolladores .NET hay un nuevo paquete NuGet: Microsoft.Windows.SDK.BuildTools.WinApp.

Añádelo al proyecto (o deja que winapp init lo haga), y dotnet run maneja todo el inner loop: build, preparar un paquete loose-layout, registrar en Windows y lanzar — todo en un paso.

# Deja que winapp init lo configure
winapp init

# O instala directamente
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

Funciona con WinUI, WPF, WinForms, Console, Avalonia. Sin comandos adicionales, sin registro manual. Solo dotnet run.

winapp ui: UI Automation desde la línea de comandos

Este es el que abre los escenarios agénticos. winapp ui te da acceso completo de UI Automation a cualquier app Windows en ejecución — WPF, WinForms, Win32, Electron, WinUI3 — todo desde la terminal.

Lo que puedes hacer:

Listar todas las ventanas de nivel superior
Navegar el árbol completo de UI Automation de cualquier ventana
Buscar elementos por nombre, tipo o ID de automatización
Hacer clic, invocar y establecer valores
Tomar capturas de pantalla
Esperar a que aparezcan elementos — ideal para sincronización de tests

Combina winapp ui con winapp run y tienes un workflow completo build → lanzar → verificar desde la terminal. Un agente puede ejecutar tu app, inspeccionar el estado de UI, interactuar con ella programáticamente y validar el resultado.

Otras novedades

winapp unregister: Elimina un paquete sideloaded cuando terminas.
winapp manifest add-alias: Añade un uap5:AppExecutionAlias para lanzar la app por nombre desde la terminal.
Tab completion: Configura completado con un solo comando para PowerShell.
Package.appxmanifest por defecto: Ahora winapp init crea Package.appxmanifest (convención VS) en lugar de appxmanifest.xml.

Cómo obtenerlo

winget install Microsoft.WinAppCli
# o
npm install -g @microsoft/winappcli

La CLI está en preview pública. Consulta el repositorio en GitHub para documentación completa y el anuncio original para todos los detalles.

Parchea Esto Ahora: Actualización de Seguridad OOB .NET 10.0.7 para ASP.NET Core Data Protection

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

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

Esta no es opcional. Si tu aplicación usa Microsoft.AspNetCore.DataProtection, necesitas actualizar a 10.0.7.

Qué Pasó

Después del lanzamiento de Patch Tuesday .NET 10.0.6, algunos usuarios reportaron que el descifrado fallaba. Mientras investigaban la regresión, el equipo descubrió que también exponía una vulnerabilidad de seguridad: CVE-2026-40372.

En versiones 10.0.0 a 10.0.6 de Microsoft.AspNetCore.DataProtection, el encriptador autenticado calculaba su etiqueta de validación HMAC sobre los bytes incorrectos del payload. Resultado: posible elevación de privilegios.

Cómo Solucionarlo

dotnet add package Microsoft.AspNetCore.DataProtection --version 10.0.7

Luego reconstruye y redespliega tu aplicación.

El Panorama General

Los lanzamientos OOB son poco comunes — ocurren cuando una vulnerabilidad es lo suficientemente seria para no esperar al próximo Patch Tuesday.

Anuncio original de Rahul Bhandari: .NET 10.0.7 Out-of-Band Security Update.

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í.

Escribir addons nativos de Node.js en C# con .NET Native AOT

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

Este es un escenario que me encanta: un equipo que trabaja en herramientas .NET tenía addons nativos de Node.js escritos en C++ y compilados con node-gyp. Funcionaba. Pero requería instalar Python en la máquina de cada desarrollador — una versión antigua de Python, nada menos — solo para construir un paquete que nadie del equipo tocaría directamente.

Así que se hicieron una pregunta muy razonable: ya tenemos el SDK de .NET instalado, ¿por qué escribimos C++ en absoluto?

La respuesta fue Native AOT, y el resultado es genuinamente elegante. Drew Noakes del equipo de C# Dev Kit documentó cómo lo hicieron, y creo que vale la pena entenderlo aunque no estés construyendo extensiones de VS Code.

La idea básica

Un addon nativo de Node.js es una biblioteca compartida (.dll en Windows, .so en Linux, .dylib en macOS) que Node.js puede cargar en tiempo de ejecución. La interfaz se llama N-API — una API C estable y compatible con ABI. A N-API no le importa qué lenguaje produjo la biblioteca, solo que exporte los símbolos correctos.

.NET Native AOT puede producir exactamente eso. Compila tu código C# ahead-of-time en una biblioteca nativa compartida con puntos de entrada arbitrarios. Ese es todo el truco.

Configuración del proyecto

El archivo de proyecto es mínimo:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net10.0</TargetFramework>
 <PublishAot>true</PublishAot>
 <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
 </PropertyGroup>
</Project>

PublishAot indica al SDK que produzca una biblioteca compartida al ejecutar dotnet publish. AllowUnsafeBlocks es necesario para el interop con N-API que usa punteros a funciones y buffers fijos.

Exportar el punto de entrada

Node.js espera que tu biblioteca exporte napi_register_module_v1. En C#, [UnmanagedCallersOnly] hace exactamente eso:

public static unsafe partial class RegistryAddon
{
 [UnmanagedCallersOnly(
 EntryPoint = "napi_register_module_v1",
 CallConvs = [typeof(CallConvCdecl)])]
 public static nint Init(nint env, nint exports)
 {
 Initialize();
 RegisterFunction(env, exports, "readStringValue"u8, &ReadStringValue);
 return exports;
 }
}

Algunas cosas que vale la pena señalar: nint es un entero de tamaño nativo — el equivalente gestionado de intptr_t. El sufijo u8 produce un ReadOnlySpan<byte> con un literal de cadena UTF-8, pasado directamente a N-API sin ninguna asignación de codificación. Y [UnmanagedCallersOnly] exporta el método con el nombre de punto de entrada exacto que Node.js busca.

Resolver N-API contra el proceso host

Las funciones de N-API las exporta node.exe en sí mismo, no una biblioteca separada. Así que en lugar de enlazar contra algo, las resuelves contra el proceso en ejecución al inicio:

private static void Initialize()
{
 NativeLibrary.SetDllImportResolver(
 System.Reflection.Assembly.GetExecutingAssembly(),
 ResolveDllImport);

 static nint ResolveDllImport(
 string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
 {
 if (libraryName is not "node") return 0;
 return NativeLibrary.GetMainProgramHandle();
 }
}

Con eso en su lugar, las declaraciones P/Invoke funcionan limpiamente, con [LibraryImport] y marshalling generado por código fuente.

Una función exportada real

Aquí está el lector de registro que construyeron — la función completa, desde leer argumentos hasta devolver un resultado:

[UnmanagedCallersOnly(CallConvs = [typeof(CallConvCdecl)])]
private static nint ReadStringValue(nint env, nint info)
{
 try
 {
 var keyPath = GetStringArg(env, info, 0);
 var valueName = GetStringArg(env, info, 1);

 if (keyPath is null || valueName is null)
 {
 ThrowError(env, "Expected two string arguments: keyPath, valueName");
 return 0;
 }

 using var key = Registry.CurrentUser.OpenSubKey(keyPath, writable: false);

 return key?.GetValue(valueName) is string value
 ? CreateString(env, value)
 : GetUndefined(env);
 }
 catch (Exception ex)
 {
 ThrowError(env, $"Registry read failed: {ex.Message}");
 return 0;
 }
}

Nota importante sobre el try/catch: una excepción no manejada en un método [UnmanagedCallersOnly] provoca el crash del proceso host. Siempre captura y reenvía a JavaScript mediante ThrowError.

Llamándolo desde TypeScript

interface RegistryAddon {
 readStringValue(keyPath: string, valueName: string): string | undefined;
}

const registry = require('./native/win32-x64/RegistryAddon.node') as RegistryAddon;

const sdkPath = registry.readStringValue(
 'SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\sdk',
 'InstallLocation'
);

TypeScript → C#, sin Python, sin C++.

Lo que ganaron

La victoria inmediata fue en la experiencia del contribuidor: ya no se necesita ninguna versión específica de Python, yarn install funciona solo con Node.js y el SDK de .NET. Los pipelines de CI también se simplificaron.

El rendimiento fue comparable a la implementación en C++. Native AOT produce código nativo optimizado, y para marshalling de cadenas y acceso al registro, la diferencia es insignificante.

Por qué me parece interesante más allá de las extensiones VS Code

Cualquier entorno que pueda cargar una biblioteca nativa compartida — apps Electron, extensiones Python vía ctypes, Rust vía FFI, Node.js vía N-API — es ahora un posible host para código C#. Para desarrolladores .NET que tenían escenarios de interop en mente pero no querían aprender un sistema de compilación C++, este patrón vale la pena conocerlo.

Conclusión

El equipo de C# Dev Kit reemplazó la sobrecarga de Python/C++ con código C# limpio que todo el equipo ya sabe escribir y depurar. Si quieres el recorrido completo con todos los helpers de marshalling de cadenas, consulta el artículo original en el blog de .NET.

VS Code 1.117: Los Agentes Están Obteniendo Sus Propias Ramas de Git y Estoy Totalmente a Favor

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

La línea entre “asistente de IA” y “compañero de equipo de IA” sigue haciéndose más delgada. VS Code 1.117 acaba de salir y las notas de la versión completas están cargadas, pero la historia está clara: los agentes se están convirtiendo en ciudadanos de primera clase en tu flujo de trabajo de desarrollo.

Esto es lo que realmente importa.

El modo Autopilot finalmente recuerda tu preferencia

Antes, tenías que volver a activar Autopilot cada vez que iniciabas una nueva sesión. Molesto. Ahora tu modo de permisos persiste entre sesiones y puedes configurar el valor por defecto.

El Agent Host soporta tres configuraciones de sesión:

Default — las herramientas piden confirmación antes de ejecutarse
Bypass — aprueba todo automáticamente
Autopilot — totalmente autónomo, responde sus propias preguntas y sigue adelante

Si estás creando un nuevo proyecto .NET con migraciones, Docker y CI — configúralo en Autopilot una vez y olvídate. Esa preferencia se mantiene.

Worktree y aislamiento de git para sesiones de agentes

Esta es la grande. Las sesiones de agentes ahora soportan aislamiento completo con worktrees y git. Eso significa que cuando un agente trabaja en una tarea, obtiene su propia rama y directorio de trabajo. Tu rama principal queda intacta.

Mejor aún — Copilot CLI genera nombres de rama significativos para estas sesiones de worktree. Se acabó el agent-session-abc123. Obtienes algo que realmente describe lo que el agente está haciendo.

Para desarrolladores .NET que manejan múltiples ramas de features o corrigen bugs mientras una tarea larga de scaffolding corre, esto es un cambio total. Puedes tener un agente construyendo tus controladores de API en un worktree mientras tú depuras un problema en la capa de servicios en otro. Sin conflictos. Sin stashing. Sin desorden.

Subagentes y equipos de agentes

El Agent Host Protocol ahora soporta subagentes. Un agente puede lanzar otros agentes para manejar partes de una tarea. Piénsalo como delegar — tu agente principal coordina, y agentes especializados se encargan de las piezas.

Esto es temprano, pero el potencial para flujos de trabajo .NET es obvio. Imagina un agente manejando tus migraciones de EF Core mientras otro configura tus pruebas de integración. No estamos totalmente ahí todavía, pero que el soporte del protocolo aterrice ahora significa que las herramientas vendrán rápido.

La salida del terminal se incluye automáticamente cuando los agentes envían input

Pequeño pero significativo. Cuando un agente envía input al terminal, la salida del terminal ahora se incluye automáticamente en el contexto. Antes, el agente tenía que hacer un turno extra solo para leer lo que pasó.

Si alguna vez viste a un agente ejecutar dotnet build, fallar, y luego tomar otro viaje de ida y vuelta solo para ver el error — esa fricción desapareció. Ve la salida inmediatamente y reacciona.

La app de Agents en macOS se auto-actualiza

La app independiente de Agents en macOS ahora se auto-actualiza. No más descargas manuales de nuevas versiones. Simplemente se mantiene al día.

Las cosas más pequeñas que vale la pena saber

Los hovers de package.json ahora muestran tanto la versión instalada como la última disponible. Útil si manejas herramientas npm junto con tus proyectos .NET.
Las imágenes en comentarios JSDoc se renderizan correctamente en hovers y completados.
Las sesiones de Copilot CLI ahora indican si fueron creadas por VS Code o externamente — práctico cuando saltas entre terminales.
Copilot CLI, Claude Code y Gemini CLI son reconocidos como tipos de shell. El editor sabe lo que estás ejecutando.

La conclusión

VS Code 1.117 no es un volcado de features llamativas. Es infraestructura. Aislamiento con worktrees, permisos persistentes, protocolos de subagentes — estos son los bloques de construcción para un flujo de trabajo donde los agentes manejan tareas reales y paralelas sin pisar tu código.

Si estás construyendo con .NET y todavía no te has metido en el flujo de trabajo con agentes, honestamente, ahora es el momento de empezar.

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.

Deja de vigilar tu terminal: el modo desacoplado de Aspire cambia el flujo de trabajo

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

Cada vez que ejecutas un AppHost de Aspire, tu terminal desaparece. Bloqueada. Ocupada hasta que presionas Ctrl+C. ¿Necesitas ejecutar un comando rápido? Abre otra pestaña. ¿Quieres revisar los logs? Otra pestaña. Es una pequeña fricción que se acumula rápido.

Aspire 13.2 soluciona esto. James Newton-King escribió todos los detalles, y honestamente, esta es una de esas funcionalidades que cambia inmediatamente tu forma de trabajar.

Modo desacoplado: un comando, terminal de vuelta

aspire start

Ese es el atajo para aspire run --detach. Tu AppHost arranca en segundo plano y recuperas tu terminal de inmediato. Sin pestañas extra. Sin multiplexor de terminal. Solo tu prompt, listo para usar.

Gestionando lo que está en ejecución

La cuestión es que ejecutar en segundo plano solo es útil si puedes gestionar lo que hay ahí fuera. Aspire 13.2 incluye un conjunto completo de comandos CLI para exactamente eso:

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

Esto convierte el CLI de Aspire en un gestor de procesos completo. Puedes iniciar múltiples AppHosts, verificar su estado, seguir sus logs y apagarlos — todo desde una sola sesión de terminal.

Combínalo con el modo aislado

El modo desacoplado se combina naturalmente con el modo aislado. ¿Quieres ejecutar dos instancias del mismo proyecto en segundo plano sin conflictos de puertos?

aspire start --isolated
aspire start --isolated

Cada uno obtiene puertos aleatorios, secretos separados y su propio ciclo de vida. Usa aspire ps para ver ambos, aspire stop para detener el que ya no necesites.

Por qué esto es enorme para los agentes de código

Aquí es donde se pone realmente interesante. Un agente de código trabajando en tu terminal ahora puede:

Iniciar la app con aspire start
Consultar su estado con aspire describe
Revisar logs con aspire logs para diagnosticar problemas
Detenerla con aspire stop cuando termine

Todo sin perder la sesión de terminal. Antes del modo desacoplado, un agente que ejecutara tu AppHost se bloqueaba a sí mismo en su propia terminal. Ahora puede iniciar, observar, iterar y limpiar — exactamente como querrías que funcione un agente autónomo.

El equipo de Aspire se volcó en esto. Ejecutar aspire agent init configura un archivo de habilidades de Aspire que enseña estos comandos a los agentes. Así, herramientas como el agente de código de Copilot pueden gestionar tus cargas de trabajo de Aspire directamente.

Para cerrar

El modo desacoplado es una mejora de flujo de trabajo disfrazada de un simple flag. Dejas de cambiar contexto entre terminales, los agentes dejan de bloquearse a sí mismos, y los nuevos comandos CLI te dan visibilidad real de lo que está en ejecución. Es práctico, es limpio, y hace que el ciclo de desarrollo diario sea notablemente más fluido.

Lee el post completo para todos los detalles y obtén Aspire 13.2 con aspire update --self.

Docker Sandbox permite a los agentes de Copilot refactorizar tu código sin poner en riesgo tu máquina

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

Si usaste el modo agente de Copilot para algo más que ediciones pequeñas, conocés el dolor. Cada escritura de archivo, cada comando en terminal — otro prompt de permisos. Ahora imaginá eso multiplicado por 50 proyectos. No es divertido.

El equipo de Azure acaba de publicar un post sobre Docker Sandbox para agentes de GitHub Copilot, y honestamente, es una de las mejoras más prácticas que he visto en herramientas agénticas. Usa microVMs para darle a Copilot un entorno completamente aislado donde puede hacer de todo — instalar paquetes, ejecutar builds, correr tests — sin tocar tu sistema host.

Qué te da realmente Docker Sandbox

La idea central es simple: levantar una microVM liviana con un entorno Linux completo, sincronizar tu workspace dentro de ella, y dejar que el agente de Copilot opere libremente adentro. Cuando termina, los cambios se sincronizan de vuelta.

Esto es lo que lo hace más que simplemente “ejecutar cosas en un contenedor”:

Sincronización bidireccional del workspace que preserva rutas absolutas. La estructura de tu proyecto se ve idéntica dentro del sandbox. Sin fallos de build por rutas.
Docker daemon privado corriendo dentro de la microVM. El agente puede construir y ejecutar contenedores sin montar jamás el socket de Docker de tu host. Eso es importante para la seguridad.
Proxies de filtrado HTTP/HTTPS que controlan lo que el agente puede alcanzar en la red. Vos decidís qué registries y endpoints están permitidos. ¿Ataques a la cadena de suministro por un npm install malicioso dentro del sandbox? Bloqueados.
Modo YOLO — sí, así lo llaman. El agente corre sin prompts de permisos porque literalmente no puede dañar tu host. Toda acción destructiva está contenida.

Por qué los desarrolladores .NET deberían prestar atención

Pensá en el trabajo de modernización que tantos equipos están enfrentando ahora mismo. Tenés una solución .NET Framework con 30 proyectos, y necesitás moverla a .NET 9. Son cientos de cambios en archivos — archivos de proyecto, actualizaciones de namespaces, reemplazos de APIs, migraciones de NuGet.

Con Docker Sandbox, podés apuntar un agente de Copilot a un proyecto, dejarlo refactorizar libremente dentro de la microVM, ejecutar dotnet build y dotnet test para validar, y solo aceptar los cambios que realmente funcionan. Sin riesgo de que accidentalmente destruya tu entorno de desarrollo local mientras experimenta.

El post también describe ejecutar una flota de agentes en paralelo — cada uno en su propio sandbox — trabajando en diferentes proyectos simultáneamente. Para soluciones .NET grandes o arquitecturas de microservicios, eso ahorra una cantidad enorme de tiempo. Un agente por servicio, todos corriendo aislados, todos validados independientemente.

El ángulo de seguridad importa

Acá está lo que la mayoría pasa por alto: cuando dejás que un agente de IA ejecute comandos arbitrarios, le estás confiando toda tu máquina. Docker Sandbox invierte ese modelo. El agente tiene autonomía total dentro de un entorno desechable. El proxy de red asegura que solo pueda descargar de fuentes aprobadas. Tu filesystem host, tu Docker daemon y tus credenciales quedan intactos.

Para equipos con requisitos de compliance — y eso es la mayoría de las empresas .NET — esta es la diferencia entre “no podemos usar IA agéntica” y “podemos adoptarla de forma segura”.

Conclusión

Docker Sandbox resuelve la tensión fundamental de la programación agéntica: los agentes necesitan libertad para ser útiles, pero libertad en tu máquina host es peligroso. Las microVMs te dan ambas cosas. Si estás planificando cualquier refactorización o modernización de .NET a gran escala, vale la pena configurar esto ahora. La combinación de la inteligencia de código de Copilot con un entorno de ejecución seguro es exactamente lo que los equipos de producción estaban esperando.

El clustering de pines por fin llega a .NET MAUI Maps — Una propiedad, cero complicaciones

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

¿Conoces ese momento en el que cargas un mapa con cien pines y todo se convierte en una mancha ilegible? Sí, esa ha sido la experiencia con .NET MAUI Maps hasta ahora. Se acabó.

David Ortinau acaba de anunciar que .NET MAUI 11 Preview 3 trae clustering de pines de serie en Android e iOS/Mac Catalyst. Y lo mejor — es ridículamente fácil de activar.

Una propiedad para gobernarlos a todos

<maps:Map IsClusteringEnabled="True" />

Eso es todo. Los pines cercanos se agrupan en clusters con un badge de cantidad. Haces zoom y se expanden. Alejas y se colapsan. El tipo de comportamiento que los usuarios esperan de cualquier mapa moderno — y ahora lo consigues con una sola propiedad.

Grupos de clustering independientes

Aquí es donde se pone interesante. No todos los pines deberían agruparse juntos. Las cafeterías y los parques son cosas distintas, y tu mapa debería saberlo.

La propiedad ClusteringIdentifier te permite separar pines en grupos independientes:

map.Pins.Add(new Pin
{
 Label = "Pike Place Coffee",
 Location = new Location(47.6097, -122.3331),
 ClusteringIdentifier = "coffee"
});

map.Pins.Add(new Pin
{
 Label = "Occidental Square",
 Location = new Location(47.6064, -122.3325),
 ClusteringIdentifier = "parks"
});

Los pines con el mismo identificador se agrupan juntos. Identificadores diferentes forman clusters independientes incluso cuando están geográficamente cerca. ¿Sin identificador? Grupo por defecto. Limpio y predecible.

Manejo de taps en clusters

Cuando un usuario toca un cluster, recibes un evento ClusterClicked con todo lo que necesitas:

map.ClusterClicked += async (sender, e) =>
{
 string names = string.Join("\n", e.Pins.Select(p => p.Label));
 await DisplayAlert(
 $"Cluster ({e.Pins.Count} pins)",
 names,
 "OK");

 // Suppress default zoom-to-cluster behavior:
 // e.Handled = true;
};

Los argumentos del evento te dan Pins (los pines del cluster), Location (el centro geográfico) y Handled (ponlo a true si quieres anular el zoom por defecto). Simple, práctico, exactamente lo que esperarías.

Detalles de plataforma que vale la pena conocer

En Android, el clustering usa un algoritmo personalizado basado en rejilla que recalcula con los cambios de zoom — sin dependencias externas. En iOS y Mac Catalyst, aprovecha el soporte nativo de MKClusterAnnotation de MapKit, lo que significa animaciones suaves y nativas de la plataforma.

Este es uno de esos casos en los que el equipo de MAUI tomó la decisión correcta — apoyarse en la plataforma donde tiene sentido.

Por qué esto importa

El clustering de pines ha sido una de las características más solicitadas en .NET MAUI (issue #11811), y con razón. Todas las apps que muestran ubicaciones en un mapa — seguimiento de envíos, localizadores de tiendas, bienes raíces — lo necesitan. Antes tenías que construirlo tú mismo o recurrir a una librería de terceros. Ahora viene integrado.

Para nosotros los desarrolladores .NET que construimos apps móviles multiplataforma, este es el tipo de mejora de calidad de vida que hace de MAUI una opción genuinamente práctica para escenarios con uso intensivo de mapas.

Empieza ya

Instala .NET 11 Preview 3 y actualiza el workload de .NET MAUI. El ejemplo de Maps incluye una nueva página de Clustering con la que puedes jugar de inmediato.

Ve y construye algo con ello — y deja que tus mapas por fin respiren.

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.

.NET Abril 2026 Servicing — Parches de seguridad que deberías aplicar hoy

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

Las actualizaciones de servicing de abril 2026 para .NET y .NET Framework ya están disponibles, y esta incluye correcciones de seguridad que vas a querer aplicar pronto. Seis CVEs parcheados, incluyendo dos vulnerabilidades de ejecución remota de código (RCE).

Qué se ha parcheado

Aquí va el resumen rápido:

CVE	Tipo	Afecta a
CVE-2026-26171	Omisión de característica de seguridad	.NET 10, 9, 8 + .NET Framework
CVE-2026-32178	Ejecución remota de código	.NET 10, 9, 8 + .NET Framework
CVE-2026-33116	Ejecución remota de código	.NET 10, 9, 8
CVE-2026-32203	Denegación de servicio	.NET 10, 9, 8 + .NET Framework
CVE-2026-23666	Denegación de servicio	.NET Framework 3.0–4.8.1
CVE-2026-32226	Denegación de servicio	.NET Framework 2.0–4.8.1

Los dos CVEs de RCE (CVE-2026-32178 y CVE-2026-33116) afectan al mayor rango de versiones de .NET y deberían ser la prioridad.

Versiones actualizadas

.NET 10: 10.0.6
.NET 9: 9.0.15
.NET 8: 8.0.26

Todas están disponibles a través de los canales habituales — dotnet.microsoft.com, imágenes de contenedores en MCR y gestores de paquetes de Linux.

Qué hacer

Actualiza tus proyectos y pipelines de CI/CD a las últimas versiones parcheadas. Si estás corriendo contenedores, descarga las últimas imágenes. Si estás en .NET Framework, revisa las notas de versión de .NET Framework para los parches correspondientes.

Para quienes están corriendo .NET 10 en producción (es la versión actual), 10.0.6 es una actualización obligatoria. Lo mismo para .NET 9.0.15 y .NET 8.0.26 si estás en esas versiones LTS. Dos vulnerabilidades de RCE no son algo que se pospone.

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 DevOps Server Parche Abril 2026 — Corrección en Completado de PRs y Actualizaciones de Seguridad

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

Aviso rápido para equipos que ejecutan Azure DevOps Server en sus propios servidores: Microsoft lanzó el Parche 3 de abril 2026 con tres correcciones específicas.

Qué se corrigió

Fallos en el completado de pull requests — una excepción de referencia nula durante el auto-completado de work items podía hacer que los merges de PRs fallaran. Si te topaste con errores aleatorios al completar PRs, esta es probablemente la causa
Validación en la redirección de cierre de sesión — se mejoró la validación durante el cierre de sesión para prevenir posibles redirecciones maliciosas. Esta es una corrección de seguridad que vale la pena aplicar pronto
Conexiones PAT con GitHub Enterprise Server — la creación de conexiones con Personal Access Token hacia GitHub Enterprise Server estaba rota, ahora se restauró

Cómo actualizar

Descarga el Parche 3 y ejecuta el instalador. Para verificar que el parche se aplicó:

<patch-installer>.exe CheckInstall

Si estás ejecutando Azure DevOps Server en tus propias instalaciones, Microsoft recomienda encarecidamente mantenerse en el último parche tanto por seguridad como por fiabilidad. Consulta las notas de la versión para todos los detalles.

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.

.NET Aspire 13.2 Quiere Ser el Mejor Amigo de Tu Agente de IA

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

¿Conoces ese momento cuando tu agente de IA escribe código sólido, te emocionas, y luego todo se desmorona cuando intenta ejecutar la cosa? Conflictos de puertos, procesos fantasma, variables de entorno incorrectas — de repente tu agente está quemando tokens depurando problemas de arranque en vez de construir funcionalidades.

El equipo de Aspire acaba de publicar un post muy bien pensado sobre exactamente este problema, y su respuesta es convincente: Aspire 13.2 está diseñado no solo para humanos, sino para agentes de IA.

El problema es real

Los agentes de IA son increíbles escribiendo código. Pero enviar una app full-stack funcional involucra mucho más que generar archivos. Necesitas iniciar servicios en el orden correcto, gestionar puertos, configurar variables de entorno, conectar bases de datos y obtener retroalimentación cuando algo se rompe. Ahora mismo, la mayoría de agentes manejan todo esto por prueba y error — ejecutando comandos, leyendo errores, intentando de nuevo.

Le metemos instrucciones en Markdown, skills personalizados y prompts para guiarlos, pero son impredecibles, no se pueden compilar y cuestan tokens solo para parsear. El equipo de Aspire dio en el clavo con la idea central: los agentes necesitan compiladores y APIs estructuradas, no más Markdown.

Aspire como infraestructura para agentes

Esto es lo que Aspire 13.2 trae a la mesa del desarrollo agéntico:

Todo tu stack en código tipado. El AppHost define tu topología completa — API, frontend, base de datos, caché — en TypeScript o C# compilable:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

Un agente puede leer esto para entender la topología de la app, agregar recursos, conectar componentes y compilar para verificar. El compilador le dice inmediatamente si algo está mal. Sin adivinanzas, sin prueba y error con archivos de configuración.

Un solo comando para gobernarlos a todos. En vez de que los agentes malabareen docker compose up, npm run dev y scripts de arranque de bases de datos, todo es simplemente aspire start. Todos los recursos se lanzan en el orden correcto, en los puertos correctos, con la configuración correcta. Los procesos de larga duración tampoco cuelgan al agente — Aspire los gestiona.

Modo aislado para agentes en paralelo. Con --isolated, cada ejecución de Aspire obtiene sus propios puertos aleatorios y secretos de usuario separados. ¿Tienes múltiples agentes trabajando en git worktrees? No colisionarán. Esto es enorme para herramientas como los agentes en segundo plano de VS Code que crean entornos paralelos.

Ojos de agente a través de telemetría. Aquí es donde se pone realmente potente. El CLI de Aspire expone datos OpenTelemetry completos durante el desarrollo — trazas, métricas, logs estructurados. Tu agente no solo lee la salida de consola esperando lo mejor. Puede rastrear una petición fallida entre servicios, perfilar endpoints lentos e identificar exactamente dónde se rompen las cosas. Eso es observabilidad de nivel producción en el ciclo de desarrollo.

La analogía de los parachoques de boliche

El equipo de Aspire usa una gran analogía: piensa en Aspire como los parachoques de una pista de boliche para agentes de IA. Si el agente no es perfecto (y no lo será), los parachoques evitan que tire canaletas. La definición del stack previene mala configuración, el compilador atrapa errores, el CLI maneja la gestión de procesos y la telemetría provee el ciclo de retroalimentación.

Combina esto con algo como Playwright CLI, y tu agente puede realmente usar tu app — haciendo clic en flujos, revisando el DOM, viendo cosas rotas en telemetría, arreglando el código, reiniciando y probando de nuevo. Construir, ejecutar, observar, arreglar. Ese es el ciclo de desarrollo autónomo que hemos estado persiguiendo.

Primeros pasos

¿Nuevo en Aspire? Instala el CLI desde get.aspire.dev y sigue la guía de inicio.

¿Ya usas Aspire? Ejecuta aspire update --self para obtener la 13.2, luego apunta tu agente de código favorito a tu repo. Te sorprenderá lo mucho más lejos que llega con los guardrails de Aspire.

Para cerrar

Aspire 13.2 ya no es solo un framework para aplicaciones distribuidas — se está convirtiendo en infraestructura esencial para agentes. Definiciones de stack estructuradas, arranque con un comando, ejecuciones paralelas aisladas y telemetría en tiempo real le dan a los agentes de IA exactamente lo que necesitan para pasar de escribir código a enviar apps.

Lee el post completo del equipo de Aspire para todos los detalles y videos de demostración.

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.

El Modo Aislado de Aspire Resuelve la Pesadilla de Conflictos de Puertos en Desarrollo Paralelo

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

Si alguna vez intentaste ejecutar dos instancias del mismo proyecto al mismo tiempo, conoces el dolor. El puerto 8080 ya está en uso. El puerto 17370 está ocupado. Mata algo, reinicia, malabarea variables de entorno — es un asesino de productividad.

Este problema está empeorando, no mejorando. Los agentes de IA crean git worktrees para trabajar de forma independiente. Los agentes en segundo plano levantan entornos separados. Los desarrolladores hacen checkout del mismo repo dos veces para ramas de funcionalidades. Cada uno de estos escenarios choca con la misma pared: dos instancias de la misma app peleando por los mismos puertos.

Aspire 13.2 resuelve esto con un solo flag. James Newton-King del equipo de Aspire escribió todos los detalles, y es una de esas funcionalidades de “¿por qué no teníamos esto antes?”

La solución: `--isolated`

aspire run --isolated

Eso es todo. Cada ejecución obtiene:

Puertos aleatorios — no más colisiones entre instancias
Secretos de usuario aislados — cadenas de conexión y claves API permanecen separados por instancia

Sin reasignación manual de puertos. Sin malabarismo de variables de entorno. Cada ejecución obtiene un entorno limpio y libre de colisiones automáticamente.

Escenarios reales donde esto brilla

Múltiples checkouts. Tienes una rama de funcionalidad en un directorio y un bugfix en otro:

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

Ambos se ejecutan sin conflictos. El dashboard muestra qué está corriendo y dónde.

Agentes en segundo plano en VS Code. Cuando el agente en background de Copilot Chat crea un git worktree para trabajar en tu código de forma independiente, puede necesitar ejecutar tu AppHost de Aspire. Sin --isolated, eso es una colisión de puertos con tu worktree principal. Con él, ambas instancias simplemente funcionan.

El skill de Aspire que viene con aspire agent init instruye automáticamente a los agentes a usar --isolated cuando trabajan en worktrees. Así que el agente en background de Copilot debería manejar esto de forma nativa.

Tests de integración junto al desarrollo. ¿Necesitas ejecutar tests contra un AppHost en vivo mientras sigues construyendo funcionalidades? El modo aislado le da a cada contexto sus propios puertos y configuración.

Cómo funciona internamente

Cuando pasas --isolated, el CLI genera un ID de instancia único para la ejecución. Esto impulsa dos comportamientos:

Aleatorización de puertos — en vez de vincularse a puertos predecibles definidos en la configuración de tu AppHost, el modo aislado elige puertos aleatorios disponibles para todo — el dashboard, los endpoints de servicio, todo. El service discovery se ajusta automáticamente, así que los servicios se encuentran entre sí sin importar qué puertos les tocaron.
Aislamiento de secretos — cada ejecución aislada obtiene su propio almacén de secretos de usuario, identificado por el ID de instancia. Las cadenas de conexión y claves API de una ejecución no se filtran a otra.

Tu código no necesita cambios. El service discovery de Aspire resuelve los endpoints en tiempo de ejecución, así que todo se conecta correctamente sin importar la asignación de puertos.

Cuándo usarlo

Usa --isolated cuando ejecutes múltiples instancias del mismo AppHost simultáneamente — ya sea desarrollo paralelo, tests automatizados, agentes de IA o git worktrees. Para desarrollo de instancia única donde prefieras puertos predecibles, el aspire run regular sigue funcionando bien.

Para cerrar

El modo aislado es una funcionalidad pequeña que resuelve un problema real y cada vez más común. A medida que el desarrollo asistido por IA nos empuja hacia más flujos paralelos — múltiples agentes, múltiples worktrees, múltiples contextos — la capacidad de simplemente levantar otra instancia sin pelear por puertos es esencial.

Lee el post completo para todos los detalles técnicos y pruébalo con aspire update --self para obtener la 13.2.

Esa Configuración de Ventanas Flotantes de Visual Studio Que No Conocías (Pero Deberías)

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

Si usas múltiples monitores con Visual Studio (y honestamente, ¿quién no lo hace hoy en día?), probablemente hayas experimentado la molestia: las ventanas flotantes de herramientas desaparecen cuando minimizas el IDE principal, siempre se quedan encima de todo lo demás, y no aparecen como botones separados en la barra de tareas. Funciona para algunos flujos de trabajo, pero para configuraciones con múltiples monitores es frustrante.

Mads Kristensen del equipo de Visual Studio compartió una configuración poco conocida que cambia completamente cómo se comportan las ventanas flotantes. Un desplegable. Eso es todo.

La configuración

Tools > Options > Environment > Windows > Floating Windows

El desplegable “These floating windows are owned by the main window” tiene tres opciones:

None — independencia total. Cada ventana flotante tiene su propia entrada en la barra de tareas y se comporta como una ventana normal de Windows.
Tool Windows (predeterminado) — los documentos flotan libremente, las ventanas de herramientas quedan vinculadas al IDE.
Documents and Tool Windows — comportamiento clásico de Visual Studio, todo vinculado a la ventana principal.

Por qué “None” es la mejor opción para configuraciones con múltiples monitores

Configúralo en None y de repente todas tus ventanas flotantes de herramientas y documentos se comportan como aplicaciones reales de Windows. Aparecen en la barra de tareas, permanecen visibles cuando minimizas la ventana principal de Visual Studio, y dejan de forzarse al frente de todo.

Combina esto con PowerToys FancyZones y es un cambio total. Crea diseños personalizados a través de tus monitores, coloca tu Explorador de Soluciones en una zona, el depurador en otra, y los archivos de código donde quieras. Todo se mantiene en su lugar, todo es accesible de forma independiente, y tu espacio de trabajo se siente organizado en lugar de caótico.

Recomendaciones rápidas

Usuarios avanzados con múltiples monitores: Configura en None, combina con FancyZones
Flotadores ocasionales: Tool Windows (predeterminado) es un buen punto medio
Flujo de trabajo tradicional: Documents and Tool Windows mantiene todo clásico

Consejo pro: Ctrl + doble clic en la barra de título de cualquier ventana de herramientas para flotarla o anclarla instantáneamente. No se necesita reiniciar después de cambiar la configuración.

Conclusión

Es una de esas configuraciones de “no puedo creer que no lo sabía”. Si las ventanas flotantes en Visual Studio alguna vez te han molestado, ve a cambiar esto ahora mismo.

Lee el post completo para los detalles y capturas de pantalla.

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.

Las MCP Apps tienen una API fluida — Construye interfaces ricas para herramientas de IA en .NET en tres pasos

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

Las herramientas MCP son geniales para darle capacidades a los agentes de IA. Pero ¿qué pasa si tu herramienta necesita mostrarle algo al usuario — un dashboard, un formulario, una visualización interactiva? Ahí es donde entran las MCP Apps, y ahora son mucho más fáciles de construir.

Lilian Kasem del equipo de Azure SDK presentó la nueva API de configuración fluida para MCP Apps en Azure Functions con .NET, y es el tipo de mejora en experiencia de desarrollador que te hace preguntarte por qué no fue siempre así de simple.

¿Qué son las MCP Apps?

Las MCP Apps extienden el Model Context Protocol permitiendo que las herramientas lleven sus propias vistas de UI, assets estáticos y controles de seguridad. En lugar de solo devolver texto, tu herramienta MCP puede renderizar experiencias HTML completas — dashboards interactivos, visualizaciones de datos, formularios de configuración — todo invocable por agentes de IA y presentado a los usuarios por clientes MCP.

El problema era que conectar todo esto manualmente requería conocer la especificación MCP a fondo: URIs ui://, tipos MIME especiales, coordinación de metadatos entre herramientas y recursos. No era difícil, pero sí tedioso.

La API fluida en tres pasos

Paso 1: Define tu función. Una herramienta MCP de Azure Functions estándar:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Paso 2: Promuévela a MCP App. En el startup de tu programa:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Paso 3: Añade tu vista HTML. Crea assets/hello-app.html con la interfaz que necesites.

Eso es todo. La API fluida se encarga de toda la plomería del protocolo MCP — genera la función de recurso sintético, establece el tipo MIME correcto e inyecta los metadatos que conectan tu herramienta con su vista.

La superficie de la API está bien diseñada

Algunas cosas que me gustan mucho:

Las fuentes de las vistas son flexibles. Puedes servir HTML desde archivos en disco, o embeber recursos directamente en tu ensamblado para despliegues autónomos:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

El CSP es componible. Explícitamente permites los orígenes que tu app necesita, siguiendo principios de mínimo privilegio. Llama a WithCsp varias veces y los orígenes se acumulan:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Control de visibilidad. Puedes hacer que una herramienta sea visible solo para el LLM, solo para la UI del host, o ambos. ¿Quieres una herramienta que solo renderice UI y no deba ser llamada por el modelo? Fácil:

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

Primeros pasos

Añade el paquete preview:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

Si ya estás construyendo herramientas MCP con Azure Functions, esto es solo una actualización de paquete. El quickstart de MCP Apps es el mejor lugar para empezar si eres nuevo en el concepto.

Para cerrar

Las MCP Apps son uno de los desarrollos más emocionantes en el espacio de herramientas de IA — herramientas que no solo hacen cosas sino que pueden mostrar cosas a los usuarios. La API fluida elimina la complejidad del protocolo y te permite enfocarte en lo que importa: la lógica de tu herramienta y su interfaz.

Lee el post completo para la referencia completa de la API y ejemplos.

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.

VS Code 1.116 — La App de Agentes Obtiene Navegación por Teclado y Autocompletado de Contexto de Archivos

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

VS Code 1.116 es la versión de abril de 2026, y aunque es más ligera que algunas actualizaciones recientes, los cambios son enfocados y significativos — especialmente si estás usando la app de Agentes a diario.

Esto es lo que llegó, basado en las notas de la versión oficial.

Mejoras en la app de Agentes

La app de Agentes sigue madurando con pulido de usabilidad que marca una diferencia real en los flujos de trabajo diarios:

Atajos de teclado dedicados — ahora puedes enfocar la vista de Cambios, el árbol de archivos dentro de Cambios, y la vista de Personalizaciones del Chat con comandos dedicados y atajos de teclado. Si has estado haciendo clic por toda la app de Agentes para navegar, esto trae flujos de trabajo completamente controlados por teclado.

Diálogo de ayuda de accesibilidad — presionar Alt+F1 en el cuadro de entrada del chat ahora abre un diálogo de ayuda de accesibilidad que muestra los comandos y atajos disponibles. Los usuarios de lectores de pantalla también pueden controlar la verbosidad de los anuncios. La buena accesibilidad beneficia a todos.

Autocompletado de contexto de archivos — escribe # en el chat de la app de Agentes para activar el autocompletado de contexto de archivos dentro de tu espacio de trabajo actual. Esta es una de esas pequeñas mejoras de calidad de vida que aceleran cada interacción — no más escribir rutas completas de archivos al referenciar código.

Resolución de enlaces CSS `@import`

Una buena para los desarrolladores frontend: VS Code ahora resuelve las referencias CSS @import que usan rutas de node_modules. Puedes hacer Ctrl+clic a través de imports como @import "some-module/style.css" cuando usas bundlers. Pequeño pero elimina un punto de fricción en los flujos de trabajo CSS.

Conclusión

VS Code 1.116 trata sobre refinamiento — hacer la app de Agentes más navegable, más accesible y más amigable con el teclado. Si pasas tiempo significativo en la app de Agentes (y sospecho que muchos de nosotros lo hacemos), estos cambios se acumulan.

Revisa las notas de la versión completas para la lista completa.

VS Code 1.115 — Notificaciones de Terminal en Segundo Plano, Modo Agente SSH y Más

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

VS Code 1.115 acaba de lanzarse, y aunque es una versión más ligera en cuanto a funcionalidades destacadas, las mejoras relacionadas con agentes son genuinamente útiles si trabajás con asistentes de código con IA todos los días.

Déjame resaltar lo que realmente vale la pena saber.

Las terminales en segundo plano ahora se comunican con los agentes

Esta es la funcionalidad estrella. Las terminales en segundo plano ahora notifican automáticamente a los agentes cuando los comandos terminan, incluyendo el código de salida y la salida de la terminal. Las solicitudes de entrada en terminales en segundo plano también se detectan y se muestran al usuario.

¿Por qué importa esto? Si usaste el modo agente de Copilot para ejecutar comandos de compilación o suites de tests en segundo plano, conocés el dolor del “¿ya terminó eso?” — las terminales en segundo plano eran básicamente disparar-y-olvidar. Ahora el agente recibe una notificación cuando tu dotnet build o dotnet test termina, ve la salida y puede reaccionar en consecuencia. Es un cambio pequeño que hace que los flujos de trabajo impulsados por agentes sean significativamente más confiables.

También hay una nueva herramienta send_to_terminal que permite a los agentes enviar comandos a terminales en segundo plano con confirmación del usuario, solucionando el problema donde run_in_terminal con un timeout movía las terminales al segundo plano y las dejaba como solo lectura.

Hosting remoto de agentes por SSH

VS Code ahora soporta conectarse a máquinas remotas por SSH, instalando automáticamente el CLI e iniciándolo en modo host de agentes. Esto significa que tus sesiones de agentes de IA pueden apuntar a entornos remotos directamente — útil para desarrolladores .NET que compilan y prueban en servidores Linux o VMs en la nube.

Seguimiento de ediciones en sesiones de agentes

Las ediciones de archivos realizadas durante sesiones de agentes ahora se rastrean y restauran, con diffs, deshacer/rehacer y restauración de estado. Si un agente hace cambios en tu código y algo sale mal, podés ver exactamente qué cambió y revertirlo. Tranquilidad para dejar que los agentes modifiquen tu codebase.

Reconocimiento de pestañas del navegador y otras mejoras

Algunas mejoras adicionales de calidad de vida:

Seguimiento de pestañas del navegador — el chat ahora puede rastrear y enlazar a pestañas del navegador abiertas durante una sesión, para que los agentes puedan referenciar páginas web que estás viendo
Pegado de archivos en la terminal — pegá archivos (incluyendo imágenes) en la terminal con Ctrl+V, arrastrar y soltar, o clic derecho
Cobertura de tests en el minimapa — los indicadores de cobertura de tests ahora se muestran en el minimapa para una vista visual rápida
Pellizcar para zoom en Mac — el navegador integrado soporta gestos de pellizcar para zoom
Derechos de Copilot en Sesiones — la barra de estado muestra información de uso en la vista de Sesiones
Favicon en Ir a Archivo — las páginas web abiertas muestran favicons en la lista de selección rápida

Conclusión

VS Code 1.115 es una versión incremental, pero las mejoras de agentes — notificaciones de terminal en segundo plano, hosting de agentes por SSH y seguimiento de ediciones — se suman a una experiencia notablemente más fluida para el desarrollo asistido por IA. Si estás usando el modo agente de Copilot para proyectos .NET, estos son el tipo de mejoras de calidad de vida que reducen la fricción diaria.

Mirá las notas de la versión completas para cada detalle.

C# 15 trae los tipos unión — y son exactamente lo que estábamos pidiendo

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

Esta es la que estuve esperando. C# 15 introduce la palabra clave union — uniones discriminadas con coincidencia de patrones exhaustiva impuesta por el compilador. Si alguna vez envidiaste las uniones discriminadas de F# o los enums de Rust, sabés exactamente por qué esto importa.

Bill Wagner publicó el análisis a fondo en el blog de .NET, y sinceramente? El diseño es limpio, práctico y muy C#. Déjame mostrarte qué hay realmente y por qué es más importante de lo que parece a primera vista.

El problema que resuelven las uniones

Antes de C# 15, devolver “uno de varios tipos posibles” desde un método siempre era un compromiso:

object — sin restricciones, sin ayuda del compilador, casting defensivo por todos lados
Interfaces marcadoras — mejor, pero cualquiera puede implementarlas. El compilador nunca puede considerar el conjunto completo
Clases base abstractas — mismo problema, además los tipos necesitan un ancestro común

Ninguna de estas opciones te da lo que realmente querés: un conjunto cerrado de tipos donde el compilador garantiza que manejaste todos los casos. Eso es lo que hacen los tipos unión.

La sintaxis es hermosamente simple

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

Una línea. Pet puede contener un Cat, un Dog o un Bird. Las conversiones implícitas se generan automáticamente:

Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }

Y acá está la magia — el compilador impone la coincidencia exhaustiva:

string name = pet switch
{
 Dog d => d.Name,
 Cat c => c.Name,
 Bird b => b.Name,
};

No se necesita descarte _. El compilador sabe que este switch cubre todos los casos posibles. Si después agregás un cuarto tipo a la unión, cada expresión switch que no lo maneje produce una advertencia. Casos faltantes detectados en tiempo de compilación, no en tiempo de ejecución.

Donde esto se vuelve práctico

El ejemplo de Pet es simpático, pero acá es donde las uniones realmente brillan en código real.

Respuestas de API que devuelven diferentes formas

public union ApiResult<T>(T, ApiError, ValidationFailure);

Ahora cada consumidor está obligado a manejar éxito, error y fallo de validación. No más bugs de “me olvidé de chequear el caso de error”.

Valor único o colección

El patrón OneOrMore<T> muestra cómo las uniones pueden tener un cuerpo con métodos auxiliares:

public union OneOrMore<T>(T, IEnumerable<T>)
{
 public IEnumerable<T> AsEnumerable() => Value switch
 {
 T single => [single],
 IEnumerable<T> multiple => multiple,
 null => []
 };
}

Los consumidores pasan la forma que les resulte conveniente:

OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };

foreach (var tag in tags.AsEnumerable())
 Console.Write($"[{tag}] ");
// [dotnet]

Componer tipos no relacionados

Esta es la funcionalidad definitiva sobre las jerarquías tradicionales. Podés unir tipos que no tienen nada en común — string y Exception, int e IEnumerable<T>. No se necesita un ancestro común.

Uniones personalizadas para bibliotecas existentes

Acá hay una decisión de diseño inteligente: cualquier clase o struct con un atributo [Union] es reconocida como tipo unión, siempre que siga el patrón básico (constructores públicos para los tipos de caso y una propiedad Value). Bibliotecas como OneOf que ya proveen tipos similares a uniones pueden optar por el soporte del compilador sin reescribir sus internos.

Para escenarios sensibles al rendimiento con tipos de valor, las bibliotecas pueden implementar un patrón de acceso sin boxing con los métodos HasValue y TryGetValue.

El panorama general

Los tipos unión son parte de una historia más amplia de exhaustividad que viene a C#:

Tipos unión — coincidencia exhaustiva sobre un conjunto cerrado de tipos (disponible ahora en preview)
Jerarquías cerradas — el modificador closed previene clases derivadas fuera del assembly que las define (propuesto)
Enums cerrados — previene la creación de valores distintos a los miembros declarados (propuesto)

Juntas, estas tres funcionalidades le darán a C# uno de los sistemas de coincidencia de patrones con seguridad de tipos más completos en cualquier lenguaje mainstream.

Probalo hoy

Los tipos unión están disponibles en .NET 11 Preview 2:

Instalá el SDK de .NET 11 Preview
Apuntá a net11.0 en tu proyecto
Configurá <LangVersion>preview</LangVersion>

Una aclaración: en Preview 2, vas a necesitar declarar UnionAttribute e IUnion en tu proyecto ya que todavía no están en el runtime. Agarrá RuntimePolyfill.cs del repo de docs, o agregá esto:

namespace System.Runtime.CompilerServices
{
 [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
 AllowMultiple = false)]
 public sealed class UnionAttribute : Attribute;

 public interface IUnion
 {
 object? Value { get; }
 }
}

Para cerrar

Los tipos unión son una de esas funcionalidades que te hacen preguntarte cómo sobrevivimos sin ellas. Coincidencia exhaustiva impuesta por el compilador, sintaxis limpia, soporte genérico e integración con el pattern matching existente — es todo lo que pedimos, hecho a la manera de C#.

Probalos en .NET 11 Preview 2, rompé cosas y compartí tu feedback en GitHub. Esto es preview, y el equipo de C# está escuchando activamente. Tus casos extremos y feedback de diseño van a dar forma a la versión final.

Para la referencia completa del lenguaje, consultá la documentación de tipos unión y la especificación de la funcionalidad.

Aspire 13.2 incluye una CLI de documentación — y tu agente de IA también puede usarla

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

¿Conocés ese momento cuando estás metido hasta el cuello en un Aspire AppHost, conectando integraciones, y necesitás verificar exactamente qué parámetros espera la integración de Redis? Hacés alt-tab al navegador, buscás por aspire.dev, entrecerrás los ojos mirando los docs de la API, y volvés a tu editor. Contexto perdido. Flujo roto.

Aspire 13.2 acaba de lanzar una solución para eso. La CLI aspire docs te permite buscar, explorar y leer documentación oficial de Aspire directamente desde tu terminal. Y como está respaldada por servicios reutilizables, los agentes de IA y skills pueden usar los mismos comandos para consultar docs en lugar de alucinar APIs que no existen.

El problema que esto realmente resuelve

David Pine lo clava en el post original: los agentes de IA eran terribles ayudando a los desarrolladores a construir apps con Aspire. Recomendaban dotnet run en vez de aspire run, referenciaban learn.microsoft.com para docs que viven en aspire.dev, sugerían paquetes NuGet desactualizados, y — mi favorito personal — alucinaban APIs que no existen.

¿Por qué? Porque Aspire fue específico de .NET por mucho más tiempo del que lleva siendo políglota, y los LLMs trabajan con datos de entrenamiento que preceden las últimas funcionalidades. Cuando le das a un agente de IA la capacidad de buscar los docs actuales, deja de adivinar y empieza a ser útil.

Tres comandos, cero pestañas del navegador

La CLI es refrescantemente simple:

Listar todos los docs

aspire docs list

Devuelve cada página de documentación disponible en aspire.dev. ¿Necesitás salida legible por máquina? Agregá --format Json.

Buscar un tema

aspire docs search "redis"

Busca tanto en títulos como en contenido con puntuación de relevancia ponderada. El mismo motor de búsqueda que alimenta la herramienta de documentación internamente. Obtenés resultados rankeados con títulos, slugs y puntuaciones de relevancia.

Leer una página completa (o solo una sección)

aspire docs get redis-integration

Transmite la página completa como markdown a tu terminal. ¿Necesitás solo una sección?

aspire docs get redis-integration --section "Add Redis resource"

Precisión quirúrgica. Sin hacer scroll por 500 líneas. Solo la parte que necesitás.

El ángulo del agente de IA

Acá es donde se pone interesante para los que desarrollamos con herramientas de IA. Los mismos comandos de aspire docs funcionan como herramientas para agentes de IA — a través de skills, servidores MCP, o wrappers simples de CLI.

En vez de que tu asistente de IA invente APIs de Aspire basándose en datos de entrenamiento obsoletos, puede llamar a aspire docs search "postgres", encontrar los docs oficiales de integración, leer la página correcta, y darte el enfoque documentado. Documentación en tiempo real y actual — no lo que el modelo memorizó hace seis meses.

La arquitectura detrás de esto es intencional. El equipo de Aspire construyó servicios reutilizables (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) en lugar de una integración única. Eso significa que el mismo motor de búsqueda funciona para humanos en la terminal, agentes de IA en tu editor, y automatización en tu pipeline de CI.

Escenarios del mundo real

Consultas rápidas en terminal: Estás tres archivos adentro y necesitás los parámetros de configuración de Redis. Dos comandos, noventa segundos, de vuelta al trabajo:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

Desarrollo asistido por IA: Tu skill de VS Code envuelve los comandos de la CLI. Preguntás “Agregá una base de datos PostgreSQL a mi AppHost” y el agente busca los docs reales antes de responder. Sin alucinaciones.

Validación en CI/CD: Tu pipeline valida configuraciones de AppHost contra documentación oficial de forma programática. La salida --format Json se conecta limpiamente con jq y otras herramientas.

Bases de conocimiento personalizadas: ¿Estás construyendo tu propia herramienta de IA? Enviá la salida JSON estructurada directamente a tu base de conocimiento:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Sin web scraping. Sin API keys. Los mismos datos estructurados que usa internamente la herramienta de documentación.

La documentación siempre está actualizada

Esta es la parte que más aprecio. La CLI no descarga una captura estática — consulta aspire.dev con caché basado en ETag. En el momento en que los docs se actualizan, tu CLI y cualquier skill construido sobre ella lo refleja. Sin copias obsoletas, sin momentos de “pero el wiki decía…”.

Para cerrar

aspire docs es una de esas funcionalidades pequeñas que resuelve un problema real de forma limpia. Los humanos obtienen acceso a documentación nativa de terminal. Los agentes de IA obtienen una forma de dejar de adivinar y empezar a referenciar docs reales. Y todo está respaldado por la misma fuente de verdad.

Si estás construyendo con .NET Aspire y todavía no probaste la CLI, ejecutá aspire docs search "tu-tema-aquí" y fijate cómo se siente. Después considerá envolver esos comandos en cualquier skill de IA o configuración de automatización que estés usando — tus agentes te lo van a agradecer.

Mirá el análisis profundo de David Pine sobre cómo se armó la herramienta de documentación, y la referencia oficial de la CLI para todos los detalles.

Microsoft Agent Framework Llega a 1.0 — Esto Es Lo Que Realmente Importa para Desarrolladores .NET

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

Si has estado siguiendo el camino de Agent Framework desde los primeros días de Semantic Kernel y AutoGen, esto es importante. Microsoft Agent Framework acaba de llegar a la versión 1.0 — listo para producción, APIs estables, compromiso de soporte a largo plazo. Está disponible tanto para .NET como para Python, y está genuinamente preparado para cargas de trabajo reales.

Voy a cortar el ruido del anuncio y centrarme en lo que importa si estás construyendo apps con IA usando .NET.

La versión corta

Agent Framework 1.0 unifica lo que solían ser Semantic Kernel y AutoGen en un único SDK de código abierto. Una abstracción de agente. Un motor de orquestación. Múltiples proveedores de IA. Si has estado saltando entre Semantic Kernel para patrones empresariales y AutoGen para flujos de trabajo multi-agente de nivel investigación, puedes parar. Este es el único SDK ahora.

Empezar es casi injustamente simple

Aquí tienes un agente funcional en .NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

Eso es todo. Un puñado de líneas y tienes un agente de IA ejecutándose contra Azure Foundry. El equivalente en Python es igual de conciso. Añade herramientas de funciones, conversaciones multi-turno y streaming a medida que avanzas — la superficie de la API escala sin volverse rara.

Orquestación multi-agente — esto va en serio

Los agentes individuales están bien para demos, pero los escenarios de producción generalmente necesitan coordinación. Agent Framework 1.0 viene con patrones de orquestación probados en batalla directamente de Microsoft Research y AutoGen:

Secuencial — los agentes procesan en orden (escritor → revisor → editor)
Concurrente — distribuye a múltiples agentes en paralelo, converge resultados
Handoff — un agente delega a otro basándose en la intención
Chat grupal — múltiples agentes discuten y convergen en una solución
Magentic-One — el patrón multi-agente de nivel investigación de MSR

Todos soportan streaming, checkpointing, aprobaciones con humano en el bucle, y pausa/reanudación. La parte de checkpointing es crucial — los flujos de trabajo de larga duración sobreviven a reinicios de proceso. Para nosotros los desarrolladores .NET que hemos construido flujos de trabajo durables con Azure Functions, esto se siente familiar.

Las funcionalidades que más importan

Aquí va mi lista de lo que vale la pena saber:

Hooks de middleware. ¿Sabes cómo ASP.NET Core tiene pipelines de middleware? Mismo concepto, pero para la ejecución de agentes. Intercepta cada etapa — añade seguridad de contenido, logging, políticas de cumplimiento — sin tocar los prompts del agente. Así es como haces que los agentes estén listos para empresa.

Memoria conectable. Historial conversacional, estado persistente clave-valor, recuperación basada en vectores. Elige tu backend: Foundry Agent Service, Mem0, Redis, Neo4j, o crea el tuyo propio. La memoria es lo que convierte una llamada LLM sin estado en un agente que realmente recuerda el contexto.

Agentes declarativos en YAML. Define las instrucciones de tu agente, herramientas, memoria y topología de orquestación en archivos YAML versionados. Carga y ejecuta con una sola llamada a la API. Esto es un cambio radical para equipos que quieren iterar en el comportamiento del agente sin redesplegar código.

Soporte A2A y MCP. MCP (Model Context Protocol) permite a los agentes descubrir e invocar herramientas externas dinámicamente. A2A (protocolo Agent-to-Agent) habilita la colaboración entre runtimes — tus agentes .NET pueden coordinarse con agentes ejecutándose en otros frameworks. El soporte para A2A 1.0 llegará pronto.

Las funcionalidades en preview que vale la pena seguir

Algunas funcionalidades se lanzaron como preview en 1.0 — funcionales pero las APIs pueden evolucionar:

DevUI — un depurador local basado en navegador para visualizar la ejecución del agente, flujos de mensajes y llamadas a herramientas en tiempo real. Piensa en Application Insights, pero para el razonamiento del agente.
GitHub Copilot SDK y Claude Code SDK — usa Copilot o Claude como un harness de agente directamente desde tu código de orquestación. Compón un agente capaz de programar junto a tus otros agentes en el mismo flujo de trabajo.
Agent Harness — un runtime local personalizable que da a los agentes acceso a shell, sistema de archivos y bucles de mensajería. Piensa en agentes de programación y patrones de automatización.
Skills — paquetes reutilizables de capacidades de dominio que dan a los agentes capacidades estructuradas listas para usar.

Migrando desde Semantic Kernel o AutoGen

Si tienes código existente de Semantic Kernel o AutoGen, hay asistentes de migración dedicados que analizan tu código y generan planes de migración paso a paso. La guía de migración de Semantic Kernel y la guía de migración de AutoGen te guían a través de todo.

Si has estado en los paquetes RC, actualizar a 1.0 es solo un cambio de versión.

Para cerrar

Agent Framework 1.0 es el hito de producción que los equipos empresariales han estado esperando. APIs estables, soporte multi-proveedor, patrones de orquestación que realmente funcionan a escala, y rutas de migración desde tanto Semantic Kernel como AutoGen.

El framework es completamente open source en GitHub, y puedes empezar hoy con dotnet add package Microsoft.Agents.AI. Echa un vistazo a la guía de inicio rápido y los ejemplos para ponerte manos a la obra.

Si has estado esperando la señal de “seguro para usar en producción” — esta es.

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.

Azure DevOps por fin arregla el editor Markdown que todos odiaban

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

Si usas Azure Boards, probablemente has vivido esto: estás leyendo la descripción de un work item, tal vez revisando los criterios de aceptación, y accidentalmente haces doble clic. Boom — estás en modo edición. No querías editar nada. Solo estabas leyendo.

Dan Hellem anunció la corrección, y es uno de esos cambios que suenan pequeños pero realmente eliminan fricción de tu flujo de trabajo diario.

Qué cambió

El editor Markdown para campos de texto de work items ahora abre en modo vista previa por defecto. Puedes leer e interactuar con el contenido — seguir enlaces, revisar formato — sin preocuparte por entrar accidentalmente en modo edición.

Cuando realmente quieres editar, haces clic en el ícono de edición en la parte superior del campo. Cuando terminas, sales explícitamente al modo vista previa. Simple, intencional, predecible.

Eso es. Ese es el cambio.

Por qué importa más de lo que parece

El hilo de feedback de la comunidad sobre esto era largo. El comportamiento de doble clic para editar se introdujo con el editor Markdown en julio 2025, y las quejas empezaron casi inmediatamente. El problema no eran solo las ediciones accidentales — era que toda la interacción se sentía impredecible.

Para equipos que hacen planificación de sprints, refinamiento de backlog o revisión de código con Azure Boards, este tipo de micro-fricción se acumula. Cada entrada accidental al modo edición es un cambio de contexto. Cada momento de “espera, ¿cambié algo?” es atención desperdiciada.

Estado del despliegue

Ya se está implementando para un subconjunto de clientes y se expandirá a todos en las próximas dos o tres semanas.

Para cerrar

No toda mejora necesita ser una función titular. A veces la mejor actualización es simplemente eliminar algo molesto. Esta es una de esas — una pequeña corrección de UX que hace que Azure Boards se sienta menos hostil para las personas que solo quieren leer sus work items en paz.

Bookmark Studio trae navegación por slots y compartir a los marcadores de Visual Studio

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

Los marcadores en Visual Studio siempre han sido… aceptables. Pones uno, navegas al siguiente, olvidas cuál es cuál. Funcionan, pero nunca han sido una función que llamarías poderosa.

Mads Kristensen acaba de lanzar Bookmark Studio, una extensión experimental que llena exactamente los vacíos que probablemente has encontrado si usas marcadores regularmente.

Navegación por slots

Los marcadores se pueden asignar a slots del 1 al 9 y saltar directamente con Alt+Shift+1 hasta Alt+Shift+9. Los nuevos marcadores obtienen automáticamente el siguiente slot disponible.

El Gestor de Marcadores

Una nueva ventana de herramientas muestra todos tus marcadores en un solo lugar con filtrado por nombre, archivo, ubicación, color o slot.

Organización con etiquetas, colores y carpetas

Los marcadores pueden tener opcionalmente etiquetas, colores y agruparse en carpetas. Toda la metadata se almacena por solución.

Exportar y compartir

Bookmark Studio permite exportar marcadores como texto plano, Markdown o CSV. Puedes incluir rutas de marcadores en descripciones de PR o compartir caminos de investigación con compañeros.

Marcadores que siguen al código

Bookmark Studio rastrea los marcadores relativos al texto al que están anclados, así que no se desplazan a líneas incorrectas mientras editas.

Para cerrar

Bookmark Studio no reinventa nada. Toma una función que ha sido “suficiente” durante años y la hace genuinamente útil. Descárgalo del Visual Studio Marketplace.

El Dashboard de Aspire 13.2 ahora tiene una API de telemetría — y lo cambia todo

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

Si has estado construyendo aplicaciones distribuidas con .NET Aspire, ya sabes que el dashboard es lo mejor de toda la experiencia. Todas tus trazas, logs y métricas en un solo lugar — sin Jaeger externo, sin configuración de Seq, sin momentos de “déjame revisar la otra terminal”.

Aspire 13.2 acaba de mejorar todo significativamente. James Newton-King anunció la actualización, y honestamente, las funciones de exportación de telemetría y la API por sí solas justifican la actualización.

Exportar telemetría como una persona normal

Este es el escenario que todos hemos vivido: estás depurando un problema distribuido, finalmente lo reproduces después de veinte minutos de configuración, y ahora necesitas compartir lo que pasó con tu equipo. ¿Antes? Capturas de pantalla. Copiar y pegar IDs de trazas. El desastre de siempre.

Aspire 13.2 añade un diálogo de Gestión de logs y telemetría donde puedes:

Limpiar toda la telemetría (útil antes de reproducir un bug)
Exportar telemetría seleccionada a un archivo ZIP en formato estándar OTLP/JSON
Re-importar ese ZIP en cualquier dashboard de Aspire después

Esa última parte es la función estrella. Reproduces un bug, exportas la telemetría, la adjuntas a tu work item, y tu compañero puede importarla en su propio dashboard para ver exactamente lo que tú viste. No más “¿puedes reproducirlo en tu máquina?”

Las trazas, spans y logs individuales también tienen una opción “Export JSON” en sus menús contextuales. ¿Necesitas compartir una traza específica? Clic derecho, copiar JSON, pegar en la descripción de tu PR. Listo.

La API de telemetría es el verdadero cambio de juego

Esto es lo que más me emociona. El dashboard ahora expone una API HTTP bajo /api/telemetry para consultar datos de telemetría programáticamente. Endpoints disponibles:

GET /api/telemetry/resources — listar recursos con telemetría
GET /api/telemetry/spans — consultar spans con filtros
GET /api/telemetry/logs — consultar logs con filtros
GET /api/telemetry/traces — listar trazas
GET /api/telemetry/traces/{traceId} — obtener todos los spans de una traza

Todo vuelve en formato OTLP JSON. Esto potencia los nuevos comandos aspire agent mcp y aspire otel del CLI, pero la implicación real es mayor: ahora puedes construir herramientas, scripts e integraciones con agentes IA que consulten la telemetría de tu app directamente.

Imagina un agente de IA que pueda ver tus trazas distribuidas reales mientras depuras. Eso ya no es hipotético — es lo que esta API permite.

La telemetría de GenAI se vuelve práctica

Si estás construyendo apps con IA usando Semantic Kernel o Microsoft.Extensions.AI, apreciarás el visualizador de telemetría GenAI mejorado. Aspire 13.2 añade:

Descripciones de herramientas IA renderizadas como Markdown
Un botón dedicado de GenAI en la página de trazas para acceso rápido
Mejor manejo de errores para JSON de GenAI truncado o no estándar
Navegación click-to-highlight entre definiciones de herramientas

El post menciona que VS Code Copilot chat, Copilot CLI y OpenCode soportan configurar un OTEL_EXPORTER_OTLP_ENDPOINT. Apúntalos al dashboard de Aspire y literalmente puedes ver a tus agentes IA pensar en tiempo real a través de la telemetría. Esa es una experiencia de depuración que no encontrarás en ningún otro lado.

Para cerrar

Aspire 13.2 transforma el dashboard de “bonita UI de depuración” a “plataforma de observabilidad programable”. El flujo de exportación/importación por sí solo ahorra tiempo real en depuración distribuida, y la API de telemetría abre la puerta al diagnóstico asistido por IA.

Si ya estás en Aspire, actualiza. Si no — esta es una buena razón para echarle un vistazo a aspire.dev.

La actualización de marzo de Visual Studio te permite crear agentes Copilot personalizados — y find_symbol es clave

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

Visual Studio acaba de recibir su actualización de Copilot más significativa hasta ahora. Mark Downie anunció la versión de marzo, y el titular son los agentes personalizados — pero honestamente, la herramienta find_symbol podría ser la función que más cambie tu flujo de trabajo.

Agentes Copilot personalizados en tu repo

¿Quieres que Copilot siga los estándares de código de tu equipo, ejecute tu pipeline de build, o consulte tus docs internos? Ahora puedes construir exactamente eso.

Los agentes personalizados se definen como archivos .agent.md que colocas en .github/agents/ en tu repositorio. Cada agente tiene acceso completo al workspace, comprensión del código, herramientas, tu modelo preferido, y conexiones MCP a servicios externos.

Agent skills: paquetes de instrucciones reutilizables

Los skills se cargan automáticamente desde .github/skills/ en tu repo o ~/.copilot/skills/ en tu perfil. Piensa en los skills como experiencia modular que puedes mezclar y combinar.

find_symbol: navegación con reconocimiento de lenguaje

La nueva herramienta find_symbol le da al modo agente de Copilot navegación de símbolos basada en servicios de lenguaje. En lugar de buscar texto, el agente puede encontrar todas las referencias a un símbolo, acceder a información de tipos, declaraciones y alcance.

Para desarrolladores .NET, esto es una mejora enorme — las bases de código C# con jerarquías de tipos profundas e interfaces se benefician enormemente.

Perfilar tests con Copilot

Hay un nuevo comando Profile with Copilot en el menú contextual del Test Explorer. Selecciona un test, haz clic en perfilar, y el Profiling Agent lo ejecuta y analiza automáticamente.

Perf tips durante debugging en vivo

La optimización de rendimiento ahora ocurre mientras depuras. Visual Studio muestra tiempo de ejecución y señales de rendimiento inline. ¿Ves una línea lenta? Haz clic en el Perf Tip y pídele a Copilot sugerencias de optimización.

Corregir vulnerabilidades de NuGet desde Solution Explorer

Cuando se detecta una vulnerabilidad en un paquete NuGet, verás un enlace Fix with GitHub Copilot directamente en Solution Explorer.

Para cerrar

Agentes personalizados y skills son el titular, pero find_symbol es la joya oculta — cambia fundamentalmente la precisión de Copilot al refactorizar código .NET. Combinado con profiling en vivo y corrección de vulnerabilidades, esta actualización hace que las funciones de IA de Visual Studio se sientan genuinamente prácticas.

Descarga Visual Studio 2026 Insiders para probarlo todo.

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.

VS Code 1.112: Lo que los desarrolladores .NET realmente deberían importarles

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

VS Code 1.112 acaba de aterrizar, y ¿honestamente? Este pega diferente si pasas tus días en territorio .NET. Hay mucho en las notas de la versión oficial, pero déjame ahorrarte algo de scroll y enfocarme en lo que realmente nos importa.

Copilot CLI se volvió mucho más útil

El gran tema de esta versión es la autonomía del agente — dar a Copilot más espacio para hacer lo suyo sin que tengas que supervisar cada paso.

Direccionamiento y cola de mensajes

¿Conoces ese momento cuando Copilot CLI va a la mitad de una tarea y te das cuenta de que olvidaste mencionar algo? Antes, tenías que esperar. Ahora puedes enviar mensajes mientras una solicitud aún está en progreso — ya sea para dirigir la respuesta actual o encolar instrucciones de seguimiento.

Esto es enorme para esas tareas más largas de scaffolding con dotnet donde estás viendo a Copilot configurar un proyecto y piensas “oh espera, también necesito MassTransit ahí”.

Niveles de permisos

Este es el que más me emociona. Las sesiones de Copilot CLI ahora soportan tres niveles de permisos:

Permisos por defecto — el flujo usual donde las herramientas piden confirmación antes de ejecutarse
Omitir aprobaciones — auto-aprueba todo y reintenta en errores
Autopiloto — totalmente autónomo: aprueba herramientas, responde sus propias preguntas, y sigue hasta que la tarea está completa

Si estás haciendo algo como crear desde cero una nueva API ASP.NET Core con Entity Framework, migraciones, y un setup de Docker — el modo Autopiloto significa que describes lo que quieres y vas por un café. Él lo resolverá.

Puedes habilitar Autopiloto con la configuración chat.autopilot.enabled.

Previsualizar cambios antes de delegar

Cuando delegas una tarea a Copilot CLI, crea un worktree. Antes, si tenías cambios sin commit, tenías que revisar el Control de Código Fuente para ver qué se afectaría. Ahora la vista de Chat muestra los cambios pendientes ahí mismo antes de que decidas si copiarlos, moverlos o ignorarlos.

Algo pequeño, pero te salva de ese momento de “espera, ¿qué tenía en staging?”.

Depura apps web sin salir de VS Code

El navegador integrado ahora soporta depuración completa. Puedes poner breakpoints, hacer step through del código, e inspeccionar variables — todo dentro de VS Code. Se acabó cambiar a Edge DevTools.

Hay un nuevo tipo de depuración editor-browser, y si ya tienes configuraciones de lanzamiento msedge o chrome existentes, migrar es tan simple como cambiar el campo type en tu launch.json:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Para desarrolladores de Blazor, esto es un game changer. Ya estás ejecutando dotnet watch en la terminal — ahora tu depuración se queda en la misma ventana también.

El navegador también obtuvo niveles de zoom independientes (por fin), menús de contexto con clic derecho apropiados, y el zoom se recuerda por sitio web.

Sandboxing de servidores MCP

Esto importa más de lo que podrías pensar. Si estás usando servidores MCP — quizás has configurado uno personalizado para tus recursos de Azure o consultas de base de datos — han estado ejecutándose con los mismos permisos que tu proceso de VS Code. Eso significa acceso total a tu sistema de archivos, red, todo.

Ahora puedes ponerlos en sandbox. En tu mcp.json:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

Cuando un servidor en sandbox necesita acceso a algo que no tiene, VS Code te solicita que otorgues permiso. Mucho mejor que el enfoque de “esperar que nadie haga nada raro”.

Descubrimiento de personalizaciones en monorepos

Si trabajas en un monorepo (y seamos honestos, muchas soluciones empresariales .NET terminan siendo uno), esto resuelve un punto de dolor real.

Anteriormente, si abrías una subcarpeta de tu repo, VS Code no encontraba tu copilot-instructions.md, AGENTS.md, o skills personalizados ubicados en la raíz del repositorio. Ahora con la configuración chat.useCustomizationsInParentRepositories, sube hasta la raíz .git y descubre todo.

Esto significa que tu equipo puede compartir instrucciones de agente, archivos de prompt y herramientas personalizadas a través de todos los proyectos en un monorepo sin que todos tengan que abrir la carpeta raíz.

/troubleshoot para depuración de agentes

¿Alguna vez configuraste instrucciones personalizadas o skills y te preguntaste por qué no se están detectando? El nuevo skill /troubleshoot lee los logs de depuración del agente y te dice qué pasó — qué herramientas se usaron o se saltaron, por qué las instrucciones no cargaron, y qué está causando respuestas lentas.

Habilítalo con:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

Luego simplemente escribe /troubleshoot why is my custom skill not loading? en el chat.

También puedes exportar e importar estos logs de depuración ahora, lo cual es genial para compartir con tu equipo cuando algo no funciona como se esperaba.

Soporte para archivos de imagen y binarios

Los agentes ahora pueden leer archivos de imagen desde disco y archivos binarios de forma nativa. Los archivos binarios se presentan en formato hexdump, y las salidas de imagen (como capturas de pantalla del navegador integrado) aparecen en una vista de carrusel.

Para desarrolladores .NET, piensa: pega una captura de pantalla de un bug de UI en el chat y haz que el agente entienda qué está mal, o haz que analice la salida del renderizado de un componente Blazor.

Referencias automáticas de símbolos

Pequeña mejora de calidad de vida: cuando copias el nombre de un símbolo (una clase, método, etc.) y lo pegas en el chat, VS Code ahora lo convierte automáticamente en una referencia #sym:Name. Esto le da al agente contexto completo sobre ese símbolo sin que tengas que agregarlo manualmente.

Si quieres texto plano en su lugar, usa Ctrl+Shift+V.

Los plugins ahora se pueden habilitar/deshabilitar

Anteriormente, deshabilitar un servidor MCP o plugin significaba desinstalarlo. Ahora puedes activarlos y desactivarlos — tanto globalmente como por workspace. Clic derecho en la vista de Extensiones o la vista de Personalizaciones y listo.

Los plugins de npm y pypi también pueden auto-actualizarse ahora, aunque pedirán aprobación primero ya que las actualizaciones significan ejecutar código nuevo en tu máquina.

Para cerrar

VS Code 1.112 está claramente empujando fuerte en la experiencia del agente — más autonomía, mejor depuración, seguridad más ajustada. Para desarrolladores .NET, la depuración del navegador integrado y las mejoras de Copilot CLI son las características destacadas.

Si aún no has probado ejecutar una sesión completa de Copilot CLI en modo Autopiloto para un proyecto .NET, esta versión es un buen momento para empezar. Solo recuerda configurar tus permisos y dejarlo cocinar.

Descarga VS Code 1.112 o actualiza desde dentro de VS Code vía Ayuda > Buscar actualizaciones.

Emiliano Montesdeoca

Mon, 01 Jan 0001 00:00:00 +0000

Escribe para The .NET Blog

Mon, 01 Jan 0001 00:00:00 +0000

The .NET Blog es una publicación impulsada por la comunidad donde los desarrolladores comparten ideas, tutoriales e historias sobre .NET, Azure, IA y desarrollo cloud-native. Damos la bienvenida a contribuciones de desarrolladores de todos los niveles — tanto si es tu primer artículo técnico como si eres un ponente con experiencia.

Cómo Unirse

Todo vive en GitHub y sigue un flujo de trabajo de pull requests. Así puedes empezar:

1. Haz un Fork del Repositorio

Ve a github.com/thedotnetblog/blog y haz un fork a tu cuenta de GitHub.

2. Crea tu Perfil de Autor

Si es tu primera contribución, añádete como autor creando una carpeta en content/authors/tu-usuario/ con un archivo index.md:

---
title: "Tu Nombre"
id: "tu-usuario"
role: "Tu cargo o título"
bio: "Una breve biografía sobre ti."
avatar: "/img/authors/tu-avatar.jpg"
socials:
 - platform: "GitHub"
 url: "https://github.com/tu-usuario"
 - platform: "Twitter"
 url: "https://x.com/tu-usuario"
---

Añade tu imagen de avatar (cuadrada, mínimo 200×200px) en static/img/authors/.

3. Escribe tu Artículo

Crea una nueva carpeta en content/posts/tu-usuario/slug-de-tu-articulo/ y añade un archivo index.md:

---
title: "Título de tu Artículo"
date: 2025-01-01
author: "tu-usuario"
description: "Una descripción breve de tu artículo."
tags: ["dotnet", "azure"]
---

El contenido de tu artículo en Markdown...

4. Abre un Pull Request

Sube tus cambios a tu fork y abre un pull request contra la rama main. Nuestro equipo lo revisará y te dará feedback en unos días.

Qué Buscamos

Tutoriales — guías paso a paso sobre .NET, Azure, IA, Blazor, Aspire y más
Análisis profundos — exploraciones detalladas de una tecnología, patrón o arquitectura
Historias de la comunidad — tu experiencia construyendo con .NET en producción
Resúmenes de eventos — resúmenes de conferencias, meetups o webinars

Directrices

El contenido debe ser técnico y relevante para el ecosistema .NET
Los ejemplos de código deben ser precisos y probados en un proyecto real
Incluye una descripción significativa y al menos una etiqueta relevante
Los artículos se traducen automáticamente a todos los idiomas disponibles

Contacto

Abre un issue en GitHub o contáctanos en X / Twitter. ¡Nos encantaría tenerte en la comunidad!

The .NET Blog

NDC Oslo 2026

En números

Ponentes confirmados

Entradas

Otros eventos NDC en 2026

Enlaces

.NET Day Switzerland 2026

Qué incluye

Entradas

Organizadores

Enlaces

SDD Conference 2026

Temas

Ponentes

Entradas e información

Actualización de Abril del Azure DevOps MCP Server: Consultas WIQL, Auth PAT y MCP Apps Experimental

Soporte de Consultas WIQL

Personal Access Tokens en el Servidor Local

Anotaciones MCP en el Servidor Remoto

Consolidación de Herramientas Wiki

Experimental: MCP Apps

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

¿Dónde Recuerda las Cosas tu Agente? Guía Práctica sobre el Almacenamiento del Historial de Chat

Dos patrones fundamentales

Gestionado por servicio: lineal vs bifurcación

Cómo Agent Framework abstrae esto

Referencia rápida de proveedores

Cómo elegir

.NET 10 Se Incluye con Ubuntu 26.04 LTS — Qué hay de Nuevo

Instala .NET 10 en dos comandos

Pruébalo de inmediato

Contenedores: actualiza -noble a -resolute

Native AOT: arranque en 3ms, binario de 1.4MB

¿Necesitas .NET 8 o 9?

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

CodeAct en Agent Framework: Cómo Reducir la Latencia de tu Agente a la Mitad

¿Qué es CodeAct?

La pieza de seguridad: micro-VMs de Hyperlight

Cómo conectarlo

Mezclando CodeAct con herramientas que requieren aprobación

Cuándo usar CodeAct (y cuándo no)

Pruébalo ahora

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

La progresión de GPT-5

Qué cambió realmente

Precios

Por qué importa Foundry

Cómo empezar

VS Code 1.118: Copilot CLI Obtiene Nombres de Sesión, Insignias de Modelo y TypeScript 7.0 Nightly

Copilot CLI: las sesiones tienen nombres reales

Cambia de sesión más rápido con atajos de teclado

Insignias de modelo en el chat

Selección automática de modelo en Copilot CLI

Opt-in a TypeScript 7.0 nightly

Bajo el capó: limpieza de node-pty

Aspire 13.2: Soporte para Bun, Mejores Contenedores y Menos Fricción en el Debug

Bun es Ahora Ciudadano de Primera Clase

Yarn es Más Confiable

Mejoras en Contenedores

Pull Policy Explícita

PostgreSQL 18+ Funciona Correctamente

Mejoras de Depuración

Resumiendo

¿68 Minutos al Día Re-Explicando Código a Copilot? Hay una Solución

Contenedores: actualiza `-noble` a `-resolute`

Bajo el capó: limpieza de `node-pty`