Azure Functions | The .NET Blog

Flujos de Trabajo Duraderos en Microsoft Agent Framework: De In-Memory a Azure Functions

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

Uno de los puntos débiles de los primeros flujos de trabajo de agentes de IA: son frágiles. Un flujo de trabajo de múltiples pasos de larga duración vinculado a un único proceso significa que el reinicio del proceso = estado perdido. Para demos simples está bien. Para cargas de trabajo en producción, no.

El modelo de programación de flujos de trabajo de Microsoft Agent Framework ahora soporta ejecución duradera, respaldada por el framework Durable Task, con hospedaje en Azure Functions. Aquí te explicamos cómo funciona el modelo de programación y por qué importa la historia de durabilidad.

Los Bloques de Construcción Básicos

Los Executors son la unidad fundamental de trabajo. Cada uno tiene tipo — toma una entrada específica y produce una salida específica:

using Microsoft.Agents.AI.Workflows;

internal sealed class OrderLookup()
 : Executor<OrderCancelRequest, Order>("OrderLookup")
{
 public override async ValueTask<Order> HandleAsync(
 OrderCancelRequest message,
 IWorkflowContext context,
 CancellationToken cancellationToken = default)
 {
 // buscar el pedido, devolverlo
 return new Order(Id: message.OrderId, ...);
 }
}

Los Workflows conectan ejecutores en grafos dirigidos usando un constructor fluido. El framework gestiona la ejecución, el flujo de datos entre pasos y la propagación de errores.

Puedes modelar:

Cadenas secuenciales (paso A → paso B → paso C)
Fan-out/fan-in paralelo (ejecutar agentes A, B, C en paralelo, agregar resultados)
Ramificación condicional
Aprobaciones de humano en el bucle (pausar flujo de trabajo, esperar señal externa)

El Corredor In-Memory para Desarrollo Local

Empezar es rápido:

dotnet add package Microsoft.Agents.AI
dotnet add package Microsoft.Agents.AI.Workflows

El paquete principal incluye un corredor ligero en proceso. Sin dependencias externas, sin base de datos, sin recursos Azure. Funciona perfectamente para desarrollo local y pruebas unitarias.

Agregar Durabilidad con Durable Task

Cuando un flujo de trabajo necesita sobrevivir a reinicios de proceso — porque es de larga duración, porque tiene pasos de humano en el bucle, porque se dispersa a través de muchas llamadas de agente en paralelo — el corredor in-memory no es suficiente.

La integración de Durable Task de MAF almacena el estado del flujo de trabajo en Azure Storage. Si el proceso se reinicia, el flujo de trabajo se reanuda desde donde lo dejó. El modelo de programación permanece igual; solo cambias el corredor.

dotnet add package Microsoft.Agents.AI.Workflows.DurableTask

Los mismos ejecutores, el mismo grafo de flujo de trabajo — respaldado por estado duradero.

Hospedaje en Azure Functions

La tercera capa es el hospedaje en Azure Functions. Tu flujo de trabajo se convierte en una aplicación Function: activa el flujo de trabajo a través de un endpoint HTTP, y el runtime duradero gestiona el escalado, el estado y la fiabilidad.

Esto significa que un flujo de trabajo multi-agente con llamadas paralelas, ramas condicionales y aprobaciones humanas puede escalar a través de un entorno de Functions sin servidor sin gestión de estado personalizada.

Por Qué Importa Esto

La combinación es significativa para sistemas de IA reales:

Llamadas de agente en paralelo — dispersar a múltiples agentes especializados simultáneamente sin bloquear, agregar resultados cuando todos completen
Procesos de larga duración — los flujos de trabajo que implican aprobación humana o eventos externos pueden pausar y reanudar durante horas o días
Escalado — Azure Functions escala la ejecución horizontalmente; el framework Durable Task gestiona la coordinación del estado paralelo

Si estás construyendo flujos de trabajo MAF más allá de demos locales simples, este es el camino hacia la ejecución de grado producción.

Publicación original: Durable Workflows in the Microsoft Agent Framework

Deja de Martillar una Dependencia en Dificultades: Patrones de Reintento para Azure Functions + Service Bus

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

Aquí te explicamos cómo una falla recuperable se convierte en una interrupción en una aplicación de Functions: una dependencia comienza a dar timeout, cada instancia de Function reintenta inmediatamente e indefinidamente, la dependencia recibe cientos de solicitudes fallidas concurrentes, y lo que comenzó como un problema transitorio se convierte en un evento de contrapresión en todo el sistema.

Probablemente conoces esta historia. Azure Functions escala rápidamente — ese es todo el punto. Pero “escalar rápidamente” y “reintentar inmediatamente” juntos pueden empeorar dramáticamente las fallas.

Dos patrones ayudan. Retroceso exponencial y circuit breaker. Ambos ahora son compatibles de forma nativa para Azure Functions activadas por Service Bus.

Dos Patrones, Roles Diferentes

Estos patrones son complementarios, no alternativas:

El retroceso exponencial responde: ¿cuándo debería intentarlo de nuevo? Aumenta el retraso entre reintentos para que una dependencia tenga tiempo de recuperarse. A nivel de mensaje, marcando el ritmo del temporizador de reintento.

El circuit breaker responde: ¿debería llamar a esta dependencia ahora mismo? Detiene las llamadas repetidas a una dependencia poco saludable después de alcanzar un umbral de fallas, y luego sondea cuidadosamente después de un período de enfriamiento. A nivel de sistema, previniendo tormentas de reintentos.

Quieres ambos. El retroceso maneja el ritmo de reintento por mensaje. El circuit breaker maneja las decisiones de salud agregadas.

Por Qué Importa Especialmente para Service Bus

La cola absorbe el tráfico en ráfagas, lo que es bueno. Pero sin controles, la cola puede crecer mientras los workers continúan desperdiciando cómputo en llamadas que fallarán. Los mensajes envenenados permanecen activos más tiempo del que deberían. Las particiones calientes o la capacidad aguas abajo limitada crean problemas en cascada.

El diseño más seguro:

Detectar la falla transitoria
Retrasar el próximo intento con retroceso exponencial
Detener las llamadas a la dependencia cuando se alcanza un umbral de fallas (circuito abierto)
Reanudar cuidadosamente después de un período de enfriamiento (sonda de circuito)
Mover el trabajo irrecuperable a dead-letter o a una ruta de cuarentena

Cómo se Ve el Soporte Nativo

El nuevo soporte se integra con el modelo de host existente de Azure Functions — sin bibliotecas adicionales, sin implementaciones personalizadas. La configuración va en tu host.json:

{
 "extensions": {
 "serviceBus": {
 "messageHandlerOptions": {
 "maxRetryCount": 5,
 "retryPolicy": {
 "mode": "exponentialBackoff",
 "minBackoff": "00:00:02",
 "maxBackoff": "00:05:00",
 "maxRetryCount": 5
 }
 }
 }
 }
}

La configuración del circuit breaker establece el umbral de fallas y el intervalo de restablecimiento para que las dependencias poco saludables no sean acosadas durante la recuperación.

Lenguajes Cubiertos

Esto no es solo para .NET. La funcionalidad cubre dotnet, JavaScript, TypeScript y Python — el conjunto completo de lenguajes compatibles con el trigger de Service Bus en Azure Functions.

Conclusión

Los patrones de reintento no son emocionantes de configurar hasta la primera vez que una interrupción aguas abajo hace que tus Functions empeoren el problema en lugar de degradarse correctamente. Configurarlos de manera proactiva es barato. Implementarlos durante un incidente no lo es.

Post original: Exponential backoff and circuit breaker for Service Bus-triggered Azure Functions

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

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

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

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.

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

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

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.