Agents | The .NET Blog

NL2SQL Es la Inyección SQL de la Era Agéntica

Emiliano Montesdeoca — Wed, 03 Jun 2026 00:00:00 +0000

Hay una versión del argumento de NL2SQL que suena perfecta: los usuarios hacen preguntas en lenguaje natural, los agentes generan SQL, los datos regresan. Menos pantallas, menos consultas, menos código. Simple.

Luego lo piensas cinco minutos más.

Los Problemas de los que Nadie Habla en la Demo

Los esquemas no fueron diseñados para explicar las cosas. Nombres de tablas crípticos, nombres de columnas inconsistentes, relaciones técnicamente válidas pero semánticamente inválidas sin predicados adicionales — esto es normal en bases de datos empresariales. No son errores, son simplemente la historia acumulada de cambios de negocio. Pero cuando le pides a un modelo que infiera intención de un esquema que no fue diseñado para comunicar intención, el modelo lo intentará de todas formas. No se rendirá. Generará su mejor consulta posible y devolverá resultados con confianza.

Los modelos no son deterministas. Haz la misma pregunta sobre la misma base de datos dos veces y podrías obtener SQL diferente. El modelo está calculando probabilidades, y variaciones ligeras en el contexto generan salidas diferentes. No puedes probar tu camino hacia una garantía de que el agente siempre genera la consulta correcta.

La revisión del usuario no escala. “Solo revisa cada consulta antes de la ejecución” suena seguro. Pero asume que los usuarios son expertos tanto en el modelo de datos como en SQL — exactamente las personas que no necesitaban la interfaz de lenguaje natural. También introduce sobrecarga cognitiva y una nueva clase de sesgo de confirmación, donde los usuarios abrumados por la complejidad de la consulta aprueban consultas inválidas en lugar de investigarlas.

Y luego está la inyección. En el desarrollo SQL tradicional, la parametrización resolvió la inyección porque la entrada del usuario llenaba parámetros, no la estructura SQL. Con NL2SQL, el modelo genera el SQL en sí. El prompt, el contexto del esquema, el historial de conversación y los datos recuperados influyen en lo que se ejecuta. Si alguien elabora un prompt que cambia lo que el modelo genera, eso es inyección — no a nivel de parámetro, sino a nivel de generación de consultas. Y a diferencia de eliminar una tabla (obvio, recuperable), la inyección NL2SQL produce consultas que devuelven resultados incorrectos sin ningún error visible. Las decisiones de negocio se toman sobre datos incorrectos.

Lo que SQL MCP Server Realmente Resuelve

Aquí es donde el artículo hace su punto práctico más útil. En lugar de dar a un agente acceso arbitrario al esquema y esperar lo mejor, SQL MCP Server expone una superficie API curada construida sobre Data API builder.

La diferencia importa: el agente no genera SQL. Llama a endpoints con nombre que devuelven formas de resultado predefinidas. El SQL se escribe una vez, por un desarrollador, y es determinista. El no-determinismo del agente se limita a elegir qué endpoint llamar, no a construir consultas arbitrarias.

Esto es análogo a lo que la parametrización hizo para la inyección SQL en el modelo de aplicación tradicional — eliminas la capacidad de construir consultas arbitrarias a partir de entrada no confiable.

La Pregunta Correcta

El artículo no dice “nunca uses NL2SQL.” Dice: sé deliberado sobre dónde lo aplicas y qué expones. Para análisis exploratorio en un entorno controlado, con un esquema limitado y acceso de solo lectura, NL2SQL podría estar bien. Para sistemas de producción donde las decisiones de negocio dependen de los resultados, una capa API curada es significativamente más segura.

Honestidad: algunos problemas se resuelven genuinamente mejor con consultas estructuradas detrás de endpoints con nombre que con lenguaje natural a SQL. SQL MCP Server te da esa opción sin abandonar completamente la interfaz agéntica.

Publicación original: Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?

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

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

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

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

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

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

El Problema Central: Autenticación ≠ Autorización

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

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

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

Cómo Funciona la Cadena de Tokens

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

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

Cómo luce el token del servidor MCP:

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

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

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

Qué Despliega la Plantilla

Con unos pocos comandos azd obtienes:

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

Todo el patrón es inspeccionable y personalizable.

El Principio de Diseño que Vale la Pena Adoptar

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

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

Conclusión

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

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

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

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.

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.

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

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

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.

¿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

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

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.

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

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

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.

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

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

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

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

Qué hace Git-APE realmente

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

Aquí está la configuración:

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

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

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

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

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

Por qué esto importa

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

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

La limpieza es igual de sencilla:

@git-ape destroy my-resource-group

Mi opinión

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

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

Para cerrar

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

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

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

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

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

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.

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

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

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.

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

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

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.

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)

Si vienes del paquete azure-ai-agents, los agentes ahora son operaciones de primera clase en AIProjectClient en azure-ai-projects. Elimina la dependencia independiente y usa get_openai_client() para manejar las respuestas.

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.

Agents | The .NET Blog

NL2SQL Es la Inyección SQL de la Era Agéntica

Los Problemas de los que Nadie Habla en la Demo

Lo que SQL MCP Server Realmente Resuelve

La Pregunta Correcta

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

El Problema Central: Autenticación ≠ Autorización

Cómo Funciona la Cadena de Tokens

Qué Despliega la Plantilla

El Principio de Diseño que Vale la Pena Adoptar

Conclusión

¿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

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

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

¿Qué es un Toolbox?

Los cuatro pilares (dos disponibles hoy)

Empezando en la práctica

No estás bloqueado en Foundry Agents

Por qué importa ahora

Conclusión

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

El modo Autopilot finalmente recuerda tu preferencia

Worktree y aislamiento de git para sesiones de agentes

Subagentes y equipos de agentes

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

La app de Agents en macOS se auto-actualiza

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

La conclusión

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

Las seis opciones de un vistazo

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

Desplegar es genuinamente simple

Gestión de conversaciones integrada

Mi framework de decisión

Para terminar

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

¿Qué es Azure MCP Server?

Lo importante: implementaciones remotas auto-alojadas

Endurecimiento de seguridad

¿Dónde puedes usarlo?

Por qué esto importa para desarrolladores .NET

Empezando

Resumiendo

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

Qué hace Git-APE realmente

Por qué esto importa

Mi opinión

Para cerrar

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

Foundry Agent Service está listo para producción

GPT-5.4 — confiabilidad sobre inteligencia pura

El SDK finalmente es estable

Fireworks AI trae modelos abiertos a Azure

Otros destacados

Conclusión

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

Mejoras en la app de Agentes

Resolución de enlaces CSS @import

Conclusión

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

Ejecutar y depurar agentes IA sin desplegar

GitHub Copilot configura tu proyecto azd

Container App Jobs y mejoras de despliegue

Pulido en la experiencia de desarrollador

Para cerrar

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

Construido sobre la Responses API

Redes privadas: el bloqueador empresarial eliminado

Resolución de enlaces CSS `@import`