Agent-Framework | The .NET Blog

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

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

Un mese impegnativo per Microsoft Foundry. Ecco gli annunci più importanti.

Foundry Local è Generalmente Disponibile

Foundry Local — il runtime AI locale multipiattaforma di Microsoft — passa dalla preview alla GA su Windows, macOS (Apple Silicon) e Linux x64. Inferenza di modelli locali pronta per la produzione con un SDK orientato agli sviluppatori. La versione 1.1 aggiunge il supporto per trascrizione, embeddings e API Responses.

GPT-5.5

L’ultimo modello della famiglia GPT-5 è ora disponibile in Foundry. Quota predefinita per gli abbonamenti Tier 5 e Tier 6. Se hai lavorato con varianti precedenti di GPT-5, vale la pena valutarlo per i tuoi casi d’uso.

Tracing di Agent Framework in Foundry

Due funzionalità di tracing vengono rilasciate in anteprima questo mese:

Tracing di Microsoft Agent Framework — Gli agenti MAF possono ora emettere trace OpenTelemetry in Foundry. Esegui il debug del comportamento degli agenti, traccia l’esecuzione in più passaggi, individua latenza ed errori nelle chiamate agli strumenti. Questo colma una lacuna reale: sapere cosa ha effettivamente fatto il tuo agente in produzione, non solo cosa ha restituito.

Tracing degli agenti ospitati — Sessioni, chiamate agli strumenti e passaggi di esecuzione degli agenti ospitati appaiono anche nelle trace di Foundry. La stessa storia di osservabilità estesa al livello ospitato.

CodeAct con Hyperlight (Alpha)

Questa è l’aggiunta tecnicamente più interessante: Agent Framework può ora eseguire codice Python all’interno di micro-macchine virtuali Hyperlight.

CodeAct è il pattern in cui un agente genera ed esegue codice Python come strumento. La preoccupazione ovvia è la sicurezza — stai eseguendo codice generato dal modello. Le micro-VM di Hyperlight forniscono isolamento a livello di processo con tempi di avvio vicini al nativo, rendendo pratica l’esecuzione di codice in sandbox senza il sovraccarico di container o VM completi.

Per i flussi di lavoro agentici dove l’esecuzione di codice è necessaria, questo è un miglioramento significativo della sicurezza rispetto all’esecuzione di codice nel processo host.

Dashboard di Monitoraggio degli Agenti (Anteprima)

Un dashboard operativo unificato che combina l’utilizzo dei token, la latenza, il tasso di successo delle esecuzioni e i punteggi degli evaluator in un’unica vista. La distinzione dai normali dashboard di osservabilità: include i risultati di valutazione insieme alle metriche operative, così puoi correlare “l’agente è più lento” con “i punteggi dell’evaluator sono scesi” — o confermare che non sono correlati.

Evaluator Personalizzati per la Valutazione Continua (Anteprima)

Ora puoi portare i tuoi evaluator basati su codice o prompt nelle pipeline di valutazione continua. In precedenza, la valutazione continua era limitata agli evaluator integrati. Gli evaluator personalizzati ti permettono di applicare criteri di qualità specifici del team nel tuo ciclo di monitoraggio in produzione.

Inventario degli Agenti nel Piano di Controllo

La vista Operate del Piano di Controllo di Foundry mostra ora tutti gli agenti supportati in un abbonamento: agenti Foundry, Azure SRE Agent, cicli di agenti Logic Apps e agenti personalizzati registrati. Una vista per capire cosa è distribuito e dove.

Post originale: What’s new in Microsoft Foundry | April 2026

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

Workflow Durevoli in Microsoft Agent Framework: Da In-Memory ad Azure Functions

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

Uno dei punti dolenti dei primi workflow di agenti IA: sono fragili. Un workflow multi-step a lunga esecuzione legato a un singolo processo significa che il riavvio del processo = stato perso. Per demo semplici va bene. Per carichi di lavoro in produzione non lo è.

Il modello di programmazione del workflow di Microsoft Agent Framework ora supporta l’esecuzione durevole, basata sul framework Durable Task, con hosting Azure Functions. Ecco come funziona il modello di programmazione e perché la storia della durabilità conta.

I Blocchi Fondamentali

Gli Executor sono l’unità fondamentale di lavoro. Ognuno è tipizzato — prende un input specifico e produce un output specifico:

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)
 {
 // cercare l'ordine, restituirlo
 return new Order(Id: message.OrderId, ...);
 }
}

I Workflow collegano gli executor in grafi diretti usando un builder fluente. Il framework gestisce l’esecuzione, il flusso di dati tra i passi e la propagazione degli errori.

Puoi modellare:

Catene sequenziali (passo A → passo B → passo C)
Fan-out/fan-in parallelo (eseguire gli agenti A, B, C in parallelo, aggregare i risultati)
Ramificazione condizionale
Approvazioni umano-nel-ciclo (mettere in pausa il workflow, attendere un segnale esterno)

Il Runner In-Memory per lo Sviluppo Locale

Iniziare è veloce:

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

Il pacchetto principale include un runner leggero in-process. Nessuna dipendenza esterna, nessun database, nessuna risorsa Azure. Funziona benissimo per lo sviluppo locale e i test unitari.

Aggiungere Durabilità con Durable Task

Quando un workflow deve sopravvivere ai riavvii del processo — perché è a lunga esecuzione, perché ha passi umano-nel-ciclo, perché si distribuisce su molte chiamate di agenti in parallelo — il runner in-memory non è sufficiente.

L’integrazione Durable Task di MAF memorizza lo stato del workflow in Azure Storage. Se il processo si riavvia, il workflow riprende da dove si era fermato. Il modello di programmazione rimane lo stesso; basta sostituire il runner.

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

Gli stessi executor, lo stesso grafo del workflow — basato su stato durevole.

Hosting Azure Functions

Il terzo livello è l’hosting Azure Functions. Il tuo workflow diventa un’app Function: attiva il workflow tramite un endpoint HTTP, e il runtime durevole gestisce scalabilità, stato e affidabilità.

Ciò significa che un workflow multi-agente con chiamate parallele, rami condizionali e approvazioni umane può scalare in un ambiente Functions serverless senza gestione dello stato personalizzata.

Perché Questo È Importante

La combinazione è significativa per i veri sistemi IA:

Chiamate di agenti in parallelo — distribuire a più agenti specializzati simultaneamente senza blocchi, aggregare i risultati quando tutti completano
Processi a lunga esecuzione — i workflow che coinvolgono approvazione umana o eventi esterni possono mettere in pausa e riprendere per ore o giorni
Scalabilità — Azure Functions scala l’esecuzione orizzontalmente; il framework Durable Task gestisce il coordinamento dello stato parallelo

Se stai costruendo workflow MAF oltre semplici demo locali, questo è il percorso verso l’esecuzione di qualità produzione.

Post originale: Durable Workflows in the Microsoft Agent Framework

Il Tuo Agente MAF Locale Ha Appena Trovato Casa in Produzione

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

Far funzionare un agente localmente è la parte divertente. La parte difficile è tutto ciò che viene dopo: distribuirlo senza impazzire, gestire le sessioni, configurare l’identità, collegare l’osservabilità. Di solito questo significa molta infrastruttura personalizzata.

Foundry Hosted Agents ha appena rimosso la maggior parte di quella infrastruttura per gli utenti di Microsoft Agent Framework (MAF).

Cosa Fa Realmente Foundry Hosted Agents

Quando distribuisci un agente MAF in Foundry Hosted Agents, la piattaforma gestisce una lista sorprendentemente lunga di cose che altrimenti dovresti costruire tu stesso:

Scala a zero — il tuo agente non costa nulla quando è inattivo e si riavvia automaticamente
Sandbox isolati per VM per sessione — ogni sessione utente ottiene il proprio sandbox con persistenza del filesystem che sopravvive agli eventi di riduzione dello scale
Entra ID integrato — ogni agente ottiene la propria identità per chiamare modelli Foundry, Toolbox e servizi Azure senza segreti nell’immagine
Deployment versionati — ogni deployment è uno snapshot immutabile, con supporto per blue/green e canary rollout
Osservabilità senza configurazione — APPLICATIONINSIGHTS_CONNECTION_STRING viene iniettato a runtime in modo che le tracce OpenTelemetry di MAF fluiscano automaticamente in App Insights

Quest’ultimo è genuinamente piacevole. Nessun cablaggio aggiuntivo, nessuna configurazione extra. Le tracce appaiono semplicemente.

La Differenza nel Codice È Minima

Questo è ciò che apprezzo di più di questa integrazione. Non riscrivi il tuo agente. Lo avvolgi semplicemente:

In .NET:

using Microsoft.Agents.AI.Foundry.Hosting;

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

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

app.Run();

In Python:

server = ResponsesHostServer(agent)
server.run()

Tutto qui. La stessa logica che hai testato localmente è ciò che gira in produzione. La piattaforma la avvolge nell’infrastruttura di gestione delle sessioni, identità e scaling.

Due Protocolli, Un Agente

Gli Hosted Agents supportano due stili di endpoint:

Responses (/responses) — compatibile con OpenAI, gestisce la cronologia delle conversazioni e lo streaming. Buon default per agenti a forma di chat.
Invocations (/invocations) — tu definisci lo schema richiesta/risposta. Buono per workflow non conversazionali.

Se stai costruendo qualcosa che assomiglia a una conversazione, inizia con Responses. Se stai costruendo un agente a forma di API che prende input strutturato e restituisce output strutturato, Invocations ti dà la flessibilità.

Il Flusso di Deployment con `azd`

Quando esegui azd up con un agente MAF:

Crea opzionalmente un progetto Foundry e distribuisce un modello
Impacchetta il tuo codice e carica un’immagine su Azure Container Registry
Provvede compute dall’immagine ACR
Assegna un Entra ID dedicato all’agente
Espone un endpoint stabile (https://{project_endpoint}/agents/{agent_name})
Gestisce tutto il resto da quel punto in poi

Le sessioni persistono per un massimo di 30 giorni. Il compute inattivo viene deprovisionato dopo 15 minuti e ripristinato trasparentemente alla successiva richiesta. Dal punto di vista dell’agente, nulla è cambiato.

Conclusione

La distanza tra “funzionante localmente” e “in esecuzione in produzione” è stata storicamente lunga e dolorosa per gli agenti AI. Foundry Hosted Agents + MAF riduce significativamente questo divario. Se hai già un agente locale costruito con Agent Framework, vale la pena provarlo oggi.

Il team dice che GA arriverà presto — questo è attualmente in preview. Consulta i documenti di integrazione MAF Hosted Agent e gli esempi .NET per iniziare.

Articolo originale: From Local to Production: Deploy Your Microsoft Agent Framework Agent with Foundry Hosted Agents

Costruire Agenti È la Parte Facile — Eseguirli in Sicurezza È la Parte Difficile

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

C’è un pattern nello sviluppo di agenti IA che ho iniziato a chiamare “rimpianto della demo”. L’agente funziona benissimo nelle demo. Poi qualcuno chiede: cosa succede se chiama lo strumento sbagliato? E se accede a dati a cui non dovrebbe? Chi ha fatto l’audit?

Microsoft Agent Framework ti supporta per la costruzione e l’orchestrazione. Agent Governance Toolkit (AGT) copre la parte successiva — governance, applicazione delle policy e auditability a runtime.

Cosa Fa Davvero Ciascun Progetto

Microsoft Agent Framework (MAF) ti offre il modello di programmazione: workflow multi-agente, interoperabilità del protocollo A2A, hook middleware, memoria e hosting gestito tramite Foundry Agent Service. Gestisce la content safety a livello di input/output del modello.

Agent Governance Toolkit (AGT) si collega a quella stessa pipeline middleware per governare le azioni. Ogni chiamata a strumento, accesso alle risorse e messaggio inter-agente viene valutato rispetto alla policy prima dell’esecuzione. Overhead inferiore al millisecondo. Nessun sidecar, nessun proxy, nessun prompt modificato.

Azione Agente --> Controllo Policy --> Consenti / Nega --> Log Audit (< 0.1 ms)

Layer diversi, copertura completa, una pipeline.

Integrarsi È Solo Aggiungere Middleware

In Python, AGT si aggiunge allo stesso parametro middleware che useresti per il logging o i filtri di contenuto:

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

In .NET, lo stesso pattern via .Use():

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

Stesso agente, stessa orchestrazione, stessi strumenti. AGT aggiunge capacità di governance senza toccare la logica dell’agente.

Cosa Ottieni

GovernancePolicyMiddleware — valuta ogni azione rispetto alle regole di policy dichiarative
CapabilityGuardMiddleware — allowlist di quali strumenti un agente è autorizzato a chiamare (lo strumento approve_small_loan non è nell’elenco consentiti sopra — deliberatamente)
RogueDetectionMiddleware — rileva pattern di comportamento anomalo a runtime
AuditTrailMiddleware — log di audit con catena Merkle per rendere ogni azione crittograficamente resistente alle manomissioni

Quest’ultimo conta per la conformità. Una catena Merkle significa che se qualcuno modifica il log, la catena si spezza. L’audit è la prova.

Cinque Scenari di Settore

Il repository AGT include cinque scenari completi end-to-end: servizi finanziari (ufficiale prestiti), sanità (dati pazienti), legale (revisione contratti), governo (servizi ai cittadini) e produzione (controllo qualità). Ognuno abbina veri agenti MAF con vero middleware di governance AGT.

Non sono demo giocattolo. Sono il tipo di scenari in cui avresti davvero bisogno di governance in produzione.

Conclusione

Se stai costruendo agenti che toccano dati reali, prendono decisioni con conseguenze, o girano incustoditi in produzione — la governance non è opzionale. La combinazione MAF + AGT ti dà l’intero stack: costruiscilo con Agent Framework, governalo con AGT.

Entrambi i progetti sono open source. L’articolo originale ha link agli esempi di codice completi.

Post originale: Governance at the Speed of Agents: Microsoft Agent Framework and Agent Governance Toolkit, Better Together

A2A v1 È Arrivato: Comunicazione tra Agenti Cross-Platform in Microsoft Agent Framework per .NET

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

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

A2A v1 È Arrivato: Comunicazione tra Agenti Cross-Platform in Microsoft Agent Framework per .NET — il Protocollo A2A ha appena raggiunto la v1.0, e sia il pacchetto A2A Agent (client) che A2A Hosting (server) per .NET sono stati aggiornati.

Cosa è Realmente A2A v1

A2A è un protocollo di interoperabilità aperto per agenti IA supportato da un comitato direttivo tecnico con rappresentanti di AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP e ServiceNow. L’etichetta v1 significa che ora è uno standard stabile e pronto per la produzione. I pacchetti SDK e Agent Framework che lo implementano sono ancora in preview, ma il protocollo stesso è bloccato.

v1 migliora v0.3 con supporto multi-tenant, Agent Cards firmate per identità crittografica, flussi di sicurezza migliorati e un’architettura allineata al web.

Connettersi a un Agente A2A Remoto

Un agente A2A remoto è semplicemente un AIAgent nel tuo codice — stesso RunAsync, stesso streaming, stessa gestione delle sessioni:

// Scoperta tramite URI well-known
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?"));

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

// Lo streaming funziona allo stesso modo
await foreach (var update in agent.RunStreamingAsync("Write a short summary..."))
 Console.Write(update.Text);

Esporre il Tuo Agente come Endpoint A2A

Qualsiasi AIAgent che hai costruito — su Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic o AWS Bedrock — può essere esposto come endpoint A2A con due righe in ASP.NET Core:

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

La card dell’agente viene servita automaticamente su /.well-known/agent-card.json.

Cosa Significa Questo in Pratica

Il protocollo stabile v1 significa che puoi collegare i tuoi agenti .NET con agenti costruiti in Python, Java o qualsiasi altro linguaggio senza preoccuparti di breaking changes. L’identità crittografica nelle Agent Cards firmate fornisce anche una base per la verifica della fiducia tra agenti.

Consulta il post completo per il changelog completo e le note di migrazione da v0.3.

CodeAct in Agent Framework: Come Dimezzare la Latenza del tuo Agente

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

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

C’è quel momento in ogni progetto di agenti in cui guardi il trace e pensi: “perché ci vuole così tanto?” Il modello funziona bene. Gli strumenti funzionano. Ma ci sono sette round trip per ottenere un risultato che potresti calcolare in una sola volta.

Questo è esattamente il problema che CodeAct risolve — e il team di Agent Framework ha appena pubblicato il supporto alpha tramite il nuovo pacchetto agent-framework-hyperlight.

Cos’è CodeAct?

Il pattern CodeAct è elegantemente semplice: invece di dare al modello una lista di strumenti da chiamare uno alla volta, gli dai un unico strumento execute_code e lo lasci esprimere l’intero piano come un breve programma Python. L’agente scrive il codice una volta, la sandbox lo esegue, e ottieni un singolo risultato consolidato.

Approccio	Tempo	Token
Tradizionale	27,81s	6.890
CodeAct	13,23s	2.489
Miglioramento	52,4%	63,9%

La componente di sicurezza: Micro-VM Hyperlight

Il pacchetto agent-framework-hyperlight utilizza micro-VM di Hyperlight. Ogni chiamata execute_code ottiene la propria micro-VM appena creata. L’avvio si misura in millisecondi. L’isolamento è praticamente gratuito.

I tuoi strumenti continuano a girare sull’host. Il codice collante generato dal modello gira nella sandbox. Questa è la divisione giusta.

Configurazione minima

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

Quando usare CodeAct (e quando no)

Usa CodeAct quando:

Il task concatena molte piccole chiamate a strumenti (lookup, join, calcoli)
La latenza e il costo dei token contano
Vuoi un isolamento forte per chiamata sul codice generato dal modello

Resta con il tool-calling tradizionale quando:

L’agente fa solo una o due chiamate a strumenti per turno
Ogni chiamata ha effetti collaterali da approvare individualmente
Le descrizioni degli strumenti sono scarse o ambigue

Provalo ora

pip install agent-framework-hyperlight --pre

Leggi il post completo sul blog di Agent Framework per una copertura più approfondita.

Dove il tuo Agente Ricorda le Cose? Guida Pratica all'Archiviazione della Cronologia Chat

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

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

Quando costruisci un agente IA, dedichi la maggior parte dell’energia al modello, agli strumenti e ai prompt. La domanda su dove vive la cronologia della conversazione sembra un dettaglio di implementazione — ma è una delle decisioni architetturali più importanti che prenderai.

Determina se gli utenti possono ramificare le conversazioni, annullare le risposte, riprendere le sessioni dopo un riavvio e se i tuoi dati escono mai dalla tua infrastruttura. Il team di Agent Framework ha pubblicato un’analisi approfondita.

Due pattern fondamentali

Gestito dal servizio: il servizio IA archivia lo stato della conversazione. La tua app mantiene un riferimento e il servizio include automaticamente la cronologia rilevante in ogni richiesta.

Gestito dal client: la tua app mantiene la cronologia completa e invia messaggi rilevanti con ogni richiesta. Il servizio è stateless. Tu controlli tutto.

Come Agent Framework astrae questo

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Mi chiamo Alice.", session);
var second = await agent.RunAsync("Come mi chiamo?", session);

session = agent.create_session()
first = await agent.run("Mi chiamo Alice.", session=session)
second = await agent.run("Come mi chiamo?", session=session)

Riferimento rapido ai provider

Provider	Archiviazione	Modello	Compattazione
OpenAI/Azure Chat Completions	Client	N/A	Tu
Foundry Agent Service	Servizio	Lineare	Servizio
Responses API (default)	Servizio	Ramificabile	Servizio
Anthropic Claude, Ollama	Client	N/A	Tu

Come scegliere

Hai bisogno di ramificazione o “annulla”? → Responses API gestito dal servizio
Hai bisogno di sovranità dei dati? → Gestito dal client con provider di database
È un semplice chatbot? → Gestito dal servizio lineare va benissimo

Leggi il post completo per l’albero decisionale completo.

GPT-5.5 È Arrivato su Azure Foundry — Cosa Devono Sapere i Sviluppatori .NET

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

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

Microsoft ha appena annunciato che GPT-5.5 è generalmente disponibile in Microsoft Foundry. Se stai costruendo agenti su Azure, questo è l’aggiornamento che stavi aspettando.

La progressione di GPT-5

GPT-5: ha unificato ragionamento e velocità in un unico sistema
GPT-5.4: ragionamento multi-step più solido, capacità agentiche per l’enterprise
GPT-5.5: ragionamento in contesto lungo più profondo, esecuzione agentica più affidabile, migliore efficienza dei token

Cosa è cambiato davvero

Coding agentico migliorato: GPT-5.5 mantiene il contesto su grandi codebase, diagnostica guasti architetturali e anticipa i requisiti di test. Il modello ragiona su cos’altro influenza una correzione prima di agire.

Efficienza dei token: Output di qualità superiore con meno token e meno tentativi. Costo e latenza direttamente inferiori in produzione.

Analisi in contesto lungo: Gestisce documenti estesi e cronologie multi-sessione senza perdere il filo.

Prezzi

Modello	Input ($/M token)	Input in cache	Output ($/M token)
GPT-5.5	$5,00	$0,50	$30,00
GPT-5.5 Pro	$30,00	$3,00	$180,00

Perché Foundry è importante

Foundry Agent Service permette di definire agenti in YAML o collegarli con Microsoft Agent Framework, GitHub Copilot SDK, LangGraph o OpenAI Agents SDK — ed eseguirli come agenti ospitati isolati con filesystem persistente, identità Microsoft Entra e prezzi scale-to-zero.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "Sei un assistente utile.", name: "MioAgente");

Consulta l’annuncio completo per tutti i dettagli.

Le Agent Skills in .NET sono diventate davvero flessibili

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

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

Se avete costruito agenti con il Microsoft Agent Framework, conoscete il processo: definite le skill, le collegate a un provider e lasciate che l’agente decida quale invocare. La novità è come create queste skill — e il salto in flessibilità è significativo.

L’ultimo aggiornamento introduce tre pattern di authoring per le agent skill: basate su file, basate su classi e definite in codice inline. Tutte e tre si collegano a un unico AgentSkillsProviderBuilder, il che significa che potete mescolarle senza logica di routing o codice speciale. Vi mostro ciascuna e quando usarla.

Skill basate su file: il punto di partenza

Le skill basate su file sono esattamente quello che sembrano — una directory su disco con un file SKILL.md, script opzionali e documenti di riferimento. Il modo più diretto per dare nuove capacità al vostro agente:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

Il frontmatter di SKILL.md dichiara il nome e la descrizione, e la sezione istruzioni dice all’agente come usare script e riferimenti:

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

Poi lo collegate con SubprocessScriptRunner.RunAsync per l’esecuzione degli script:

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);

L’agente scopre la skill automaticamente e invoca lo script di provisioning quando deve verificare lo stato degli account. Pulito e semplice.

Skill basate su classi: distribuire via NuGet

Qui diventa interessante per i team. Le skill basate su classi derivano da AgentClassSkill<T> e usano attributi come [AgentSkillResource] e [AgentSkillScript] perché il framework scopra tutto tramite reflection:

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 });
 }
}

Il bello è che un team può impacchettarlo come pacchetto NuGet. Lo aggiungete al progetto, lo inserite nel builder e funziona accanto alle vostre skill basate su file senza coordinazione:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Entrambe le skill appaiono nel system prompt dell’agente. L’agente decide quale usare in base alla conversazione — nessun codice di routing necessario.

Skill inline: il ponte rapido

Conoscete quel momento in cui un altro team sta costruendo esattamente la skill di cui avete bisogno, ma non sarà pronta fino al prossimo sprint? AgentInlineSkill è il vostro ponte:

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 });
 });

Aggiungetela al builder come le altre:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Quando il pacchetto NuGet esce finalmente, sostituite la skill inline con la versione basata su classe. L’agente non nota la differenza.

Ma le skill inline non sono solo per i ponti. Sono anche la scelta giusta quando dovete generare skill dinamicamente a runtime — pensate a una skill per unità di business caricata dalla configurazione — o quando uno script deve catturare stato locale che non appartiene a un container DI.

Approvazione degli script: umano nel loop

Per noi sviluppatori .NET che costruiamo agenti di produzione, questa è la parte che sblocca davvero le discussioni sul deployment. Alcuni script hanno conseguenze reali — iscrivere qualcuno ai benefit, interrogare l’infrastruttura di produzione. Attivate UseScriptApproval e l’agente si ferma prima di eseguire qualsiasi script:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

Quando l’agente vuole eseguire uno script, restituisce una richiesta di approvazione. La vostra app raccoglie la decisione — approvare o rifiutare — e l’agente continua di conseguenza. Negli ambienti regolamentati, questa è la differenza tra “possiamo fare il deploy” e “l’ufficio legale dice no.”

Perché questa combinazione conta

Il vero potere non è in nessun pattern individuale — è nella composizione. Potete:

Iniziare in piccolo con una skill basata su file, iterare sulle istruzioni e pubblicarla senza scrivere C#
Distribuire skill riutilizzabili come pacchetti NuGet che altri team aggiungono con una riga
Colmare lacune con skill inline quando avete bisogno di qualcosa adesso
Filtrare directory condivise con predicati perché il vostro agente carichi solo quello che deve
Aggiungere supervisione umana per gli script che toccano sistemi di produzione

Tutto questo si compone tramite AgentSkillsProviderBuilder. Nessun routing speciale, nessuna logica condizionale, nessun controllo del tipo di skill.

Per concludere

Le agent skill in .NET ora hanno un modello di authoring genuinamente flessibile. Che siate uno sviluppatore solo che prototipa con skill basate su file o un team enterprise che distribuisce capacità impacchettate via NuGet, i pattern si adattano. E il meccanismo di approvazione degli script lo rende pronto per la produzione negli ambienti dove serve quel checkpoint umano.

Date un’occhiata all’annuncio originale, alla documentazione Agent Skills su Microsoft Learn e agli esempi .NET su GitHub per iniziare.

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.

Risposte in background nel Microsoft Agent Framework: basta ansia da timeout

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Se hai costruito qualcosa con modelli di ragionamento come o3 o GPT-5.2, conosci il dolore. Il tuo agente inizia a ragionare su un compito complesso, il client resta in attesa, e da qualche parte tra “va tutto bene” e “si sarà bloccato?” la tua connessione va in timeout. Tutto quel lavoro? Perso.

Microsoft Agent Framework ha appena rilasciato le risposte in background — e onestamente, questa è una di quelle funzionalità che avrebbero dovuto esistere dal primo giorno.

Il problema con le chiamate bloccanti

In un pattern tradizionale richiesta-risposta, il tuo client si blocca finché l’agente non finisce. Funziona bene per i compiti veloci. Ma quando chiedi a un modello di ragionamento di fare ricerca approfondita, analisi multi-step, o generare un report di 20 pagine? Stai guardando minuti di tempo reale. Durante quella finestra:

Le connessioni HTTP possono scadere
I problemi di rete uccidono l’intera operazione
Il tuo utente fissa uno spinner chiedendosi se sta succedendo qualcosa

Le risposte in background ribaltano tutto questo.

Come funzionano i token di continuazione

Invece di bloccare, lanci il compito dell’agente e ottieni un token di continuazione. Pensalo come un biglietto di ritiro in un’officina — non resti al bancone ad aspettare, torni quando è pronto.

Il flusso è diretto:

Invia la tua richiesta con AllowBackgroundResponses = true
Se l’agente supporta l’elaborazione in background, ricevi un token di continuazione
Interroga al tuo ritmo finché il token non torna null — significa che il risultato è pronto

Ecco la versione .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);

// Interrogare fino al completamento
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);

Se l’agente completa immediatamente (compiti semplici, modelli che non necessitano di elaborazione in background), nessun token viene restituito. Il tuo codice funziona e basta — nessuna gestione speciale necessaria.

Streaming con ripresa: la vera magia

Il polling va bene per scenari fire-and-forget, ma cosa succede quando vuoi il progresso in tempo reale? Le risposte in background supportano anche lo streaming con ripresa integrata.

Ogni aggiornamento dello stream porta il suo token di continuazione. Se la tua connessione cade a metà stream, riprendi esattamente da dove avevi lasciato:

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; // Simulare un'interruzione di rete
}

// Riprendere esattamente da dove avevamo lasciato
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

L’agente continua a elaborare lato server indipendentemente da cosa succede al tuo client. È tolleranza ai guasti integrata senza che tu scriva logica di retry o circuit breaker.

Quando usare questo concretamente

Non ogni chiamata all’agente ha bisogno di risposte in background. Per completamenti veloci, stai aggiungendo complessità senza motivo. Ma ecco dove brillano:

Compiti di ragionamento complesso — analisi multi-step, ricerca approfondita, qualsiasi cosa che faccia davvero pensare un modello di ragionamento
Generazione di contenuti lunghi — report dettagliati, documenti multi-parte, analisi estese
Reti poco affidabili — client mobili, deployment edge, VPN aziendali instabili
Pattern UX asincroni — invia un compito, vai a fare altro, torna per i risultati

Per noi sviluppatori .NET che costruiamo app enterprise, l’ultimo punto è particolarmente interessante. Pensa a un’app Blazor dove un utente richiede un report complesso — lanci il compito dell’agente, mostri un indicatore di progresso, e li lasci continuare a lavorare. Niente acrobazie WebSocket, niente infrastruttura di code personalizzata, solo un token e un loop di polling.

Per concludere

Le risposte in background sono disponibili ora sia in .NET che in Python attraverso Microsoft Agent Framework. Se stai costruendo agenti che fanno qualcosa di più complesso del semplice Q&A, vale la pena aggiungerlo al tuo toolkit. Il pattern del token di continuazione mantiene le cose semplici risolvendo un problema di produzione molto reale.

Consulta la documentazione completa per il riferimento completo dell’API e altri esempi.

Agent-Framework | The .NET Blog

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

Foundry Local è Generalmente Disponibile

GPT-5.5

Tracing di Agent Framework in Foundry

CodeAct con Hyperlight (Alpha)

Dashboard di Monitoraggio degli Agenti (Anteprima)

Evaluator Personalizzati per la Valutazione Continua (Anteprima)

Inventario degli Agenti nel Piano di Controllo

Il Pattern Handoff: Quando Un Agente Non Basta

Come Funziona Handoff

Un Esempio Minimale

Quando Usare Handoff (e Quando No)

Bordi Posteriori e Human-in-the-Loop

Conclusione

Workflow Durevoli in Microsoft Agent Framework: Da In-Memory ad Azure Functions

I Blocchi Fondamentali

Il Runner In-Memory per lo Sviluppo Locale

Aggiungere Durabilità con Durable Task

Hosting Azure Functions

Perché Questo È Importante

Il Tuo Agente MAF Locale Ha Appena Trovato Casa in Produzione

Cosa Fa Realmente Foundry Hosted Agents

La Differenza nel Codice È Minima

Due Protocolli, Un Agente

Il Flusso di Deployment con azd

Conclusione

Costruire Agenti È la Parte Facile — Eseguirli in Sicurezza È la Parte Difficile

Cosa Fa Davvero Ciascun Progetto

Integrarsi È Solo Aggiungere Middleware

Cosa Ottieni

Cinque Scenari di Settore

Conclusione

A2A v1 È Arrivato: Comunicazione tra Agenti Cross-Platform in Microsoft Agent Framework per .NET

Cosa è Realmente A2A v1

Connettersi a un Agente A2A Remoto

Esporre il Tuo Agente come Endpoint A2A

Cosa Significa Questo in Pratica

CodeAct in Agent Framework: Come Dimezzare la Latenza del tuo Agente

Cos’è CodeAct?

La componente di sicurezza: Micro-VM Hyperlight

Configurazione minima

Quando usare CodeAct (e quando no)

Provalo ora

Dove il tuo Agente Ricorda le Cose? Guida Pratica all'Archiviazione della Cronologia Chat

Due pattern fondamentali

Come Agent Framework astrae questo

Riferimento rapido ai provider

Come scegliere

GPT-5.5 È Arrivato su Azure Foundry — Cosa Devono Sapere i Sviluppatori .NET

La progressione di GPT-5

Cosa è cambiato davvero

Prezzi

Perché Foundry è importante

Le Agent Skills in .NET sono diventate davvero flessibili

Skill basate su file: il punto di partenza

Skill basate su classi: distribuire via NuGet

Skill inline: il ponte rapido

Approvazione degli script: umano nel loop

Perché questa combinazione conta

Per concludere

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

Perché questo è importante per gli sviluppatori .NET

La topologia di handoff è la vera star

Human-in-the-loop che funziona davvero

Collegare il tutto è sorprendentemente semplice

La mia opinione

Per concludere

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

La versione breve

Iniziare è quasi ingiustamente semplice

Orchestrazione multi-agente — questa è la cosa seria

Le funzionalità che contano di più

Le funzionalità in preview da tenere d’occhio

Migrazione da Semantic Kernel o AutoGen

Per concludere

Risposte in background nel Microsoft Agent Framework: basta ansia da timeout

Il problema con le chiamate bloccanti

Come funzionano i token di continuazione

Streaming con ripresa: la vera magia

Il Flusso di Deployment con `azd`