AI Agents | The .NET Blog

Microsoft Agent Framework Parte 3: De las Herramientas a los Workflows — Las Piezas Encajan

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

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

Si has seguido la serie Building Blocks for AI en .NET, sabes que la Parte 1 nos dio IChatClient (la interfaz universal de modelos) y la Parte 2 nos dio Microsoft.Extensions.VectorData (búsqueda semántica y RAG). Ambas son fundamentales y útiles por sí solas. Pero aquí es donde todo empieza a conectarse.

La Parte 3 trata del Microsoft Agent Framework — y sinceramente, es la pieza que estaba esperando ver en .NET. La versión 1.0 se publicó en abril. La API es estable. Es hora de construir agentes de verdad.

Qué es un Agente (vs. un Chatbot)

Antes de entrar en el código, dejemos esto claro. Un chatbot recibe input, llama a un modelo, devuelve output. Bucle simple.

Un agente tiene autonomía. Puede razonar sobre una tarea, decidir qué herramientas usar, llamarlas, evaluar resultados y decidir qué hacer a continuación — todo sin que tú escribas lógica paso a paso para cada escenario. Le das herramientas e instrucciones, y él se encarga de la orquestación.

Piénsalo así: IChatClient es como tener una conversación. Un agente es como delegarle una lista de tareas a alguien.

Tu Primer Agente en 10 Líneas

dotnet add package Microsoft.Agents.AI

AIAgent agent = new AzureOpenAIClient(
 new Uri(endpoint),
 new DefaultAzureCredential())
 .GetChatClient(deploymentName)
 .AsAIAgent(
 instructions: "You are good at telling jokes.",
 name: "Joker");

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate."));

El método de extensión .AsAIAgent() es el puente. Mismo patrón que .AsIChatClient() de MEAI — envuelve el SDK del proveedor en una abstracción estable. Funciona con Azure OpenAI, OpenAI, GitHub Models, Microsoft Foundry o modelos locales.

El streaming también funciona:

await foreach (var update in agent.RunStreamingAsync("Tell me a joke about a pirate."))
{
 Console.Write(update);
}

Dando Herramientas al Agente

Aquí es donde los agentes dejan de ser chatbots sofisticados. Las herramientas son funciones que el modelo puede decidir llamar según lo que el usuario pida. No necesitas lógica de enrutamiento — el modelo lo descifra solo.

[Description("Get the weather for a given location.")]
static string GetWeather(
 [Description("The location to get the weather for.")] string location)
 => $"The weather in {location} is cloudy with a high of 15°C.";

AIAgent agent = chatClient.AsAIAgent(
 instructions: "You are a helpful assistant",
 tools: [AIFunctionFactory.Create(GetWeather)]);

Dos cosas a notar. Primero, AIFunctionFactory es de MEAI — la misma fábrica de herramientas que usarías con un IChatClient normal. Si ya tienes herramientas definidas para escenarios de chat, funcionan aquí también.

Segundo, los atributos Description importan mucho. Son cómo el modelo entiende qué hace una herramienta y cuándo usarla. Trátalos como documentación para tu IA, no para humanos.

Sesiones: Conversaciones con Memoria Real

AgentSession session = await agent.CreateSessionAsync();

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate.", session));

Console.WriteLine(await agent.RunAsync(
 "Now add some emojis and tell it in the voice of a pirate's parrot.",
 session));

Sin sesión, cada llamada a RunAsync es sin estado. Con sesión, el agente sabe a qué chiste te refieres. AgentSession preserva el historial de conversación entre turnos.

Para servicios sin estado en producción, las sesiones se serializan de forma limpia:

JsonElement sessionState = await agent.SerializeSessionAsync(session);
// ... guárdalo en algún lugar ...
var restoredSession = await agent.DeserializeSessionAsync(sessionState);
Console.WriteLine(await agent.RunAsync("What were we just talking about?", restoredSession));

Esto es crítico si tu agente se ejecuta en entornos serverless o con escalado horizontal.

AIContextProvider: Memoria Persistente Entre Sesiones

Las sesiones preservan el historial dentro de una sesión. Pero ¿qué hay de conocer cosas sobre un usuario entre sesiones? AIContextProvider maneja eso.

Tiene dos ganchos:

ProvideAIContextAsync — se ejecuta antes de cada interacción, inyecta contexto en el agente
StoreAIContextAsync — se ejecuta después de cada interacción, permite aprender y persistir

El patrón es elegante: puedes apilar múltiples proveedores — uno para preferencias del usuario, uno para interacciones recientes, uno que consulta tu almacén de VectorData para documentos relevantes. Ese último es exactamente el patrón RAG de la Parte 2, ahora ejecutándose automáticamente en cada llamada al agente.

Workflows Multiagente

Aquí es donde el framework se gana su nombre. Incluye un sistema de workflows basado en grafos donde los ejecutores (agentes, funciones, lo que sea) se conectan mediante aristas.

Algunos patrones soportados nativamente:

Secuencial: La salida del Agente A alimenta al Agente B
Concurrente (fan-out/fan-in): Despacha a múltiples agentes en paralelo, recoge resultados
Enrutamiento condicional: Enruta trabajo a diferentes agentes según el output
Bucles escritor-crítico: Un agente escribe, otro evalúa, bucle hasta aprobación
Sub-workflows: Compone workflows jerárquicamente

Un ejemplo de escritor-crítico:

WorkflowBuilder builder = new(writerAgent);
builder
 .AddEdge(writerAgent, criticAgent)
 .AddEdge(criticAgent, writerAgent, condition: result => !result.IsApproved)
 .WithOutputFrom(criticAgent, condition: result => result.IsApproved);
var workflow = builder.Build();

Limpio, legible, y el enrutamiento basado en condiciones significa que no escribes la lógica del bucle tú mismo.

Human-in-the-Loop

No todo debería ejecutarse de forma completamente autónoma. Para operaciones sensibles — escrituras en bases de datos, transacciones financieras, envío de comunicaciones — quieres que un humano apruebe antes de que el agente ejecute.

El framework tiene soporte integrado para esto mediante FunctionApprovalRequestContent y FunctionApprovalResponseContent. El agente propone la llamada a la herramienta, tu código la presenta al usuario, y la respuesta determina si la ejecución procede.

Esta es la forma correcta de pensar en agentes en entornos empresariales: no completamente autónomos, sino autonomía con barandillas.

El Cuadro Completo

Si das un paso atrás:

MEAI te da una interfaz universal para cualquier modelo
VectorData da a tus agentes acceso al conocimiento de tu organización mediante búsqueda semántica
Agent Framework orquesta todo — usa IChatClient internamente, se compone con proveedores de contexto y coordina mediante workflows

Cada pieza fue diseñada para componerse con las otras. Consulta el post original de Jeremy Likness y el repositorio de GitHub del Agent Framework para los ejemplos completos.

Conclusión

El post de la Parte 3 del Microsoft Agent Framework cierra el bucle de la serie de bloques de construcción. Para los desarrolladores .NET que quieren construir agentes AI — no solo chatbots, sino agentes reales que usan herramientas, recuerdan cosas y coordinan — este es el camino.

La versión estable 1.0 significa que puedes construir con esto en producción. Si has estado esperando para saltar al desarrollo de agentes en .NET, el momento es ahora.

SQL MCP Server en Azure App Service — Sin Contenedores

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

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

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

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

¿Qué es el SQL MCP Server?

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

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

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

El Problema del Contenedor (y la Solución)

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

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

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

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

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

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

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

# Iniciar el servidor
dab start

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

Autenticación Sin Claves de API Compartidas

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

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

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

Despliegue en App Service

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

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

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

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

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

Por qué Importa para los Desarrolladores .NET

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

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

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

Conclusión

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

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

Actualizacion de abril de Visual Studio: integracion de Cloud Agent para flujos .NET

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

Este post fue traducido automaticamente. Para la version original, haz clic aqui.

Actualizacion de abril de Visual Studio: integracion de Cloud Agent para flujos .NET vale la pena para equipos que construyen y operan sistemas .NET en produccion.

Desde mi punto de vista, lo mas importante no es solo la novedad, sino como convertirla rapido en una practica de ingenieria repetible.

Por que importa para equipos .NET

Este cambio ayuda cuando hay que equilibrar velocidad de entrega, consistencia de plataforma y gobernanza.

Siguientes pasos practicos

Valida la funcionalidad en un piloto .NET pequeno con datos realistas.
Define observabilidad y un plan de rollback antes de escalar.
Documenta el patron para reutilizarlo en otros equipos.

Fuente

Articulo original: https://devblogs.microsoft.com/visualstudio/visual-studio-april-update-cloud-agent-integration/

Gobernar llamadas de herramientas MCP en .NET con Agent Governance Toolkit