Azure Functions | The .NET Blog

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

Smetti di Martellare una Dipendenza in Difficoltà: Pattern di Retry per Azure Functions + Service Bus

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

Ecco come un guasto recuperabile diventa un’interruzione in un’applicazione Functions: una dipendenza inizia a generare timeout, ogni istanza Function riprova immediatamente e indefinitamente, la dipendenza viene martellata con centinaia di richieste fallite concorrenti, e quello che è iniziato come un piccolo problema transitorio diventa un evento di contropressione a livello di sistema.

Probabilmente conosci questa storia. Azure Functions scala velocemente — questo è tutto il punto. Ma “scalare velocemente” e “riprovare immediatamente” insieme possono peggiorare drammaticamente i guasti.

Due pattern aiutano. Exponential backoff e circuit breaker. Entrambi sono ora supportati nativamente per le Azure Functions attivate da Service Bus.

Due Pattern, Ruoli Diversi

Questi pattern sono complementari, non alternative:

L’exponential backoff risponde a: quando dovrei riprovare? Aumenta il ritardo tra i tentativi in modo che una dipendenza abbia il tempo di recuperare. A livello di messaggio, regolando il ritmo dei retry.

Il circuit breaker risponde a: dovrei chiamare questa dipendenza adesso? Interrompe le chiamate ripetute a una dipendenza non sana dopo che viene raggiunta una soglia di errore, poi sonda con cautela dopo un periodo di raffreddamento. A livello di sistema, prevenendo le tempeste di retry.

Li vuoi entrambi. Il backoff gestisce il ritmo dei retry per messaggio. Il circuit breaker gestisce le decisioni di salute aggregate.

Perché è Importante Specialmente per Service Bus

La coda assorbe il traffico a burst, il che è positivo. Ma senza controlli, la coda può crescere mentre i worker continuano a sprecare risorse di calcolo su chiamate che falliranno. I messaggi avvelenati rimangono attivi più a lungo di quanto dovrebbero. Le partizioni calde o la capacità downstream limitata creano problemi a cascata.

Il design più sicuro:

Rilevare il guasto transitorio
Ritardare il prossimo tentativo con exponential backoff
Interrompere le chiamate alla dipendenza quando viene raggiunta una soglia di guasto (circuito aperto)
Riprendere con cautela dopo un periodo di raffreddamento (sonda del circuito)
Spostare il lavoro irrecuperabile in dead-letter o in un percorso di quarantena

Come Appare il Supporto Nativo

Il nuovo supporto si integra con il modello di host Azure Functions esistente — nessuna libreria aggiuntiva, nessuna implementazione personalizzata. La configurazione va nel tuo host.json:

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

La configurazione del circuit breaker imposta la soglia di errore e l’intervallo di reset in modo che le dipendenze non sane non vengano bombardate durante il recupero.

Linguaggi Coperti

Questo non è solo per .NET. La funzionalità copre dotnet, JavaScript, TypeScript e Python — il set completo di linguaggi supportati dal trigger Service Bus in Azure Functions.

Conclusione

I pattern di retry non sono emozionanti da configurare fino alla prima volta che un’interruzione downstream fa sì che le tue Functions peggiorino il problema invece di degradarsi gradualmente. Configurarli in modo proattivo è economico. Adattarli durante un incidente non lo è.

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

Collega i tuoi server MCP su Azure Functions ai Foundry Agents — Ecco come

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

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

Ecco cosa adoro dell’ecosistema MCP: costruisci il tuo server una volta e funziona ovunque. VS Code, Visual Studio, Cursor, ChatGPT — ogni client MCP può scoprire e utilizzare i tuoi strumenti. Ora, Microsoft sta aggiungendo un altro consumatore a quella lista: gli agenti Foundry.

Lily Ma del team Azure SDK ha pubblicato una guida pratica su come collegare server MCP distribuiti su Azure Functions con gli agenti Microsoft Foundry. Se hai già un server MCP, questo è puro valore aggiunto — nessuna ricostruzione necessaria.

Perché questa combinazione ha senso

Azure Functions ti offre infrastruttura scalabile, autenticazione integrata e fatturazione serverless per ospitare server MCP. Microsoft Foundry ti dà agenti AI che possono ragionare, pianificare e agire. Collegare i due significa che i tuoi strumenti personalizzati — interrogare un database, chiamare un’API aziendale, eseguire logica di validazione — diventano capacità che gli agenti AI aziendali possono scoprire e utilizzare autonomamente.

Il punto chiave: il tuo server MCP resta lo stesso. Stai semplicemente aggiungendo Foundry come un altro consumatore. Gli stessi strumenti che funzionano nel tuo setup VS Code ora alimentano un agente AI con cui il tuo team o i clienti interagiscono.

Opzioni di autenticazione

È qui che il post offre davvero valore. Quattro metodi di autenticazione a seconda del tuo scenario:

Metodo	Caso d’uso
Basato su chiave (predefinito)	Sviluppo o server senza autenticazione Entra
Microsoft Entra	Produzione con identità gestite
Passthrough identità OAuth	Produzione dove ogni utente si autentica individualmente
Senza autenticazione	Dev/test o solo dati pubblici

Per la produzione, Microsoft Entra con identità dell’agente è il percorso consigliato. Il passthrough identità OAuth è per quando il contesto utente conta — l’agente chiede agli utenti di accedere, e ogni richiesta porta il token personale dell’utente.

Configurazione

Il flusso generale:

Distribuisci il tuo server MCP su Azure Functions — esempi disponibili per .NET, Python, TypeScript e Java
Abilita l’autenticazione MCP integrata sulla tua function app
Ottieni l’URL del tuo endpoint — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Aggiungi il server MCP come strumento in Foundry — naviga al tuo agente nel portale, aggiungi un nuovo strumento MCP, fornisci endpoint e credenziali

Poi testalo nel playground dell’Agent Builder inviando un prompt che attiverebbe uno dei tuoi strumenti.

La mia opinione

La storia della composabilità qui sta diventando davvero forte. Costruisci il tuo server MCP una volta in .NET (o Python, TypeScript, Java), distribuiscilo su Azure Functions, e ogni client compatibile con MCP può usarlo — strumenti di codifica, app di chat, e ora agenti AI aziendali. È un pattern “scrivi una volta, usa ovunque” che funziona davvero.

Per gli sviluppatori .NET nello specifico, l’estensione MCP di Azure Functions rende tutto semplice. Definisci i tuoi strumenti come Azure Functions, fai il deploy, e hai un server MCP di livello produzione con tutta la sicurezza e la scalabilità che Azure Functions offre.

Conclusione

Se hai strumenti MCP in esecuzione su Azure Functions, collegarli agli agenti Foundry è una vittoria rapida — i tuoi strumenti personalizzati diventano capacità AI aziendali con autenticazione adeguata e senza modifiche al codice del server.

Leggi la guida completa per istruzioni passo passo su ogni metodo di autenticazione, e consulta la documentazione dettagliata per configurazioni di produzione.

Le MCP Apps hanno una Fluent API — Crea interfacce ricche per strumenti AI in .NET in tre passaggi

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

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

Gli strumenti MCP sono fantastici per dare capacità agli agenti AI. Ma cosa succede se il tuo strumento deve mostrare qualcosa all’utente — una dashboard, un form, una visualizzazione interattiva? È qui che entrano in gioco le MCP Apps, e ora sono diventate molto più facili da costruire.

Lilian Kasem del team Azure SDK ha presentato la nuova API di configurazione fluent per le MCP Apps su Azure Functions .NET, ed è il tipo di miglioramento dell’esperienza sviluppatore che ti fa chiedere perché non fosse sempre così semplice.

Cosa sono le MCP Apps?

Le MCP Apps estendono il Model Context Protocol permettendo agli strumenti di portare le proprie viste UI, asset statici e controlli di sicurezza. Invece di restituire solo testo, il tuo strumento MCP può renderizzare esperienze HTML complete — dashboard interattive, visualizzazioni di dati, form di configurazione — tutto invocabile dagli agenti AI e presentato agli utenti dai client MCP.

Il problema era che collegare tutto manualmente richiedeva di conoscere la specifica MCP in profondità: URI ui://, tipi MIME speciali, coordinamento dei metadati tra strumenti e risorse. Non difficile, ma noioso.

La Fluent API in tre passaggi

Passaggio 1: Definisci la tua funzione. Uno strumento MCP standard di Azure Functions:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Passaggio 2: Promuovila a MCP App. Nello startup del tuo programma:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Passaggio 3: Aggiungi la tua vista HTML. Crea assets/hello-app.html con l’interfaccia di cui hai bisogno.

Tutto qui. La Fluent API gestisce tutta l’infrastruttura del protocollo MCP — genera la funzione risorsa sintetica, imposta il tipo MIME corretto e inietta i metadati che collegano il tuo strumento alla sua vista.

La superficie dell’API è ben progettata

Alcune cose che mi piacciono molto:

Le fonti delle viste sono flessibili. Puoi servire HTML da file su disco, o incorporare risorse direttamente nel tuo assembly per deployment autonomi:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

Il CSP è componibile. Autorizzi esplicitamente le origini di cui la tua app ha bisogno, seguendo i principi del minimo privilegio. Chiama WithCsp più volte e le origini si accumulano:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Controllo della visibilità. Puoi rendere uno strumento visibile solo al LLM, solo all’UI dell’host, o entrambi. Vuoi uno strumento che renderizza solo UI e non dovrebbe essere chiamato dal modello? Facile:

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

Per iniziare

Aggiungi il pacchetto preview:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

Se stai già costruendo strumenti MCP con Azure Functions, è solo un aggiornamento del pacchetto. Il quickstart MCP Apps è il miglior punto di partenza se sei nuovo al concetto.

Conclusione

Le MCP Apps sono uno degli sviluppi più entusiasmanti nello spazio degli strumenti AI — strumenti che non solo fanno cose ma possono mostrare cose agli utenti. La Fluent API rimuove la complessità del protocollo e ti permette di concentrarti su ciò che conta: la logica del tuo strumento e la sua interfaccia.

Leggi il post completo per il riferimento completo dell’API e gli esempi.