Multi-Agent | The .NET Blog

Il Pattern Handoff: Quando Un Agente Non Basta

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

A un certo punto ogni sistema multi-agente supera un semplice router. Il primo segnale è di solito quando un agente specialista deve fare una domanda di follow-up, o si rende conto a metà turno che un altro agente dovrebbe continuare. Una pipeline fissa fallisce lì. Un router a singolo passaggio fallisce lì.

È esattamente il problema per cui il pattern di orchestrazione Handoff in Microsoft Agent Framework è progettato.

Come Funziona Handoff

Lo sviluppatore dichiara un grafo: ecco gli agenti, ecco i bordi tra di loro. Il framework fa il resto — sintetizza uno strumento handoff per ogni bordo in uscita e lo inietta in ogni agente. Quando un agente decide di cedere il controllo, chiama lo strumento. Il framework applica la topologia.

Tre cose rendono questo diverso dal semplice fare in modo che gli agenti si chiamino tra di loro:

Una trascrizione condivisa — l’agente ricevente vede l’intera cronologia della conversazione. Senza ricominciare da zero.
Applicazione della topologia — un agente può fare handoff solo a destinazioni dichiarate. I bug di routing vengono rilevati in fase di authoring, non in produzione.
Terminazione naturale — quando l’agente attivo finisce il suo turno senza chiamare uno strumento handoff, il workflow cede all’utente. Senza polling, senza condizioni di uscita esplicite.

Un Esempio Minimale

In .NET, costruire un workflow handoff appare così:

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 può inviare a entrambi i specialisti. Entrambi i specialisti possono rimandare a triage. Il grafo è compatibile con l’aciclico ma supporta bordi posteriori quando ne hai bisogno (“ho bisogno di più informazioni” → torna alla ricerca).

Quando Usare Handoff (e Quando No)

Handoff è una buona scelta quando:

La proprietà può cambiare a metà conversazione — un agente può rendersi conto di essere lo specialista sbagliato
I bordi posteriori contano — potresti dover rivisitare un passo precedente senza ricominciare
Le decisioni di routing sono sfumate — la decisione di fare handoff è contestuale e meglio presa dal modello che da predicati tipizzati

Non è la scelta giusta quando:

La tua pipeline è fissa e sequenziale — usa il workflow Sequential per quello
Ogni passo è indipendente — agenti che condividono una trascrizione dove solo uno di loro ne aveva bisogno è solo rumore
Hai bisogno di garanzie di elaborazione rigorose — il non-determinismo del routing guidato dal modello non è ciò che vuoi

Bordi Posteriori e Human-in-the-Loop

Una delle forme più interessanti che Handoff consente sono i veri bordi posteriori. Un agente può decidere “non ho abbastanza informazioni” e tornare a un passo di ricerca, non con un loop codificato, ma perché il modello decide che è la scelta giusta.

Le interazioni human-in-the-loop si compongono naturalmente. Quando uno specialista ha bisogno dell’input dell’utente, il workflow cede all’utente tramite il loop di turno predefinito, raccoglie la risposta e riprende con il contesto completo. L’agente non ha mai perso la conversazione.

Conclusione

Handoff è uno di quei pattern che sembra semplice ma permette molto una volta interiorizzato: routing decentralizzato, contesto condiviso, topologia applicata, terminazione naturale. È il giusto passo successivo quando i tuoi agenti cominciano a dire “in realtà, qualcun altro dovrebbe gestire questo.”

Leggi il percorso completo nel post originale: A Tour of the Handoff Orchestration Pattern

Costruire UI Multi-Agente in Tempo Reale Che Non Sembrino una Scatola Nera

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

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Ecco il punto dei sistemi multi-agente: nelle demo sono incredibili. Tre agenti che si passano il lavoro, risolvono problemi, prendono decisioni. Poi provi a metterlo davanti a utenti reali e… silenzio. Un indicatore che gira. Nessuna idea di quale agente stia facendo cosa o perché il sistema sia in pausa. Quello non è un prodotto — è un problema di fiducia.

Il team di Microsoft Agent Framework ha appena pubblicato un fantastico walkthrough su come accoppiare i workflow MAF con AG-UI, un protocollo aperto per lo streaming degli eventi di esecuzione degli agenti verso un frontend tramite Server-Sent Events. E onestamente? È esattamente il ponte che ci mancava.

Perché questo è importante per gli sviluppatori .NET

Se stai costruendo app alimentate dall’IA, probabilmente hai già sbattuto contro questo muro. La tua orchestrazione backend funziona benissimo — gli agenti si passano il lavoro, gli strumenti si attivano, le decisioni vengono prese. Ma il frontend non ha idea di cosa stia succedendo dietro le quinte. AG-UI risolve questo definendo un protocollo standard per lo streaming degli eventi degli agenti (pensa a RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_*) direttamente verso il tuo layer UI tramite SSE.

La demo è un workflow di supporto clienti con tre agenti: un agente di triage che smista le richieste, un agente rimborsi che gestisce le questioni di denaro, e un agente ordini che gestisce le sostituzioni. Ogni agente ha i propri strumenti, e la topologia di handoff è definita esplicitamente — niente “scoprilo dal prompt”.

La topologia di handoff è la vera star

Quello che mi ha colpito è come HandoffBuilder ti permette di dichiarare un grafo di routing diretto tra gli agenti:

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.")
)

Ogni add_handoff crea un arco diretto con una descrizione in linguaggio naturale. Il framework genera strumenti di handoff per ogni agente basandosi su questa topologia. Quindi le decisioni di routing sono fondate sulla tua struttura di orchestrazione, non solo su quello che il LLM decide di fare. Questo è un vantaggio enorme per l’affidabilità in produzione.

Human-in-the-loop che funziona davvero

La demo mostra due pattern di interruzione di cui qualsiasi app di agenti reale ha bisogno:

Interruzioni di approvazione strumenti — quando un agente chiama uno strumento marcato con approval_mode="always_require", il workflow si mette in pausa ed emette un evento. Il frontend mostra un modal di approvazione con il nome dello strumento e i suoi argomenti. Niente loop di retry che bruciano token — solo un flusso pulito pausa-approvazione-ripresa.

Interruzioni di richiesta informazioni — quando un agente ha bisogno di più contesto dall’utente (come un ID ordine), si mette in pausa e chiede. Il frontend mostra la domanda, l’utente risponde, e l’esecuzione riprende esattamente da dove si era fermata.

Entrambi i pattern vengono trasmessi come eventi AG-UI standard, quindi il tuo frontend non ha bisogno di logica personalizzata per agente — semplicemente renderizza qualsiasi evento arrivi dalla connessione SSE.

Collegare il tutto è sorprendentemente semplice

L’integrazione tra MAF e AG-UI si riduce a una singola chiamata di funzione:

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",
)

La workflow_factory crea un workflow fresco per thread, così ogni conversazione ottiene il proprio stato isolato. L’endpoint gestisce tutta l’infrastruttura SSE automaticamente. Se stai già usando FastAPI (o puoi aggiungerlo come layer leggero), c’è praticamente zero frizione.

La mia opinione

Per noi sviluppatori .NET, la domanda immediata è: “Posso farlo in C#?” L’Agent Framework è disponibile sia per .NET che per Python, e il protocollo AG-UI è agnostico rispetto al linguaggio (è solo SSE). Quindi anche se questa demo specifica usa Python e FastAPI, il pattern si traduce direttamente. Potresti configurare una API minimale ASP.NET Core con endpoint SSE seguendo lo stesso schema di eventi AG-UI.

Il messaggio più importante è che le UI multi-agente stanno diventando una preoccupazione di prima classe, non un ripensamento. Se stai costruendo qualcosa dove gli agenti interagiscono con gli umani — supporto clienti, workflow di approvazione, elaborazione documenti — questa combinazione di orchestrazione MAF e trasparenza AG-UI è il pattern da seguire.

Per concludere

AG-UI + Microsoft Agent Framework ti dà il meglio di entrambi i mondi: orchestrazione multi-agente robusta nel backend e visibilità in tempo reale nel frontend. Niente più interazioni tra agenti come scatole nere.

Dai un’occhiata al walkthrough completo e al repository del protocollo AG-UI per approfondire.

Microsoft Agent Framework Raggiunge la 1.0 — Ecco Cosa Conta Davvero per gli Sviluppatori .NET

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

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Se hai seguito il percorso di Agent Framework dai primi giorni di Semantic Kernel e AutoGen, questo è significativo. Microsoft Agent Framework ha appena raggiunto la versione 1.0 — pronto per la produzione, API stabili, impegno di supporto a lungo termine. È disponibile sia per .NET che per Python, ed è genuinamente pronto per carichi di lavoro reali.

Vi taglio attraverso il rumore dell’annuncio e mi concentro su ciò che conta se state costruendo app alimentate dall’IA con .NET.

La versione breve

Agent Framework 1.0 unifica quello che erano Semantic Kernel e AutoGen in un singolo SDK open source. Un’astrazione di agente. Un motore di orchestrazione. Molteplici provider di IA. Se avete saltato tra Semantic Kernel per i pattern enterprise e AutoGen per i workflow multi-agente di livello ricerca, potete smettere. Questo è l’unico SDK ora.

Iniziare è quasi ingiustamente semplice

Ecco un agente funzionante in .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."));

Tutto qui. Una manciata di righe e hai un agente IA che gira su Azure Foundry. L’equivalente Python è altrettanto conciso. Aggiungi strumenti di funzione, conversazioni multi-turno e streaming man mano che procedi — la superficie dell’API scala senza diventare strana.

Orchestrazione multi-agente — questa è la cosa seria

Gli agenti singoli vanno bene per le demo, ma gli scenari di produzione di solito necessitano di coordinamento. Agent Framework 1.0 arriva con pattern di orchestrazione testati in battaglia direttamente da Microsoft Research e AutoGen:

Sequenziale — gli agenti elaborano in ordine (scrittore → revisore → editor)
Concorrente — distribuisci a più agenti in parallelo, convergi i risultati
Handoff — un agente delega a un altro in base all’intento
Chat di gruppo — più agenti discutono e convergono su una soluzione
Magentic-One — il pattern multi-agente di livello ricerca di MSR

Tutti supportano streaming, checkpointing, approvazioni human-in-the-loop e pausa/ripresa. La parte di checkpointing è cruciale — i workflow di lunga durata sopravvivono ai riavvii del processo. Per noi sviluppatori .NET che abbiamo costruito workflow durevoli con Azure Functions, questo è familiare.

Le funzionalità che contano di più

Ecco la mia lista di ciò che vale la pena sapere:

Hook middleware. Sapete come ASP.NET Core ha le pipeline middleware? Stesso concetto, ma per l’esecuzione degli agenti. Intercetta ogni fase — aggiungi sicurezza dei contenuti, logging, policy di conformità — senza toccare i prompt dell’agente. È così che rendi gli agenti pronti per l’enterprise.

Memoria pluggable. Storico conversazionale, stato persistente chiave-valore, recupero basato su vettori. Scegli il tuo backend: Foundry Agent Service, Mem0, Redis, Neo4j, o costruisci il tuo. La memoria è ciò che trasforma una chiamata LLM senza stato in un agente che ricorda davvero il contesto.

Agenti YAML dichiarativi. Definisci le istruzioni del tuo agente, gli strumenti, la memoria e la topologia di orchestrazione in file YAML versionati. Carica ed esegui con una singola chiamata API. Questo è un game-changer per i team che vogliono iterare sul comportamento dell’agente senza ridistribuire il codice.

Supporto A2A e MCP. MCP (Model Context Protocol) permette agli agenti di scoprire e invocare strumenti esterni dinamicamente. A2A (protocollo Agent-to-Agent) abilita la collaborazione cross-runtime — i tuoi agenti .NET possono coordinarsi con agenti in esecuzione in altri framework. Il supporto A2A 1.0 arriverà presto.

Le funzionalità in preview da tenere d’occhio

Alcune funzionalità sono state rilasciate come preview nella 1.0 — funzionali ma le API potrebbero evolvere:

DevUI — un debugger locale basato su browser per visualizzare l’esecuzione dell’agente, i flussi di messaggi e le chiamate agli strumenti in tempo reale. Pensate ad Application Insights, ma per il ragionamento dell’agente.
GitHub Copilot SDK e Claude Code SDK — usa Copilot o Claude come harness dell’agente direttamente dal tuo codice di orchestrazione. Componi un agente capace di programmare accanto ai tuoi altri agenti nello stesso workflow.
Agent Harness — un runtime locale personalizzabile che dà agli agenti accesso a shell, file system e loop di messaggistica. Pensate ad agenti di coding e pattern di automazione.
Skills — pacchetti riutilizzabili di capacità di dominio che danno agli agenti capacità strutturate pronte all’uso.

Migrazione da Semantic Kernel o AutoGen

Se avete codice Semantic Kernel o AutoGen esistente, ci sono assistenti di migrazione dedicati che analizzano il vostro codice e generano piani di migrazione passo dopo passo. La guida alla migrazione da Semantic Kernel e la guida alla migrazione da AutoGen vi accompagnano attraverso tutto.

Se siete stati sui pacchetti RC, l’aggiornamento alla 1.0 è solo un cambio di versione.

Per concludere

Agent Framework 1.0 è il traguardo di produzione che i team enterprise stavano aspettando. API stabili, supporto multi-provider, pattern di orchestrazione che funzionano davvero su scala, e percorsi di migrazione sia da Semantic Kernel che da AutoGen.

Il framework è completamente open source su GitHub, e potete iniziare oggi con dotnet add package Microsoft.Agents.AI. Date un’occhiata alla guida rapida e agli esempi per mettere le mani in pasta.

Se stavate aspettando il segnale “sicuro da usare in produzione” — eccolo.