Agent-Framework | The .NET Blog

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

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

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

Foundry Local Está Disponible de Forma General

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

GPT-5.5

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

Trazado de Agent Framework en Foundry

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

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

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

CodeAct con Hyperlight (Alpha)

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

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

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

Panel de Monitoreo de Agentes (Vista Previa)

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

Evaluadores Personalizados de Evaluación Continua (Vista Previa)

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

Inventario de Agentes en el Plano de Control

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

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

El Patrón Handoff: Cuando Un Agente No Es Suficiente

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

En algún momento, todo sistema multi-agente supera un enrutador simple. La primera señal suele aparecer cuando un agente especialista necesita hacer una pregunta de seguimiento, o se da cuenta a mitad del turno de que otro agente debería continuar. Un pipeline fijo falla ahí. Un enrutador de un solo paso falla ahí.

Exactamente para eso está diseñado el patrón de orquestación Handoff en Microsoft Agent Framework.

Cómo Funciona Handoff

El desarrollador declara un grafo: aquí están los agentes, aquí están las aristas entre ellos. El framework hace el resto — sintetiza una herramienta de handoff por cada arista de salida y la inyecta en cada agente. Cuando un agente decide pasar el control, llama a la herramienta. El framework aplica la topología.

Tres cosas hacen esto diferente a simplemente hacer que los agentes se llamen entre sí:

Un transcripto compartido — el agente receptor ve el historial completo de la conversación. Sin empezar desde cero.
Aplicación de topología — un agente solo puede hacer handoff a destinos declarados. Los errores de enrutamiento se detectan en tiempo de autoría, no en producción.
Terminación natural — cuando el agente activo termina su turno sin llamar a una herramienta de handoff, el flujo de trabajo cede al usuario. Sin sondeo, sin condiciones de salida explícitas.

Un Ejemplo Mínimo

En .NET, construir un flujo de trabajo handoff se ve así:

using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Workflows;

AIAgent triage = chatClient.AsAIAgent(
 instructions: "Route to the right specialist.",
 name: "Triage");

AIAgent billing = chatClient.AsAIAgent(
 instructions: "Handle billing questions.",
 name: "Billing");

AIAgent tech = chatClient.AsAIAgent(
 instructions: "Handle technical support.",
 name: "Tech");

var workflow = HandoffWorkflow.Create()
 .Add(triage, targets: [billing, tech])
 .Add(billing, targets: [triage])
 .Add(tech, targets: [triage, billing]);

Triage puede enviar a cualquier especialista. Ambos especialistas pueden enviar de vuelta a triage. El grafo es compatible con acíclico pero admite aristas hacia atrás cuando las necesitas (“necesito más información” → de vuelta a investigación).

Cuándo Usar Handoff (y Cuándo No)

Handoff es una buena opción cuando:

La propiedad puede cambiar a mitad de conversación — un agente puede darse cuenta de que es el especialista equivocado
Las aristas hacia atrás importan — puede que necesites revisar un paso anterior sin reiniciar
Las decisiones de enrutamiento son difusas — la decisión de hacer handoff es contextual y mejor tomada por el modelo que por predicados tipificados

No es la elección correcta cuando:

Tu pipeline es fijo y secuencial — usa el flujo de trabajo Sequential para eso
Cada paso es independiente — los agentes compartiendo un transcripto donde solo uno de ellos lo necesitaba es solo ruido
Necesitas garantías estrictas de procesamiento — la no determinismo del enrutamiento impulsado por modelos no es lo que deseas

Aristas hacia Atrás y Humano en el Bucle

Una de las formas más interesantes que Handoff permite son las aristas hacia atrás genuinas. Un agente puede decidir “no tengo suficiente información” y enrutar de vuelta a un paso de investigación, no con un bucle codificado, sino porque el modelo decide que es la decisión correcta.

Las interacciones de humano en el bucle también se componen naturalmente. Cuando un especialista necesita entrada del usuario, el flujo de trabajo cede de vuelta al usuario a través del bucle de turno predeterminado, recopila la respuesta y se reanuda con contexto completo. El agente nunca perdió la conversación.

Conclusión

Handoff es uno de esos patrones que suena simple pero permite mucho una vez que lo internalizas: enrutamiento descentralizado, contexto compartido, topología aplicada, terminación natural. Es el siguiente paso correcto cuando tus agentes comienzan a decir “en realidad, alguien más debería manejar esto.”

Lee el recorrido completo en el post original: A Tour of the Handoff Orchestration Pattern

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

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

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

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

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

Lo Que Foundry Hosted Agents Realmente Hace

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

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

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

La Diferencia en el Código Es Mínima

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

En .NET:

using Microsoft.Agents.AI.Foundry.Hosting;

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

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

app.Run();

En Python:

server = ResponsesHostServer(agent)
server.run()

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

Dos Protocolos, Un Agente

Los Hosted Agents soportan dos estilos de endpoints:

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

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

El Flujo de Despliegue con `azd`

Cuando ejecutas azd up con un agente MAF:

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

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

Conclusión

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

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

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

Construir Agentes Es la Parte Fácil — Ejecutarlos de Forma Segura Es la Parte Difícil

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

Hay un patrón en el desarrollo de agentes de IA que he empezado a llamar “arrepentimiento de demo”. El agente funciona genial en las demos. Luego alguien pregunta: ¿qué pasa si llama a la herramienta equivocada? ¿Y si accede a datos que no debería? ¿Quién auditó eso?

Microsoft Agent Framework te respalda para construir y orquestar. Agent Governance Toolkit (AGT) cubre la parte posterior — gobernanza, aplicación de políticas y auditabilidad en tiempo de ejecución.

Qué Hace Realmente Cada Proyecto

Microsoft Agent Framework (MAF) te proporciona el modelo de programación: flujos de trabajo multi-agente, interoperabilidad del protocolo A2A, hooks de middleware, memoria y alojamiento administrado a través de Foundry Agent Service. Maneja la seguridad de contenido a nivel de entrada/salida del modelo.

Agent Governance Toolkit (AGT) se conecta a ese mismo pipeline de middleware para gobernar acciones. Cada llamada a herramienta, acceso a recursos y mensaje entre agentes se evalúa contra la política antes de la ejecución. Sobrecarga de submilisegundos. Sin sidecars, sin proxies, sin prompts modificados.

Acción del Agente --> Verificación de Política --> Permitir / Denegar --> Registro de Auditoría (< 0.1 ms)

Capas diferentes, cobertura completa, un pipeline.

Conectarse Es Solo Agregar Middleware

En Python, AGT se agrega al mismo parámetro middleware que usarías para registro o filtros de contenido:

agent = Agent(
 client=OpenAIChatClient(model="gpt-5.3"),
 name="Contoso Loan Officer",
 instructions="You are a governed loan assistant.",
 tools=[check_credit_score, get_loan_rates, approve_small_loan],
 middleware=[
 AuditTrailMiddleware(audit_log=audit_log, agent_did="loan-agent"),
 GovernancePolicyMiddleware(evaluator=evaluator, audit_log=audit_log),
 CapabilityGuardMiddleware(allowed_tools=["check_credit_score", "get_loan_rates"]),
 RogueDetectionMiddleware(detector=detector, agent_id="loan-agent"),
 ],
)

En .NET, el mismo patrón a través de .Use():

var agent = builder.BuildAIAgent(model: "gpt-5.3")
 .Use(new GovernancePolicyMiddleware(evaluator))
 .Use(new CapabilityGuardMiddleware(allowedTools))
 .Use(new AuditTrailMiddleware(auditLog));

Mismo agente, misma orquestación, mismas herramientas. AGT agrega capacidades de gobernanza sin tocar la lógica del agente.

Lo Que Obtienes

GovernancePolicyMiddleware — evalúa cada acción contra reglas de política declarativas
CapabilityGuardMiddleware — lista de permitidos qué herramientas tiene permiso de llamar un agente (la herramienta approve_small_loan no está en la lista de permitidos arriba — deliberadamente)
RogueDetectionMiddleware — detecta patrones de comportamiento anómalo en tiempo de ejecución
AuditTrailMiddleware — registro de auditoría encadenado con Merkle para que cada acción sea criptográficamente resistente a manipulaciones

Este último importa para el cumplimiento normativo. Una cadena Merkle significa que si alguien modifica el registro, la cadena se rompe. La auditoría es la evidencia.

Cinco Escenarios de la Industria

El repositorio de AGT incluye cinco escenarios completos de extremo a extremo: servicios financieros (oficial de préstamos), atención médica (datos de pacientes), legal (revisión de contratos), gobierno (servicios al ciudadano) y manufactura (control de calidad). Cada uno combina agentes MAF reales con middleware de gobernanza AGT real.

Estas no son demos de juguete. Son el tipo de escenarios donde realmente necesitarías gobernanza en producción.

Conclusión

Si estás construyendo agentes que tocan datos reales, toman decisiones con consecuencias, o se ejecutan sin supervisión en producción — la gobernanza no es opcional. La combinación de MAF + AGT te brinda el stack completo: constrúyelo con Agent Framework, govírnalo con AGT.

Ambos proyectos son de código abierto. El artículo original tiene enlaces a los ejemplos de código completos.

Publicación original: Governance at the Speed of Agents: Microsoft Agent Framework and Agent Governance Toolkit, Better Together

A2A v1 Ha Llegado: Comunicación Entre Agentes Cross-Platform en Microsoft Agent Framework para .NET

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

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

A2A v1 Ha Llegado: Comunicación Entre Agentes Cross-Platform en Microsoft Agent Framework para .NET — el Protocolo A2A acaba de alcanzar v1.0, y tanto el paquete A2A Agent (cliente) como A2A Hosting (servidor) para .NET han sido actualizados.

Qué es A2A v1 realmente

A2A es un protocolo de interoperabilidad abierto para agentes de IA respaldado por un comité directivo técnico con representantes de AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP y ServiceNow. La etiqueta v1 significa que ahora es un estándar estable y listo para producción. Los paquetes SDK y Agent Framework que lo implementan aún están en preview, pero el protocolo en sí está bloqueado.

v1 mejora v0.3 con soporte multi-tenant, Agent Cards firmadas para identidad criptográfica, flujos de seguridad mejorados y una arquitectura alineada con la web.

Conectarse a un agente A2A remoto

Un agente A2A remoto es simplemente un AIAgent en tu código — el mismo RunAsync, el mismo streaming, el mismo manejo de sesiones:

// Descubrimiento via URI conocida
A2ACardResolver resolver = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = await resolver.GetAIAgentAsync();
Console.WriteLine(await agent.RunAsync("What's the weather in Seattle?"));

// Configuración directa
A2AClient a2aClient = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = a2aClient.AsAIAgent(name: "my-agent", description: "A helpful assistant.");

// El streaming funciona igual
await foreach (var update in agent.RunStreamingAsync("Write a short summary..."))
 Console.Write(update.Text);

El enfoque A2ACardResolver hace el descubrimiento automático via el endpoint /.well-known/agent-card.json. El camino directo con A2AClient te da control explícito sobre el nombre y descripción.

Exponer tu agente como endpoint A2A

Cualquier AIAgent que hayas construido — en Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic o AWS Bedrock — puede exponerse como endpoint A2A con dos líneas en ASP.NET Core:

builder.Services.AddKeyedSingleton<AIAgent>("weather-agent", (sp, _) => ...);
builder.AddA2AServer("weather-agent");

La tarjeta del agente se sirve automáticamente en /.well-known/agent-card.json.

Lo que esto significa en la práctica

El protocolo estable v1 significa que puedes conectar tus agentes .NET con agentes construidos en Python, Java o cualquier otro lenguaje sin preocuparte por cambios que rompan compatibilidad. La identidad criptográfica en las Agent Cards firmadas también te da una base para la verificación de confianza entre agentes.

Consulta el post completo para el registro de cambios completo y las notas de migración desde v0.3.

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

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.

Las Agent Skills en .NET se volvieron muy flexibles

Emiliano Montesdeoca — Tue, 14 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 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.

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

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

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.

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

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

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.

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.

Agent-Framework | The .NET Blog

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

Foundry Local Está Disponible de Forma General

GPT-5.5

Trazado de Agent Framework en Foundry

CodeAct con Hyperlight (Alpha)

Panel de Monitoreo de Agentes (Vista Previa)

Evaluadores Personalizados de Evaluación Continua (Vista Previa)

Inventario de Agentes en el Plano de Control

El Patrón Handoff: Cuando Un Agente No Es Suficiente

Cómo Funciona Handoff

Un Ejemplo Mínimo

Cuándo Usar Handoff (y Cuándo No)

Aristas hacia Atrás y Humano en el Bucle

Conclusión

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

Los Bloques de Construcción Básicos

El Corredor In-Memory para Desarrollo Local

Agregar Durabilidad con Durable Task

Hospedaje en Azure Functions

Por Qué Importa Esto

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

Lo Que Foundry Hosted Agents Realmente Hace

La Diferencia en el Código Es Mínima

Dos Protocolos, Un Agente

El Flujo de Despliegue con azd

Conclusión

Construir Agentes Es la Parte Fácil — Ejecutarlos de Forma Segura Es la Parte Difícil

Qué Hace Realmente Cada Proyecto

Conectarse Es Solo Agregar Middleware

Lo Que Obtienes

Cinco Escenarios de la Industria

Conclusión

A2A v1 Ha Llegado: Comunicación Entre Agentes Cross-Platform en Microsoft Agent Framework para .NET

Qué es A2A v1 realmente

Conectarse a un agente A2A remoto

Exponer tu agente como endpoint A2A

Lo que esto significa en la práctica

¿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

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

Las Agent Skills en .NET se volvieron muy flexibles

Skills basadas en archivos: el punto de partida

Skills basadas en clases: distribuir vía NuGet

Skills inline: el puente rápido

Aprobación de scripts: humano en el bucle

Por qué esta combinación importa

Para cerrar

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

Por qué esto importa para desarrolladores .NET

La topología de handoff es la verdadera estrella

Human-in-the-loop que realmente funciona

Conectarlo todo es sorprendentemente simple

Mi opinión

Para cerrar

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

La versión corta

Empezar es casi injustamente simple

Orquestación multi-agente — esto va en serio

Las funcionalidades que más importan

Las funcionalidades en preview que vale la pena seguir

Migrando desde Semantic Kernel o AutoGen

Para cerrar

El Flujo de Despliegue con `azd`