Multi-Agent | The .NET Blog

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

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.