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

Foundry Local 1.1: Trascrizione in Tempo Reale, Embeddings e l'API di Risposta

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

Foundry Local 1.0 ha dimostrato il concetto: eseguire modelli di IA localmente su Windows, macOS (Apple Silicon) e Linux x64 con un SDK adatto agli sviluppatori. La versione 1.1 aggiunge tre funzionalità che coprono molti casi d’uso reali in produzione.

Trascrizione Audio in Diretta

La nuova funzionalità più significativa: streaming di riconoscimento vocale in tempo reale direttamente dal microfono. Sottotitoli, interfacce vocali, trascrizione di riunioni, strumenti di accessibilità — tutto eseguito localmente senza alcuna dipendenza dal cloud.

L’API è basata su sessioni e trasmette i risultati man mano che arrivano, con marcatori is_final per distinguere il testo intermedio da quello finalizzato. Disponibile per tutti i binding linguistici: JavaScript, C#, Python e Rust.

Carica un modello vocale in streaming dal catalogo, crea una sessione con le impostazioni audio (frequenza di campionamento, canali, lingua), avviala, invia blocchi audio PCM grezzi e consuma lo stream asincrono di risultati. Il post contiene esempi completi in Python e C#.

Embeddings di Testo

Ricerca semantica, pipeline RAG, clustering, corrispondenza di similarità — tutto questo richiede embeddings. Foundry Local 1.1 aggiunge il supporto per i modelli di embedding così da poter generare vettori localmente dallo stesso SDK, senza inviare dati a un endpoint cloud.

Per le applicazioni in cui la residenza dei dati è importante o dove si elabora contenuto sensibile, la generazione locale di embeddings è una capacità significativa.

API di Risposta

Foundry Local supporta ora la API di Risposta — l’interfaccia strutturata progettata per le interazioni agentiche. Questo aggiunge:

Chiamata agli strumenti — consente ai modelli in esecuzione locale di invocare strumenti che definisci tu
Input multimodale visione-linguaggio — passa immagine + testo a modelli capaci di visione
Compatibile con la forma API standard, quindi gli agenti esistenti che puntano all’API di Risposta di OpenAI funzionano contro modelli locali

Miglioramenti alle Dimensioni del Pacchetto

Due modifiche riducono la dimensione del pacchetto JavaScript:

Il layer FFI koffi è stato sostituito con un addon C Node-API personalizzato
Il provider di esecuzione WebGPU viene distribuito come plugin separato, così le applicazioni che non necessitano di accelerazione GPU non ne pagano il costo in termini di dimensioni

L’SDK C# ora punta a versioni di framework inferiori per una compatibilità .NET più ampia.

Perché È Importante

Le tre funzionalità insieme — trascrizione, embeddings, chiamata agli strumenti — coprono i blocchi di costruzione fondamentali di molte applicazioni di IA. Eseguirli localmente significa:

Nessun internet richiesto
Nessun costo per token
Nessun dato lascia la macchina
Latenza costante indipendentemente dalle condizioni di rete

Foundry Local è la scelta giusta per scenari edge, carichi di lavoro sensibili alla privacy, applicazioni offline, o qualsiasi cosa in cui si voglia evitare la dipendenza dal cloud durante lo sviluppo.

Post originale: Foundry Local 1.1: Live Transcription, Embeddings, and Responses API

Cosmos DB Shell È in Anteprima Pubblica — E Ha un Server MCP Integrato

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

Se hai mai dovuto saltare tra una scheda del portale, un esempio di SDK e uno script a metà completato solo per rispondere a una domanda su Cosmos DB, conosci già la frizione che questo progetto è progettato per eliminare.

Azure Cosmos DB Shell è appena entrato in anteprima pubblica. È una CLI open source con sintassi simile a bash e — la parte che lo rende interessante — un server MCP integrato.

Cosa lo Rende Diverso dalle Altre CLI di Database

La CLI in sé è utile: comandi familiari, supporto agli script, integrazione CI/CD. Quella parte è il minimo atteso per uno strumento di database orientato agli sviluppatori.

La parte interessante è l’integrazione del server MCP. Ogni comando che la CLI espone diventa disponibile come strumento MCP che i tuoi agenti IA possono chiamare. Non c’è nessuno strato API personalizzato, nessun codice di integrazione da scrivere. Il tuo agente può:

Navigare nelle gerarchie di database con cd, ls, pwd
Eseguire query SQL con query e ottenere risultati strutturati
Creare e modificare elementi con create item, update, rm
Gestire database e container con mkdb, mkcon, rmdb, rmcon
Ispezionare il contesto corrente con endpoint, pwd

Il cambiamento fondamentale: il tuo agente non sta parlando con un’API di Cosmos DB — sta parlando con la stessa interfaccia shell che usi tu. I comandi sono deterministici, verificabili e open source in modo da poter ispezionare esattamente cosa sta succedendo.

La Base Open Source È Importante

Questo non è un servizio gestito a scatola nera. La shell è open source, il che significa:

I team di sicurezza possono verificare l’implementazione
I team di piattaforma possono fare fork e estenderla per i loro standard specifici
Gli sviluppatori possono contribuire miglioramenti che beneficiano tutti

Per i team aziendali che adottano strumenti IA, “possiamo vedere esattamente come funziona” è sempre meno un requisito opzionale. L’open source qui è un differenziatore significativo.

Tre Scenari Che Diventano Più Semplici

Analisi intelligente dei dati — connetti un agente alla shell, fai domande in linguaggio naturale, ottieni risultati di query strutturati. L’agente gestisce la costruzione della query; la shell gestisce l’esecuzione.

Gestione autonoma dei dati — i workflow che devono creare, aggiornare o rimuovere dati in Cosmos DB possono farlo attraverso gli strumenti MCP senza necessitare un’integrazione personalizzata.

Monitoraggio e avvisi in tempo reale — un agente può interrogare periodicamente i container, confrontare i risultati e segnalare anomalie tramite qualsiasi canale di notifica abbia senso.

L’interfaccia MCP rende questi scenari componibili con qualsiasi piattaforma IA che parla MCP — non solo gli strumenti Microsoft.

Per Iniziare

La shell è in anteprima pubblica. Installala, configura la tua connessione Cosmos DB e abilita il server MCP. Da lì, qualsiasi host agente compatibile con MCP può scoprire e utilizzare gli strumenti.

Post originale: Announcing the Public Preview of Azure Cosmos DB Shell: Open-Source Power Meets AI-Driven Database Automation

Il Tuo Agente IA Ha un Problema di Identità (Ed Ecco il Template che lo Risolve)

Emiliano Montesdeoca — Wed, 20 May 2026 00:00:00 +0000

C’è un momento in ogni progetto di agente IA che va più o meno così: la demo funziona perfettamente, l’agente interpreta il linguaggio naturale, chiama le API giuste, restituisce i dati giusti. Poi inizi a pensare agli utenti reali.

Cosa impedisce alla sessione dell’agente di un utente di vedere i dati di un altro utente? E se l’agente viene ingannato tramite prompt injection? E se chiama uno strumento in modo inaspettato?

Questi non sono casi limite. Sono decisioni di design che devi prendere prima di rilasciare.

Un nuovo template azd di Curity e Microsoft ti fornisce un riferimento funzionante per esattamente questo problema.

Il Problema Principale: Autenticazione ≠ Autorizzazione

La maggior parte dei campioni di agenti gestisce bene l’autenticazione degli utenti. Gestisce male l’autorizzazione. Sapere chi è l’utente non ti dice quali dati dovrebbe vedere.

Un’applicazione client tradizionale fa chiamate API prevedibili. Un agente IA è non deterministico — interpreta il linguaggio naturale e decide cosa chiamare. Può essere creativo. Può anche sbagliare. E se viene manipolato tramite prompt injection, hai bisogno di regole che non dipendano dal buon comportamento dell’IA.

La soluzione dimostrata da questo template: token di breve durata che trasportano esattamente le informazioni giuste per ogni salto.

Come Funziona la Catena di Token

Il template usa token di accesso OAuth 2.0 con scambio di token per restringere i permessi a ogni passo. Un token utente viene scambiato due volte prima di raggiungere il server MCP:

Primo scambio — restringe lo scope e converte il token opaco in un JWT
Secondo scambio — aggiunge l’identità dell’agente e un nuovo audience per il salto del server MCP

Come appare il token del server MCP:

{
 "scope": "stocks/read",
 "sub": "62c839b8...",
 "aud": "https://mcp.demo.example",
 "customer_id": "178",
 "region": "USA"
}

Il customer_id è incorporato nel token dal server di autorizzazione, non passato come parametro che l’agente controlla. L’API controlla il token, non le istruzioni dell’agente.

Questo significa: anche se qualcuno inganna l’agente facendogli tentare di recuperare i dati di un altro cliente, il token non lo autorizzerà.

Cosa Distribuisce il Template

Con pochi comandi azd ottieni:

Un agente backend su Microsoft Foundry (C#, SDK Microsoft A2A e MCP)
Un server MCP che espone un’API di portafoglio di esempio
Curity Identity Server come server di autorizzazione, insieme a Entra ID per l’autenticazione
Gateway API esterni e interni che gestiscono lo scambio di token e il logging degli audit
Bicep per tutta l’infrastruttura Azure: Container Apps, VNet, ACR, Azure AI Foundry, Key Vault, Azure SQL Database, storage

L’intero pattern è ispezionabile e personalizzabile.

Il Principio di Design che Vale la Pena Adottare

Anche se non usi Curity, il pattern è trasferibile: gli agenti non dovrebbero mai avere accesso permanente all’API. Ogni azione dovrebbe usare un token di breve durata con il minimo scope necessario per quella specifica chiamata, emesso per la specifica identità dell’agente, con i claim di cui l’API ha bisogno per prendere decisioni di autorizzazione.

Questo regge contro agenti creativi, errori e prompt injection in modi che “assicurati solo che l’agente non faccia cose cattive” non farà mai.

Conclusione

I pattern di sicurezza per gli agenti IA sono ancora in fase di definizione in tutto il settore. Questo template è una delle implementazioni di riferimento più complete che ho visto — copre il flusso di autorizzazione reale, non solo l’autenticazione.

Post originale: Least privilege AI agents: A new azd template from Curity and Microsoft

Endpoint Privati, VNet, NSG — Aspire Gestisce la Rete Ora

Emiliano Montesdeoca — Tue, 19 May 2026 00:00:00 +0000

Ho visto questo scenario troppe volte. L’app è pronta. La demo è fantastica. Poi arriva la checklist di sicurezza: porta lo storage fuori da internet pubblico, esegui all’interno di un VNet, fornisci IP in uscita per l’allowlist del partner, dimostra che solo le subnet giuste parlano con i servizi giusti.

A quel punto il modello dell’applicazione e il modello dell’infrastruttura iniziano a divergere in modi che sono dolorosi da mantenere.

Il nuovo supporto per le reti aziendali Azure di Aspire affronta questo direttamente. Descrivi la forma della rete accanto alle risorse che la usano, nel tuo AppHost.

I Blocchi di Costruzione

Ecco a cosa serve ogni concetto di rete Azure, sintetizzato:

Funzionalità	Usala quando	Perché è importante
Rete virtuale	Hai bisogno di uno spazio di indirizzi privato	Il confine di rete per subnet, endpoint privati e routing
Subnet	Devi separare i carichi di lavoro all’interno del VNet	Ogni parte del sistema ottiene il proprio intervallo di indirizzi e superficie di policy
Subnet delegata	Un servizio di piattaforma (come ACA) deve gestire una subnet	Consente al servizio di posizionare infrastruttura gestita nel tuo VNet in modo sicuro
Gateway NAT	Hai bisogno di IP pubblici in uscita prevedibili	Indirizzo stabile per allowlist e auditing
Endpoint privato	Vuoi una risorsa PaaS raggiungibile privatamente	Inserisce un IP privato per quel servizio nel tuo VNet, rimuove l’esposizione pubblica
NSG	Hai bisogno di regole di traffico a livello di subnet	Permetti/nega esplicito per il traffico in entrata e in uscita per subnet

Descrivendolo nel tuo AppHost

Il cambiamento chiave qui è che stai modellando la rete insieme alle risorse che la usano, non in un file Bicep separato che si allontana dal modello dell’applicazione nel tempo.

Dall’AppHost puoi:

Creare VNet e subnet con AddVirtualNetwork() e AddSubnet()
Allegare un gateway NAT alle subnet per IP in uscita stabili
Creare endpoint privati per storage, Key Vault, SQL e altri servizi PaaS
Definire NSG con regole di sicurezza in entrata e in uscita
Configurare Perimetri di Sicurezza di Rete per policy tra risorse

Il risultato è che quando esegui azd up, l’infrastruttura corrisponde a ciò che il modello dell’applicazione dice di cui ha bisogno. Non quello che dice un template mantenuto manualmente.

Perché Questo è Importante per le Applicazioni Reali

Alcune cose che diventano significativamente più facili una volta che la rete è modellata in Aspire:

Endpoint privati per Key Vault e storage — descrivi WithPrivateEndpoint() su quelle risorse, e Aspire gestisce la configurazione delle zone DNS e l’allegato degli endpoint. L’app non cambia mai.

IP in uscita coerenti — aggiungi un gateway NAT alla subnet pertinente e ogni richiesta in uscita dalla tua app passa attraverso un IP noto e stabile. I partner possono aggiungerlo all’allowlist. I revisori possono tracciarlo.

Regole NSG dal codice — invece di cliccare nel portale o mantenere un frammento Bicep, le tue regole di sicurezza vivono nell’AppHost accanto alle risorse che proteggono.

Questo è il tipo di integrazione che non rende le demo eccitanti ma rende i sistemi di produzione manutenibili.

Conclusione

La sicurezza di rete che appare tardi nel ciclo di vita del progetto è un problema risolto se la modelli insieme all’app fin dall’inizio. Il supporto per le reti aziendali di Aspire rende ciò possibile senza richiedere una traccia di infrastruttura separata.

Dettagli completi nel post originale: Securing Azure apps with Aspire enterprise networking

Aspire 13.3: Supporto Kubernetes, Log del Browser e la Skill Aspireify

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

Cinque settimane non sono molto per un rilascio, ma Aspire 13.3 non sembra tale. Gli elementi principali sono significativi: deployment di Kubernetes e AKS di prima classe con Helm, una skill di onboarding assistita da agente chiamata Aspireify, cattura dei log del browser direttamente nel dashboard e risultati dei comandi strutturati. In più, 45 nuove funzionalità, 134 miglioramenti e 93 correzioni di bug.

Passiamo ai punti salienti.

Aspireify: Onboarding Assistito da Agente

Aggiungere Aspire a un progetto esistente sembra semplice — inserisci un AppHost, fatto. In pratica comporta molta archeologia: quali porte contano, quali variabili d’ambiente sono dipendenze reali, quali servizi Docker Compose devono corrispondere alle integrazioni Aspire.

La nuova skill Aspireify fornisce al tuo agente di codice un flusso di lavoro guidato esattamente per questo. Quando aspire init crea un AppHost scheletro, la skill Aspireify aiuta l’agente a ispezionare il repository, capire come funziona già e collegare l’AppHost per adattarsi all’app — non il contrario.

La postura predefinita è “minimizzare le modifiche al tuo codice.” Se la tua app legge già DATABASE_URL, l’agente lo mappa con WithEnvironment() invece di chiederti di riscrivere la tua configurazione. Se una porta è codificata in modo fisso, la skill indica all’agente quando preservarla.

Questo è il tipo di tooling IA che fa davvero risparmiare tempo invece di generare più lavoro da revisionare.

Deployment di Kubernetes e AKS di Prima Classe

Questo era nella lista dei desideri da un po’. Aspire 13.3 include il supporto di deployment di Kubernetes e AKS di prima classe con Helm. Ora puoi puntare ad AKS come destinazione di deployment direttamente dagli strumenti Aspire.

Per i team che già eseguono carichi di lavoro di produzione su AKS, questo colma una lacuna significativa. Il tuo modello di applicazione Aspire ora ha un percorso pulito dallo sviluppo locale a Kubernetes senza la necessità di scrivere manualmente chart Helm.

Log del Browser nel Dashboard

Questa è una di quelle funzionalità che sembrano piccole finché non stai facendo debug di un problema frontend.

La nuova API WithBrowserLogs() collega una risorsa browser tracciata a qualsiasi risorsa capace di endpoint. Aspire lancia Chromium usando un pipe CDP privato e trasmette log della console, richieste di rete ed errori direttamente nel flusso di log della risorsa:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

L’AppHost TypeScript supporta lo stesso:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

Errori della console, richieste di rete fallite, eccezioni lato client — tutto visibile nello stesso dashboard dove stai già guardando trace e metriche. Nessun cambio di tab verso le DevTools del browser per le cose di base.

Risultati dei Comandi Strutturati

I comandi delle risorse hanno ricevuto un aggiornamento significativo. Fino ad ora, i comandi restituivano successo/fallimento. Ora restituiscono risultati strutturati: testo, JSON o markdown che fluisce attraverso il modello, l’interfaccia del dashboard, la CLI e gli strumenti MCP.

Il dashboard lega tutto questo con un nuovo centro notifiche nell’intestazione. I risultati dei comandi appaiono come notifiche con timestamp con rendering markdown e un’azione “Visualizza risposta”.

Questo rende i comandi delle risorse veramente componibili. Un’integrazione ora può esporre un comando che restituisce un output significativo — come un URL di tunnel — invece di cambiare semplicemente lo stato da qualche parte.

Conclusione

Aspire 13.3 vale l’aggiornamento anche solo per il supporto Kubernetes. I log del browser e i risultati dei comandi strutturati sembrano il tipo di miglioramenti della qualità della vita che si accumulano rapidamente in un flusso di lavoro di sviluppo quotidiano.

Note di rilascio complete: What’s New in Aspire 13.3

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 si svolge dall’11 al 15 maggio 2026 al Barbican Centre di Londra. La conferenza principale di 3 giorni va da martedì a giovedì, con workshop opzionali di un’intera giornata il lunedì e il venerdì.

Con 78 sessioni e 14 workshop, è una delle conferenze per sviluppatori più ricche d’Europa.

Argomenti

Pensiero Architetturale
Codice Funzionale in C# 13
Design Serverless
IA Semantica
Azure Kubernetes Services
Strategie Lean DevOps
The Model Context Protocol (MCP)
IA Agentica in .NET
Refactoring del Monolite
Programmare Più Velocemente con gli LLM
Crittografia in un Mondo Post-Quantistico
Sviluppo Local First

Speaker

Lineup di classe mondiale che include Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm e Raju Gandhi.

Biglietti e informazioni

Il 98% dei partecipanti di SDD 2025 ha valutato l’esperienza complessiva come buona, molto buona o eccellente.

Eliminare il Lavoro Ripetitivo della Migrazione con l'Agentic Platform Engineering

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

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

Removing the Monkey Work of Migration with Agentic Platform Engineering — una guida passo per passo di Git-Ape (strumento git di ingegneria di piattaforma agentiva) che migra un vero repository Terraform AWS verso Azure, concentrandosi sull’estrazione dell’intenzione piuttosto che sulla conversione riga per riga.

L’input: contoso-migration

La fonte è un vero progetto Terraform (contoso-migration) che distribuisce un’app Next.js su AWS — EC2 per il computing, ALB per il bilanciamento del carico, S3 per gli artefatti e chiavi IAM per l’identità. Costo: ~34 $/mese. L’obiettivo non è riprodurre la stessa infrastruttura su Azure; è capire cosa il deployment sta effettivamente cercando di fare e ricostruirlo con servizi nativi Azure.

Passo 1: Validazione e autenticazione

Git-Ape inizia validando tutti gli strumenti CLI richiesti — az, aws, gh, jq, git — e confermando le sessioni di autenticazione attive prima di toccare qualsiasi cosa. Nessuna esecuzione parziale.

Passo 2: Estrazione dell’intenzione

L’agente legge l’intero repository sorgente tramite l’API GitHub ed estrae l’intenzione del deployment: runtime (Node.js), tipo di computing, modello di ingress, gestione degli artefatti, modello di identità, rete e monitoraggio. Questo è il passaggio chiave — sta costruendo un modello semantico di cosa fa il deployment, non quali parole chiave Terraform usa.

Passo 3: Mappatura dei servizi

I servizi AWS vengono mappati agli equivalenti Azure:

EC2 → App Service (Linux, Node 20 LTS)
ALB → Bilanciamento del carico integrato di App Service
Ruoli/chiavi IAM → Managed Identity
Terraform → Bicep + GitHub Actions

Passo 4: Agente critico

Prima di generare l’output, viene eseguito un agente critico che individua due problemi bloccanti:

Anti-pattern di build all’avvio — il Terraform originale eseguiva npm install && npm run build su EC2 all’avvio. Fix: costruire in CI, distribuire un artefatto pronto.
Blob Storage non necessario — S3 veniva usato per lo staging degli artefatti che poteva essere eliminato con un CI/CD appropriato. L’agente critico lo ha rimosso completamente.

Passo 5: Output generato

Il risultato è ~80 righe di Bicep invece delle 200+ righe originali di Terraform. L’agente ha creato un nuovo repository GitHub con infra/main.bicep e .github/workflows/deploy.yml e rimosso tutti i file specifici di AWS.

Confronto della postura di sicurezza

La migrazione ha anche prodotto un significativo miglioramento della sicurezza:

AWS originale	Output Azure
Solo HTTP	Solo HTTPS, TLS 1.2
SSH aperto a 0.0.0.0/0	Nessuna esposizione SSH
Chiavi di accesso IAM	OIDC + Managed Identity
Nessun monitoraggio	Application Insights

Costo: ~13 $/mese vs i 34 $/mese originali.

Cosa lo differenzia da un convertitore di sintassi

Il passaggio dell’agente critico è ciò che separa questo da una traduzione meccanica. Ha individuato pattern che avrebbero funzionato su AWS ma sarebbero stati sbagliati su Azure — e li ha corretti invece di replicarli. L’output non è “AWS in sintassi Azure”; è un deployment nativo Azure che raggiunge lo stesso obiettivo in modo più pulito.

Vedi la guida completa per la traccia completa dell’agente e i file generati.

SQL MCP Server su Azure App Service — Senza Container

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

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

Diciamoci la verità: ogni volta che vedo “richiede un container” in un tutorial, una piccola parte di me sospira. I container sono fantastici — finché il tuo team non ha una strategia per i container, e improvvisamente una funzionalità che sembrava semplice è bloccata da complessità di orchestrazione che nessuno aveva pianificato.

Ecco perché questo mi ha colpito. Il SQL MCP Server ora può girare su Azure App Service — senza Docker, senza Kubernetes, solo con la stessa configurazione di Data API Builder (DAB) che espone il tuo database SQL tramite MCP, REST e GraphQL.

Cos’è il SQL MCP Server?

Contesto rapido se non lo conosci ancora. Il SQL MCP Server si trova tra il tuo agente AI e il tuo database SQL. Invece di dare all’agente accesso diretto al database (un’idea pessima), espone le tue tabelle e view come uno strato di astrazione — entità con permessi definiti.

È costruito su Data API Builder, il che significa che un singolo file di configurazione gestisce MCP e REST e GraphQL contemporaneamente. Il tuo agente parla con l’endpoint MCP. La tua applicazione tradizionale parla con REST o GraphQL. Stessa config, stesso runtime, superfici diverse.

Questo è genuinamente utile. Non stai mantenendo due strati API separati.

Il Problema del Container (e la Soluzione)

Il modello di deployment originale del SQL MCP Server usava i container. Funziona bene in molti team — ma non in tutti. Molti team .NET standardizzano su Azure App Service o VM. Richiedere un runtime di container solo per esporre un endpoint SQL aggiunge attrito che nessuno ha chiesto.

Il nuovo walkthrough mostra come saltare completamente il container. Tutto funziona con un comando dab start, ospitato su App Service come un processo web .NET 8 standard.

# Installare Data API Builder
dotnet tool install microsoft.dataapibuilder --prerelease -g

# Inizializzare la configurazione
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Aggiungere un'entità
dab add products --source dbo.products --permissions "authenticated:*"

# Configurare il provider di autenticazione App Service
dab configure --runtime.host.authentication.provider AppService

# Avviare il server
dab start

A questo punto hai MCP su /mcp, REST e GraphQL dallo stesso processo, e niente che gira in un container.

Autenticazione Senza Chiavi API Condivise

Questa è la parte che apprezzo di più. Quando fai il deploy su App Service, configuri Microsoft Entra ID come provider di autenticazione. Nessun segreto condiviso nei file di configurazione, nessuna chiave API da ruotare.

La stringa di connessione rimane in una variabile d’ambiente di App Service (non in dab-config.json), e l’endpoint MCP è protetto dall’autenticazione della piattaforma. Se sei già allineato con Entra ID nei tuoi workload Azure, questo si integra naturalmente.

Per lo sviluppo locale, passi alla modalità Simulator e al trasporto STDIO. Torni alla modalità AppService prima del deployment. Pulito ed esplicito.

Deploy su App Service

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

Poi fai il deploy del tuo progetto DAB usando il metodo di deployment del codice che il tuo team già utilizza. Il dettaglio chiave: è un deployment di codice, non di container.

Perché Importa per gli Sviluppatori .NET

Se stai costruendo agenti AI in .NET, prima o poi il tuo agente dovrà comunicare con un database. Il SQL MCP Server ti dà un modo strutturato per farlo senza esporre stringhe di connessione grezze.

Consulta il tutorial completo nel post originale e il repository di esempio su GitHub.

Conclusione

Il SQL MCP Server su App Service è una solida opzione pragmatica per i team .NET che vogliono dare ai propri agenti accesso strutturato ai dati SQL senza una strategia di container. Provalo — i tuoi agenti apprezzeranno la superficie API pulita.

Azure MCP Server Ora è un .mcpb — Installalo senza Nessun Runtime

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

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

Sai cosa era fastidioso nella configurazione dei server MCP? Avevi bisogno di un runtime. Node.js per la versione npm, Python per pip/uvx, .NET SDK per la variante dotnet.

L’Azure MCP Server ha appena cambiato questo. È ora disponibile come .mcpb — un MCP Bundle — e la configurazione è drag-and-drop.

Cos’è un MCP Bundle?

Pensaci come a un’estensione VS Code (.vsix) o un’estensione browser (.crx), ma per i server MCP. Un file .mcpb è un archivio ZIP autonomo che include il binario del server e tutte le sue dipendenze.

Come installarlo

1. Scarica il bundle per la tua piattaforma

Vai alla pagina GitHub Releases e scarica il file .mcpb per il tuo OS e architettura.

2. Installa in Claude Desktop

Il modo più semplice: trascina il file .mcpb nella finestra di Claude Desktop sulla pagina delle impostazioni Estensioni (☰ → File → Impostazioni → Estensioni). Rivedi i dettagli del server, clicca su Installa, conferma.

3. Autenticati su Azure

az login

Fatto. Azure MCP Server usa le tue credenziali Azure esistenti.

Cosa puoi fare

Oltre 100 strumenti di servizi Azure direttamente dal tuo client AI:

Interrogare e gestire Cosmos DB, Storage, Key Vault, App Service, Foundry
Generare comandi az CLI per qualsiasi attività
Creare template Bicep e Terraform

Per iniziare

Download: GitHub Releases
Repository: aka.ms/azmcp
Docs: aka.ms/azmcp/docs

Consulta il post completo.

Azure SDK Aprile 2026: AI Foundry 2.0 e Cosa Devono Sapere gli Sviluppatori .NET

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

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

Le versioni mensili dell’SDK sono spesso facili da ignorare. Questa ha alcune cose degne di attenzione — specialmente se stai costruendo con AI Foundry, Cosmos DB in Java, o fai provisioning di infrastruttura da codice .NET.

Azure.AI.Projects 2.0.0 — Breaking Change che Hanno Senso

Split di namespace, tipi rinominati, e convenzione Is* coerente per i booleani.

Cosmos DB Java: Correzione Critica di Sicurezza (RCE)

La versione 4.79.0 corregge una vulnerabilità di Remote Code Execution (CWE-502). Aggiorna immediatamente.

Nuove Librerie di Provisioning per .NET

Post originale: Azure SDK Release (April 2026).

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.

Foundry Toolboxes: Un unico endpoint per tutti i tool degli agenti

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

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

C’è un problema che sembra noioso finché non lo si vive in prima persona: l’organizzazione sta costruendo più agenti IA, ognuno ha bisogno di tool, e ogni team li riconfigura da zero. La stessa integrazione di ricerca web, la stessa config di Azure AI Search, la stessa connessione al server MCP di GitHub — ma in un altro repository, da un altro team, con altre credenziali e senza governance condivisa.

Microsoft Foundry ha appena lanciato Toolboxes in public preview, ed è una risposta diretta a questo problema.

Cos’è una Toolbox?

Una Toolbox è un bundle di tool con nome, riutilizzabile, che si definisce una volta in Foundry e si espone tramite un unico endpoint compatibile MCP. Qualsiasi runtime di agente che parla MCP può consumarlo — nessun lock-in con Foundry Agents.

La promessa è semplice: build once, consume anywhere. Definisci i tool, configura l’autenticazione centralmente (OAuth passthrough, identità gestita di Entra), pubblica l’endpoint. Ogni agente che ha bisogno di quei tool si connette all’endpoint e li ottiene tutti.

I quattro pilastri (due disponibili oggi)

Pilastro	Stato	Cosa fa
Discover	In arrivo	Trova tool approvati senza ricerca manuale
Build	Disponibile	Raggruppa tool in un bundle riutilizzabile
Consume	Disponibile	Un endpoint MCP unico espone tutti i tool
Govern	In arrivo	Auth centralizzata + observability per tutte le chiamate

Esempio pratico

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Cerca documentazione e rispondi alle issue di GitHub.",
 tools=[
 {"type": "web_search", "description": "Cerca documentazione pubblica"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Una volta pubblicato, Foundry fornisce un endpoint unificato. Una connessione, tutti i tool.

Nessun lock-in con Foundry Agents

Le Toolbox vengono create e gestite in Foundry, ma la superficie di consumo è il protocollo MCP aperto. Si possono usare da agenti personalizzati (Microsoft Agent Framework, LangGraph), GitHub Copilot e altri IDE compatibili MCP.

Perché è importante adesso

L’ondata multi-agente sta arrivando in produzione. Ogni nuovo agente è una nuova superficie per configurazione duplicata, credenziali scadute e comportamento inconsistente. La base Build + Consume è sufficiente per iniziare a centralizzare. Quando arriverà il pilastro Govern, si avrà uno strato di tool completamente osservabile e controllato centralmente per tutta la flotta di agenti.

Conclusione

È ancora presto — public preview, SDK Python prima, con Discover e Govern ancora in arrivo. Ma il modello è solido e il design nativo MCP significa che funziona con i tool che si stanno già costruendo. Dai un’occhiata all’annuncio ufficiale per iniziare.

azd + GitHub Copilot: Configurazione del progetto con IA e risoluzione intelligente degli errori

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

Conosci quel momento in cui vuoi fare il deploy di un’app esistente su Azure e ti ritrovi a fissare un azure.yaml vuoto, cercando di ricordare se la tua API Express dovrebbe usare Container Apps o App Service? Quel momento è appena diventato molto più breve.

L’Azure Developer CLI (azd) si integra ora con GitHub Copilot in due modi concreti: scaffolding assistito dall’IA durante azd init, e risoluzione intelligente degli errori quando i deployment falliscono. Entrambe le funzionalità rimangono completamente nel terminale — esattamente dove voglio che siano.

Configurazione con Copilot durante azd init

Quando esegui azd init, ora compare l’opzione “Set up with GitHub Copilot (Preview)”. Selezionala e Copilot analizza la tua codebase per generare azure.yaml, i template di infrastruttura e i moduli Bicep — basandosi sul tuo codice reale.

azd init
# Seleziona: "Set up with GitHub Copilot (Preview)"

Prerequisiti:

azd 1.23.11 o superiore — verifica con azd version o aggiorna con azd update
Abbonamento attivo a GitHub Copilot (Individual, Business o Enterprise)
GitHub CLI (gh) — azd chiederà il login se necessario

Quello che trovo genuinamente utile: funziona in entrambi i sensi. Stai costruendo da zero? Copilot ti aiuta a configurare i servizi Azure giusti sin dall’inizio. Hai un’app esistente che volevi deployare da tempo? Punta Copilot su di essa e genera la configurazione senza che tu debba ristrutturare nulla.

Cosa fa davvero

Diciamo che hai un’API Express Node.js con dipendenza da PostgreSQL. Invece di decidere manualmente tra Container Apps e App Service, e poi scrivere Bicep da zero, Copilot rileva il tuo stack e genera:

Un azure.yaml con le impostazioni corrette di language, host e build
Un modulo Bicep per Azure Container Apps
Un modulo Bicep per Azure Database for PostgreSQL

E prima di toccare qualsiasi cosa esegue verifiche preventive — controlla che la tua directory git sia pulita, chiede il consenso per gli strumenti del server MCP. Niente accade senza che tu sappia esattamente cosa sta per cambiare.

Risoluzione degli errori con Copilot

Gli errori di deployment sono inevitabili. Parametri mancanti, problemi di permessi, disponibilità degli SKU — e il messaggio d’errore raramente ti dice l’unica cosa che hai davvero bisogno di sapere: come risolverlo.

Senza Copilot, il ciclo è: copiare l’errore → cercare nella documentazione → leggere tre risposte irrilevanti su Stack Overflow → eseguire alcuni comandi az CLI → riprovare sperando. Con Copilot integrato in azd, questo ciclo collassa. Quando qualsiasi comando azd fallisce, offre immediatamente quattro opzioni:

Explain — spiegazione in linguaggio naturale di cosa è andato storto
Guidance — istruzioni passo dopo passo per correggere il problema
Diagnose and Guide — analisi completa + Copilot applica la correzione (con la tua approvazione) + retry opzionale
Skip — gestire da soli

Il punto cruciale: Copilot ha già il contesto del tuo progetto, il comando che ha fallito e l’output dell’errore. I suoi suggerimenti sono specifici per la tua situazione, non documentazione generica.

Configurare il comportamento predefinito

Se scegli sempre la stessa opzione, salta il prompt interattivo:

azd config set copilot.errorHandling.category troubleshoot

Valori: explain, guidance, troubleshoot, fix, skip. Puoi anche abilitare auto-fix e retry:

azd config set copilot.errorHandling.fix allow

Ritorno alla modalità interattiva in qualsiasi momento:

azd config unset copilot.errorHandling.category

Conclusione

Questo è esattamente il tipo di integrazione di Copilot che porta valore reale. Provalo eseguendo azd update per ottenere l’ultima versione e usa azd init nel tuo prossimo progetto.

Leggi l’annuncio originale qui.

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 si tiene il 18 aprile 2026 al Kinépolis Diversia ad Alcobendas, Madrid. È il più grande evento comunitario Azure in Spagna, con 38 speaker su 3 track paralleli dedicati ad agenti IA, networking Azure, Cosmos DB, Fabric, IoT, sicurezza e molto altro.

L’evento si svolge dalle 08:30 alle 18:30 e include keynote, pause caffè, pranzo e una sessione di chiusura Q&A.

Punti salienti dell’agenda

Domando Agentes de IA: governance, strumenti e API con Azure AI Foundry e Azure API Management
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: sistemi multi-agente in azione
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Biglietti

L’iscrizione prevede una donazione simbolica — l’intero prezzo del biglietto va direttamente a Plan International, a sostegno dei diritti dei bambini e dell’uguaglianza nel mondo. Posti limitati, prenota il tuo posto in anticipo.

Azure Tour 2026

Oltre a Madrid, il Global Azure Tour 2026 prevede tappe anche a Saragozza, Tenerife e Siviglia.

I tuoi esperimenti IA su Azure stanno bruciando soldi — Ecco come risolvere

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

Se stai costruendo app basate sull’IA su Azure in questo momento, probabilmente hai notato qualcosa: la tua bolletta cloud è diversa rispetto a prima. Non solo più alta — più strana. A picchi. Difficile da prevedere.

Microsoft ha appena pubblicato un ottimo articolo sui principi di ottimizzazione dei costi cloud che contano ancora, e onestamente, il tempismo non potrebbe essere migliore. Perché i carichi di lavoro IA hanno cambiato le regole del gioco per quanto riguarda i costi.

Perché i carichi di lavoro IA colpiscono diversamente

Ecco il punto. I carichi di lavoro .NET tradizionali sono relativamente prevedibili. Conosci il tuo tier App Service, conosci i tuoi DTU SQL, puoi stimare la spesa mensile abbastanza precisamente. Carichi di lavoro IA? Non proprio.

Stai testando più modelli per vedere quale si adatta. Stai avviando infrastruttura con GPU per il fine-tuning. Stai facendo chiamate API ad Azure OpenAI dove il consumo di token varia enormemente in base alla lunghezza del prompt e al comportamento degli utenti. Ogni esperimento costa soldi veri, e potresti farne decine prima di trovare l’approccio giusto.

Questa imprevedibilità è ciò che rende l’ottimizzazione dei costi critica — non come un ripensamento, ma dal primo giorno.

Gestione vs. ottimizzazione — conosci la differenza

Una distinzione dell’articolo che secondo me gli sviluppatori trascurano: c’è una differenza tra gestione dei costi e ottimizzazione dei costi.

La gestione è tracciamento e reporting. Imposti budget in Azure Cost Management, ricevi avvisi, vedi dashboard. Questo è il minimo indispensabile.

L’ottimizzazione è dove prendi effettivamente le decisioni. Hai davvero bisogno di quel tier S3, o l’S1 gestirebbe il tuo carico? Quell’istanza di compute sempre attiva sta ferma nei weekend? Potresti usare istanze spot per i tuoi job di addestramento?

Come sviluppatori .NET, tendiamo a concentrarci sul codice e lasciare le decisioni sull’infrastruttura al “team ops”. Ma se stai facendo deploy su Azure, quelle decisioni sono anche le tue.

Cosa funziona davvero

Basandomi sull’articolo e sulla mia esperienza personale, ecco cosa fa la differenza:

Sappi cosa stai spendendo e dove. Tagga le tue risorse. Sul serio. Se non riesci a capire quale progetto o esperimento sta mangiando il tuo budget, non puoi ottimizzare nulla. Azure Cost Management con un tagging appropriato è il tuo migliore amico.

Metti dei guardrail prima di sperimentare. Usa Azure Policy per limitare SKU costosi negli ambienti dev/test. Imposta limiti di spesa sui tuoi deployment Azure OpenAI. Non aspettare che arrivi la bolletta per scoprire che qualcuno ha lasciato un cluster GPU acceso tutto il weekend.

Ridimensiona continuamente. Quella VM che hai scelto durante il prototipo? Probabilmente è sbagliata per la produzione. Azure Advisor ti dà raccomandazioni — guardale davvero. Rivedi mensilmente, non annualmente.

Pensa al ciclo di vita. Le risorse di sviluppo dovrebbero spegnersi. Gli ambienti di test non devono girare 24/7. Usa policy di spegnimento automatico. Per i carichi di lavoro IA nello specifico, considera opzioni serverless dove paghi per esecuzione invece di mantenere il compute attivo.

Misura il valore, non solo il costo. Questa è facile da dimenticare. Un modello che costa di più ma fornisce risultati significativamente migliori potrebbe essere la scelta giusta. L’obiettivo non è spendere il meno possibile — è spendere in modo intelligente.

Il punto chiave

L’ottimizzazione dei costi cloud non è una pulizia una tantum. È un’abitudine. E con i carichi di lavoro IA che rendono la spesa meno prevedibile che mai, costruire questa abitudine presto ti risparmia sorprese dolorose in futuro.

Se sei uno sviluppatore .NET che costruisce su Azure, inizia a trattare la tua bolletta cloud come tratti il tuo codice — rivedila regolarmente, fai refactoring quando diventa disordinata, e non fare mai deploy senza capire quanto ti costerà.

L'RFT di Foundry è ora più economico e intelligente — Ecco cosa è cambiato

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

Se state sviluppando app .NET che si basano su modelli fine-tunati, gli aggiornamenti Foundry di questo mese meritano la vostra attenzione. Il Reinforcement Fine-Tuning è diventato più accessibile e significativamente più economico.

I dettagli completi sono nell’annuncio ufficiale, ma ecco il riassunto pratico.

Addestramento Globale per o4-mini

o4-mini è il modello di riferimento per workload pesanti in ragionamento e agentici. La grande notizia: ora potete lanciare job di fine-tuning da più di 13 regioni Azure con tariffe di addestramento per token più basse rispetto all’addestramento Standard. Stessa infrastruttura, stessa qualità, maggiore copertura.

Se il vostro team è distribuito geograficamente, questo conta. Non siete più vincolati a un pugno di regioni per addestrare.

Ecco la chiamata API REST per avviare un job di addestramento globale:

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

Quel flag trainingType: globalstandard è la differenza chiave.

Nuovi Valutatori di Modello: Famiglia GPT-4.1

I valutatori definiscono il segnale di ricompensa contro cui il vostro modello ottimizza. Finora, i valutatori basati su modello erano limitati a un insieme più ristretto di modelli. Ora avete tre nuove opzioni: GPT-4.1, GPT-4.1-mini e GPT-4.1-nano.

Quando dovreste usare valutatori di modello invece di quelli deterministici? Quando l’output del vostro task è aperto, quando avete bisogno di punteggio parziale su più dimensioni, o quando state costruendo workflow agentici dove la correttezza delle chiamate agli strumenti dipende dal contesto semantico.

Il punto è che la strategia a livelli è pratica:

GPT-4.1-nano per le iterazioni iniziali. Basso costo, cicli di feedback rapidi.
GPT-4.1-mini una volta che la vostra rubrica di valutazione è stabile e avete bisogno di maggiore fedeltà.
GPT-4.1 per la valutazione in produzione o rubriche complesse dove ogni decisione di punteggio conta.

Potete persino mescolare tipi di valutatori in un singolo job RFT. Usate string-match per la dimensione “risposta corretta” e un valutatore di modello per valutare la qualità del ragionamento. Questa flessibilità è onestamente ciò che lo rende utile per workload reali.

La Trappola del Formato Dati RFT

Questo fa inciampare molti. Il formato dati RFT è diverso da SFT. L’ultimo messaggio in ogni riga deve avere il ruolo User o Developer — non Assistant. La risposta attesa va in una chiave di livello superiore come reference_answer che il valutatore referenzia direttamente.

Se stavate facendo supervised fine-tuning e volete passare a RFT, dovete ristrutturare i vostri dati di addestramento. Non saltate questo passaggio o i vostri job falliranno silenziosamente.

Perché Questo È Importante per gli Sviluppatori .NET

Se state chiamando modelli fine-tunati dalle vostre app .NET tramite l’SDK Azure OpenAI, un addestramento più economico significa che potete iterare in modo più aggressivo. Le opzioni dei valutatori di modello significano che potete fare fine-tuning per task sfumati — non solo scenari di corrispondenza esatta. E la guida alle best practice su GitHub vi farà risparmiare tempo reale di debugging.

Iniziate in piccolo. Da dieci a cento campioni. Valutatore semplice. Validate il ciclo. Poi scalate.

Gli strumenti Azure MCP sono ora integrati in Visual Studio 2022 — Nessuna estensione necessaria

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

Se hai usato gli strumenti Azure MCP in Visual Studio tramite l’estensione separata, conosci il rituale — installare il VSIX, riavviare, sperare che non si rompa nulla, gestire le incompatibilità di versione. Quella frizione è finita.

Yun Jung Choi ha annunciato che gli strumenti Azure MCP vengono ora distribuiti direttamente come parte del carico di lavoro di sviluppo Azure in Visual Studio 2022. Nessuna estensione. Nessun VSIX. Nessun balletto del riavvio.

Cosa significa concretamente

A partire da Visual Studio 2022 versione 17.14.30, il Azure MCP Server è incluso nel carico di lavoro di sviluppo Azure. Se hai già quel carico di lavoro installato, basta attivarlo in GitHub Copilot Chat e sei a posto.

Oltre 230 strumenti per 45 servizi Azure — accessibili direttamente dalla finestra di chat. Elenca i tuoi account di archiviazione, fai il deploy di un’app ASP.NET Core, diagnostica problemi di App Service, interroga Log Analytics — tutto senza aprire una scheda del browser.

Perché questo conta più di quanto sembri

Il punto sugli strumenti per sviluppatori è questo: ogni passaggio in più è frizione, e la frizione uccide l’adozione. Avere MCP come estensione separata significava incompatibilità di versione, errori di installazione e un’altra cosa da tenere aggiornata. Integrarlo nel carico di lavoro significa:

Un unico percorso di aggiornamento tramite il Visual Studio Installer
Nessuna divergenza di versione tra l’estensione e l’IDE
Sempre aggiornato — il MCP Server si aggiorna con i rilasci regolari di VS

Per i team che standardizzano su Azure, questo è un grande vantaggio. Installi il carico di lavoro una volta, attivi gli strumenti, e sono disponibili per ogni sessione.

Cosa puoi farci

Gli strumenti coprono l’intero ciclo di vita dello sviluppo tramite Copilot Chat:

Imparare — chiedi informazioni sui servizi Azure, best practice, pattern architetturali
Progettare e sviluppare — ottieni raccomandazioni sui servizi, configura il codice dell’applicazione
Fare deploy — provisiona risorse e fai il deploy direttamente dall’IDE
Risolvere problemi — interroga i log, verifica lo stato delle risorse, diagnostica problemi in produzione

Un esempio rapido — scrivi questo in Copilot Chat:

List my storage accounts in my current subscription.

Copilot chiama gli strumenti Azure MCP dietro le quinte, interroga le tue sottoscrizioni e restituisce una lista formattata con nomi, posizioni e SKU. Niente portale necessario.

Come attivarlo

Aggiorna a Visual Studio 2022 17.14.30 o superiore
Assicurati che il carico di lavoro Azure development sia installato
Apri GitHub Copilot Chat
Clicca sul pulsante Select tools (l’icona delle due chiavi)
Attiva Azure MCP Server

Tutto qui. Rimane attivato tra le sessioni.

Un’avvertenza

Gli strumenti sono disattivati per default — devi attivarli manualmente. E gli strumenti specifici per VS 2026 non sono disponibili in VS 2022. La disponibilità degli strumenti dipende anche dai permessi della tua sottoscrizione Azure, come nel portale.

Il quadro generale

Questo fa parte di una tendenza chiara: MCP sta diventando lo standard per esporre gli strumenti cloud negli IDE di sviluppo. Abbiamo già visto il rilascio stabile di Azure MCP Server 2.0 e integrazioni MCP in VS Code e altri editor. Averlo integrato nel sistema dei carichi di lavoro di Visual Studio è la naturale evoluzione.

Per noi sviluppatori .NET che viviamo in Visual Studio, questo elimina un altro motivo per fare context-switch verso il portale Azure. E onestamente, meno cambi di scheda si fanno, meglio è.

Aspire 13.2 aggiunge MongoDB EF Core e Azure Data Lake — Due integrazioni da provare

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Aspire 13.2 è appena arrivato con due nuove integrazioni database che meritano la vostra attenzione: MongoDB Entity Framework Core e Azure Data Lake Storage. Se volevate usare EF Core con MongoDB in un’app Aspire, o avevate bisogno di collegare workload data lake con il service discovery, questa release offre entrambe le cose.

MongoDB incontra EF Core in Aspire

Questa è quella che mi entusiasma di più. Aspire supporta MongoDB da un po’, ma è sempre stato il driver grezzo — niente EF Core, niente DbContext, niente query LINQ sui vostri documenti. Ora avete l’esperienza completa di EF Core con MongoDB, più gli health check automatici e il service discovery di Aspire.

La configurazione segue il classico pattern di Aspire. Nel vostro AppHost:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

Poi nel progetto consumatore, aggiungete l’integrazione EF Core:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

E registrate il vostro DbContext:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

Da lì in poi, è EF Core standard. Definite le vostre entità, usate il vostro DbContext come fareste con qualsiasi altro provider. L’integrazione gestisce il connection pooling, le trace OpenTelemetry e gli health check dietro le quinte.

Per gli sviluppatori .NET che usavano MongoDB con il driver grezzo e configuravano le connection string manualmente, questo è un bel miglioramento. Ottenete l’astrazione completa di EF Core senza perdere il service discovery di Aspire.

Azure Data Lake Storage entra in gioco

La seconda grande aggiunta è un’integrazione Azure Data Lake Storage (ADLS). Se state costruendo pipeline di dati, processi ETL o piattaforme di analisi, ora potete collegare risorse Data Lake allo stesso modo di qualsiasi altra dipendenza Aspire.

Nell’AppHost:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

Nel progetto consumatore:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Nessuna gestione manuale delle connection string, nessuna caccia alle credenziali. Aspire effettua il provisioning delle risorse e le inietta. Per chi di noi costruisce app .NET cloud-native che toccano sia dati operazionali che workload analitici, questo fa sentire il data lake come un cittadino di prima classe nel modello Aspire.

Le piccole correzioni che contano

Oltre alle funzionalità principali, ci sono alcuni miglioramenti degni di nota:

Fix della connection string MongoDB — lo slash prima del nome del database ora viene gestito correttamente. Se avevate un workaround, potete rimuoverlo
Export SQL Server — Aspire.Hosting.SqlServer ora esporta opzioni di configurazione server aggiuntive per un controllo più granulare
Aggiornamenti emulatori — emulatore ServiceBus 2.0.0, emulatore App Configuration 1.0.2, e l’emulatore preview di CosmosDB ora include un readiness check
Azure Managed Redis — ora usa rediss:// (Redis Secure) di default, quindi le connessioni sono crittografate fin da subito

L’ultimo punto è sottile ma importante — Redis crittografato di default significa una cosa in meno da configurare in produzione.

Per concludere

Aspire 13.2 è una release incrementale, ma le integrazioni MongoDB EF Core e Data Lake colmano lacune reali. Se stavate aspettando un supporto EF Core adeguato con MongoDB in Aspire, o avevate bisogno del Data Lake come dipendenza di prima classe, aggiornate alla 13.2 e provatele. Il comando aspire add genera tutto il necessario.

Leggete le note di rilascio complete per maggiori dettagli, e date un’occhiata alla galleria delle integrazioni per la lista completa.

azd update — Un solo comando per tutti i tuoi package manager

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Conosci quel messaggio “È disponibile una nuova versione di azd” che compare ogni poche settimane? Quello che ignori perché non ricordi se hai installato azd tramite winget, Homebrew o quello script curl che hai eseguito sei mesi fa? Ecco, finalmente è stato risolto.

Microsoft ha appena rilasciato azd update — un unico comando che aggiorna Azure Developer CLI all’ultima versione indipendentemente da come lo hai installato in origine. Windows, macOS, Linux — non importa. Un solo comando.

Come funziona

azd update

Tutto qui. Se vuoi accesso anticipato alle nuove funzionalità, puoi passare alla build giornaliera insiders:

azd update --channel daily
azd update --channel stable

Il comando rileva il tuo metodo di installazione attuale e utilizza il meccanismo di aggiornamento appropriato dietro le quinte. Niente più “aspetta, ho usato winget o choco su questa macchina?”

Il piccolo dettaglio

azd update è disponibile a partire dalla versione 1.23.x. Se sei su una versione precedente, dovrai fare un ultimo aggiornamento manuale usando il tuo metodo di installazione originale. Dopo di che, azd update gestisce tutto d’ora in avanti.

Controlla la tua versione attuale con azd version. Se hai bisogno di un’installazione da zero, la documentazione di installazione fa al caso tuo.

Perché è importante

È un piccolo miglioramento della qualità della vita, ma per chi di noi usa azd quotidianamente per il deploy di agenti IA e app Aspire su Azure, essere aggiornati significa meno momenti “questo bug era già stato corretto nell’ultima versione”. Una cosa in meno a cui pensare.

Leggi l’annuncio completo e l’approfondimento di Jon Gallant per maggiori dettagli.

Azure Smart Tier è in GA — Ottimizzazione automatica dei costi di Blob Storage senza regole di ciclo di vita

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Se hai mai passato tempo a ottimizzare le policy di ciclo di vita di Azure Blob Storage per poi vederle crollare quando i pattern di accesso sono cambiati, questo è per te. Microsoft ha appena annunciato la disponibilità generale dello smart tier per Azure Blob e Data Lake Storage — una funzionalità di tiering completamente gestita che sposta automaticamente gli oggetti tra i livelli hot, cool e cold in base all’utilizzo reale.

Cosa fa realmente lo smart tier

Il concetto è semplice: lo smart tier valuta continuamente l’ultimo orario di accesso di ogni oggetto nel tuo account di archiviazione. I dati acceduti frequentemente restano in hot, i dati inattivi passano a cool dopo 30 giorni, e poi a cold dopo altri 60 giorni. Quando i dati vengono nuovamente acceduti, vengono promossi subito a hot. Il ciclo ricomincia.

Nessuna regola di ciclo di vita da configurare. Nessuna previsione dei pattern di accesso. Nessun tuning manuale.

Durante la preview, Microsoft ha riportato che oltre il 50% della capacità gestita dallo smart tier si è spostata automaticamente verso livelli più freddi in base ai pattern di accesso reali. È una riduzione dei costi significativa per account di archiviazione di grandi dimensioni.

Perché è importante per gli sviluppatori .NET

Se stai costruendo applicazioni che generano log, telemetria, dati analitici, o qualsiasi tipo di patrimonio dati in crescita — e siamo onesti, chi non lo fa? — i costi di archiviazione si accumulano velocemente. L’approccio tradizionale era scrivere policy di gestione del ciclo di vita, testarle e poi ricalibrarle quando i pattern di accesso della tua applicazione cambiavano. Lo smart tier elimina completamente quel workflow.

Alcuni scenari pratici dove questo aiuta:

Telemetria e log delle applicazioni — hot durante il debug, raramente acceduti dopo qualche settimana
Pipeline di dati e output ETL — acceduti intensamente durante l’elaborazione, poi per lo più cold
Contenuti generati dagli utenti — gli upload recenti sono hot, i contenuti più vecchi si raffreddano gradualmente
Dati di backup e archiviazione — acceduti occasionalmente per conformità, per lo più inattivi

Come configurarlo

Abilitare lo smart tier è una configurazione una tantum:

Account nuovi: Seleziona smart tier come livello di accesso predefinito durante la creazione dell’account di archiviazione (ridondanza zonale richiesta)
Account esistenti: Cambia il livello di accesso blob dall’impostazione predefinita attuale a smart tier

Gli oggetti più piccoli di 128 KiB restano in hot e non generano la tariffa di monitoraggio. Per tutto il resto, paghi le tariffe standard di capacità hot/cool/cold senza costi di transizione tra livelli, senza penali per eliminazione anticipata e senza costi di recupero dati. Una tariffa mensile di monitoraggio per oggetto copre l’orchestrazione.

Il compromesso da conoscere

Le regole di tiering dello smart tier sono statiche (30 giorni → cool, 90 giorni → cold). Se hai bisogno di soglie personalizzate — ad esempio, spostare a cool dopo 7 giorni per un workload specifico — le regole di ciclo di vita restano la strada giusta. E non mescolare entrambi: evita di usare regole di ciclo di vita su oggetti gestiti dallo smart tier, perché possono entrare in conflitto.

Conclusione

Non è rivoluzionario, ma risolve un vero grattacapo operativo. Se gestisci account di blob storage in crescita e sei stanco di mantenere le policy di ciclo di vita, abilita lo smart tier e lascia che Azure se ne occupi. È disponibile oggi in quasi tutte le regioni zonali del cloud pubblico.

Dove dovresti ospitare i tuoi agenti IA su Azure? Una guida decisionale pratica

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Se stai costruendo agenti IA con .NET in questo momento, probabilmente hai notato qualcosa: ci sono molti modi per ospitarli su Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — e tutti sembrano ragionevoli finché non devi effettivamente sceglierne uno. Microsoft ha appena pubblicato una guida completa all’hosting di agenti IA su Azure che chiarisce tutto, e voglio analizzarla dalla prospettiva pratica di uno sviluppatore .NET.

Le sei opzioni a colpo d’occhio

Ecco come riassumerei il panorama:

Opzione	Ideale per	Gestisci tu
Container Apps	Controllo totale dei container senza complessità K8s	Osservabilità, stato, ciclo di vita
AKS	Compliance aziendale, multi-cluster, networking personalizzato	Tutto (è quello il punto)
Azure Functions	Task di agenti event-driven e di breve durata	Quasi niente — serverless vero
App Service	Agenti HTTP semplici, traffico prevedibile	Deploy, config di scaling
Foundry Agents	Agenti senza codice via portale/SDK	Quasi niente
Foundry Hosted Agents	Agenti con framework personalizzato e infra gestita	Solo il tuo codice agente

Le prime quattro sono compute general-purpose — puoi eseguire agenti su di esse, ma non sono state progettate per quello. Le ultime due sono native per agenti: comprendono conversazioni, chiamate a strumenti e cicli di vita degli agenti come concetti di prima classe.

Foundry Hosted Agents — il punto ideale per sviluppatori .NET di agenti

Questo è ciò che ha catturato la mia attenzione. I Foundry Hosted Agents si posizionano proprio nel mezzo: ottieni la flessibilità di eseguire il tuo codice (Semantic Kernel, Agent Framework, LangGraph — qualsiasi cosa) ma la piattaforma gestisce infrastruttura, osservabilità e gestione delle conversazioni.

Il pezzo chiave è l’Hosting Adapter — un sottile livello di astrazione che collega il tuo framework di agenti alla piattaforma Foundry. Per Microsoft Agent Framework, appare così:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

Questa è tutta la tua storia di hosting. L’adapter gestisce traduzione di protocolli, streaming via server-sent events, cronologia delle conversazioni e tracing OpenTelemetry — tutto automaticamente. Nessun middleware personalizzato, nessun plumbing manuale.

Il deploy è genuinamente semplice

Ho fatto deploy di agenti su Container Apps prima e funziona, ma finisci per scrivere molto codice di collegamento per gestione dello stato e osservabilità. Con Hosted Agents e azd, il deploy è:

# Installare l'estensione agente IA
azd ext install azure.ai.agents

# Inizializzare da un template
azd ai agent init

# Costruire, pushare, fare deploy — fatto
azd up

Quel singolo azd up costruisce il tuo container, lo pusha su ACR, provisiona il progetto Foundry, fa deploy degli endpoint del modello e avvia il tuo agente. Cinque passaggi condensati in un solo comando.

Gestione conversazioni integrata

Questa è la parte che fa risparmiare più tempo in produzione. Invece di costruire il tuo store di stato delle conversazioni, gli Hosted Agents lo gestiscono nativamente:

# Creare una conversazione persistente
conversation = openai_client.conversations.create()

# Primo turno
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Secondo turno — il contesto è preservato
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Niente Redis. Niente session store Cosmos DB. Niente middleware personalizzato per la serializzazione dei messaggi. La piattaforma semplicemente se ne occupa.

Il mio framework decisionale

Dopo aver esaminato tutte e sei le opzioni, ecco il mio modello mentale rapido:

Hai bisogno di zero infrastruttura? → Foundry Agents (portale/SDK, niente container)
Hai codice agente personalizzato ma vuoi hosting gestito? → Foundry Hosted Agents
Hai bisogno di task agente event-driven e di breve durata? → Azure Functions
Hai bisogno di massimo controllo dei container senza K8s? → Container Apps
Hai bisogno di compliance rigorosa e multi-cluster? → AKS
Hai un agente HTTP semplice con traffico prevedibile? → App Service

Per la maggior parte degli sviluppatori .NET che costruiscono con Semantic Kernel o Microsoft Agent Framework, Hosted Agents è probabilmente il punto di partenza giusto. Ottieni scale-to-zero, OpenTelemetry integrato, gestione conversazioni e flessibilità di framework — senza gestire Kubernetes o montare il tuo stack di osservabilità.

Per concludere

Il panorama dell’hosting di agenti su Azure sta maturando velocemente. Se stai iniziando un nuovo progetto di agente IA oggi, considererei seriamente Foundry Hosted Agents prima di ricorrere a Container Apps o AKS per abitudine. L’infrastruttura gestita fa risparmiare tempo reale, e il pattern hosting adapter ti permette di mantenere la tua scelta di framework.

Dai un’occhiata alla guida completa di Microsoft e al repo Foundry Samples per esempi funzionanti.

Le Agent Skills in .NET sono diventate davvero flessibili

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

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.

Azure MCP Server 2.0 è Arrivato — L'Automazione Agentica Self-Hosted nel Cloud È Qui

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

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

Se hai costruito qualcosa con MCP e Azure di recente, probabilmente sai già che l’esperienza locale funziona bene. Connetti un server MCP, lascia che il tuo agente AI parli alle risorse Azure, e vai avanti. Ma nel momento in cui hai bisogno di condividere questa configurazione con un team? Ecco dove le cose si complicavano.

Non più. Azure MCP Server ha appena raggiunto la versione 2.0 stabile, e la feature principale è esattamente quello che i team enterprise chiedevano: supporto per server MCP remoti self-hosted.

Che cos’è Azure MCP Server?

Un rapido ripasso. Azure MCP Server implementa la specifica Model Context Protocol ed espone le capacità di Azure come tool strutturati e scopribili che gli agenti AI possono invocare. Pensalo come un ponte standardizzato tra il tuo agente e Azure — provisioning, deployment, monitoring, diagnostica, tutto attraverso un’interfaccia coerente.

I numeri parlano da soli: 276 tool MCP su 57 servizi Azure. È una copertura seria.

Il grande affare: deployment remoti self-hosted

Ecco il punto. Eseguire MCP localmente sulla tua macchina va bene per lo sviluppo e gli esperimenti. Ma in uno scenario di team reale, hai bisogno di:

Accesso condiviso per sviluppatori e sistemi agentici interni
Configurazione centralizzata (contesto tenant, impostazioni di sottoscrizione predefinite, telemetria)
Limiti di rete e policy aziendali
Integrazione nelle pipeline CI/CD

Azure MCP Server 2.0 affronta tutto questo. Puoi deployarlo come servizio interno gestito centralmente con trasporto basato su HTTP, autenticazione adeguata e governance coerente.

Per l’autenticazione, hai due solide opzioni:

Managed Identity — quando eseguito insieme a Microsoft Foundry
On-Behalf-Of (OBO) flow — delegazione OpenID Connect che chiama le API Azure usando il contesto dell’utente autenticato

Quel flusso OBO è particolarmente interessante per noi sviluppatori .NET. Significa che i tuoi workflow agentici possono operare con i permessi effettivi dell’utente, non con un account di servizio sovra-privilegiato. Principio del minimo privilegio, integrato fin dall’inizio.

Hardening della sicurezza

Non è solo un rilascio di feature — è anche uno di sicurezza. Il rilascio 2.0 aggiunge:

Validazione endpoint più forte
Protezioni contro i pattern di injection negli strumenti orientati alle query
Controlli di isolamento più rigidi per gli ambienti di sviluppo

Se stai per esporre MCP come servizio condiviso, questi salvaguardi contano. Molto.

Dove puoi usarlo?

La storia della compatibilità client è ampia. Azure MCP Server 2.0 funziona con:

IDE: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
Agenti CLI: GitHub Copilot CLI, Claude Code
Standalone: server locale per configurazioni semplici
Self-hosted remote: la nuova stella del 2.0

Inoltre c’è il supporto per sovereign cloud per Azure US Government e Azure gestito da 21Vianet, che è critico per i deployment regolamentati.

Perché questo conta per gli sviluppatori .NET

Se stai costruendo applicazioni agentiche con .NET — che sia Semantic Kernel, Microsoft Agent Framework, o la tua orchestrazione personalizzata — Azure MCP Server 2.0 ti dà un modo production-ready per lasciare che i tuoi agenti interagiscano con l’infrastruttura Azure. Nessun wrapper REST personalizzato. Nessun pattern di integrazione specifico per il servizio. Solo MCP.

Combinato con l’API fluent per MCP Apps uscito pochi giorni fa, l’ecosistema .NET MCP sta maturando velocemente.

Per iniziare

Scegli il tuo percorso:

GitHub Repo — codice sorgente, documentazione, tutto
Docker Image — deployment containerizzato
VS Code Extension — integrazione IDE
Self-hosting guide — la feature principale del 2.0

Per concludere

Azure MCP Server 2.0 è esattamente il tipo di upgrade infrastrutturale che non sembra vistoso in una demo ma cambia tutto nella pratica. MCP remoto self-hosted con autenticazione appropriata, hardening della sicurezza e supporto per sovereign cloud significa che MCP è pronto per team reali che costruiscono workflow agentici reali su Azure. Se stavi aspettando il segnale “enterprise-ready” — questo è.

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

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

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.

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

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

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.

L'Ingegneria delle Piattaforme Agentiche Sta Diventando Realtà — Git-APE Mostra Come

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

L’ingegneria delle piattaforme è stato uno di quei termini che suona bene alle conferenze ma che di solito significa “abbiamo costruito un portale interno e un wrapper Terraform.” La vera promessa — infrastruttura self-service che sia realmente sicura, governata e veloce — è sempre stata a qualche passo di distanza.

Il team Azure ha appena pubblicato la Parte 2 della serie sull’ingegneria delle piattaforme agentiche, e questa è tutta sull’implementazione pratica. Lo chiamano Git-APE (sì, l’acronimo è intenzionale), ed è un progetto open source che utilizza agenti GitHub Copilot più server Azure MCP per trasformare richieste in linguaggio naturale in infrastruttura validata e deployata.

Cosa fa Git-APE concretamente

L’idea centrale: invece di far imparare ai developer moduli Terraform, navigare nelle UI dei portali o aprire ticket al team piattaforma, parlano con un agente Copilot. L’agente interpreta l’intento, genera Infrastructure-as-Code, la valida contro le policy e deploya — tutto all’interno di VS Code.

Ecco il setup:

git clone https://github.com/Azure/git-ape
cd git-ape

Apri il workspace in VS Code, e i file di configurazione dell’agente vengono scoperti automaticamente da GitHub Copilot. Interagisci direttamente con l’agente:

@git-ape deploy a function app with storage in West Europe

L’agente utilizza Azure MCP Server internamente per interagire con i servizi Azure. La configurazione MCP nelle impostazioni di VS Code abilita capacità specifiche:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Perché è importante

Per chi di noi costruisce su Azure, questo sposta la conversazione sull’ingegneria delle piattaforme da “come costruiamo un portale” a “come descriviamo i nostri guardrail come API.” Quando l’interfaccia della tua piattaforma è un agente IA, la qualità dei tuoi vincoli e delle tue policy diventa il prodotto.

Il blog della Parte 1 esponeva la teoria: API ben descritte, schemi di controllo e guardrail espliciti rendono le piattaforme agent-ready. La Parte 2 dimostra che funziona rilasciando strumenti concreti. L’agente non genera risorse alla cieca — valida contro le best practice, rispetta le convenzioni di naming e applica le policy della tua organizzazione.

La pulizia è altrettanto semplice:

@git-ape destroy my-resource-group

La mia opinione

Sarò onesto — qui si tratta più del pattern che dello strumento specifico. Git-APE in sé è una demo/architettura di riferimento. Ma l’idea sottostante — agenti come interfaccia alla tua piattaforma, MCP come protocollo, GitHub Copilot come host — è la direzione in cui sta andando l’esperienza developer enterprise.

Se sei un team piattaforma che cerca come rendere il proprio tooling interno agent-friendly, non c’è punto di partenza migliore. E se sei uno sviluppatore .NET che si chiede come questo si collega al suo mondo: Azure MCP Server e gli agenti GitHub Copilot funzionano con qualsiasi workload Azure. La tua API ASP.NET Core, il tuo stack .NET Aspire, i tuoi microservizi containerizzati — tutto può essere il target di un flusso di deployment agentico.

Per concludere

Git-APE è uno sguardo precoce ma concreto sull’ingegneria delle piattaforme agentiche nella pratica. Clona il repo, prova la demo e inizia a pensare a come le API e le policy della tua piattaforma dovrebbero apparire per permettere a un agente di usarle in sicurezza.

Leggi il post completo per il walkthrough e i video dimostrativi.

La valutazione di modernizzazione di GitHub Copilot è il miglior strumento di migrazione che non stai ancora usando

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

Migrare un’app legacy .NET Framework a .NET moderno è una di quelle attività che tutti sanno di dover fare ma che nessuno vuole iniziare. Non è mai solo “cambiare il target framework.” Sono API che sono scomparse, pacchetti che non esistono più, modelli di hosting che funzionano in modo completamente diverso, e un milione di piccole decisioni su cosa containerizzare, cosa riscrivere e cosa lasciare così.

Jeffrey Fritz ha appena pubblicato un approfondimento sulla valutazione di modernizzazione di GitHub Copilot, e onestamente? È il miglior tooling di migrazione che abbia visto per .NET. Non per la generazione di codice — quello è ormai standard. Per il documento di valutazione che produce.

Non è solo un motore di suggerimenti di codice

L’estensione VS Code segue un modello Valuta → Pianifica → Esegui. La fase di valutazione analizza l’intero codebase e produce un documento strutturato che cattura tutto: cosa deve cambiare, quali risorse Azure provisionare, quale modello di deployment usare. Tutto ciò che segue — infrastructure as code, containerizzazione, manifesti di deployment — deriva da ciò che la valutazione trova.

La valutazione viene salvata in .github/modernize/assessment/ nel tuo progetto. Ogni esecuzione produce un report indipendente, così accumuli uno storico e puoi monitorare come la tua postura di migrazione evolve man mano che risolvi gli issue.

Due modi per iniziare

Valutazione Consigliata — il percorso veloce. Scegli tra domini curati (Upgrade Java/.NET, Cloud Readiness, Sicurezza) e ottieni risultati significativi senza toccare la configurazione. Ottimo per un primo sguardo a dove si trova la tua app.

Valutazione Personalizzata — il percorso mirato. Configura esattamente cosa analizzare: compute target (App Service, AKS, Container Apps), OS target, analisi della containerizzazione. Scegli più target Azure per confrontare gli approcci di migrazione fianco a fianco.

Quella vista di confronto è genuinamente utile. Un’app con 3 issue obbligatori per App Service potrebbe averne 7 per AKS. Vedere entrambi aiuta a guidare la decisione sull’hosting prima di impegnarsi in un percorso di migrazione.

La suddivisione degli issue è azionabile

Ogni issue viene con un livello di criticità:

Obbligatorio — deve essere risolto o la migrazione fallisce
Potenziale — potrebbe impattare la migrazione, necessita di giudizio umano
Opzionale — miglioramenti raccomandati, non bloccano la migrazione

E ogni issue linka ai file interessati e numeri di riga, fornisce una descrizione dettagliata di cosa c’è che non va e perché conta per la tua piattaforma target, dà passaggi concreti di remediation (non solo “sistema questo”), e include link alla documentazione ufficiale.

Puoi assegnare singoli issue agli sviluppatori e hanno tutto ciò di cui hanno bisogno per agire. Questa è la differenza tra uno strumento che ti dice “c’è un problema” e uno che ti dice come risolverlo.

I percorsi di upgrade coperti

Per .NET specificamente:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Ogni percorso di upgrade ha regole di rilevamento che sanno quali API sono state rimosse, quali pattern non hanno un equivalente diretto e quali problemi di sicurezza richiedono attenzione.

Per i team che gestiscono più applicazioni, c’è anche un CLI che supporta valutazioni batch multi-repo — clona tutti i repo, valutali tutti, ottieni report per app più una vista aggregata del portfolio.

La mia opinione

Se sei seduto su applicazioni legacy .NET Framework (e siamo onesti, la maggior parte dei team enterprise lo è), questo è lo strumento con cui iniziare. Il solo documento di valutazione vale il tempo — trasforma un vago “dovremmo modernizzare” in una lista concreta e prioritizzata di elementi di lavoro con percorsi chiari in avanti.

Il workflow collaborativo è intelligente anche: esporta le valutazioni, condividile con il tuo team, importale senza rieseguire. Review di architettura dove chi decide non è chi esegue gli strumenti? Coperto.

Conclusione

La valutazione di modernizzazione di GitHub Copilot trasforma la migrazione .NET da un progetto spaventoso e indefinito in un processo strutturato e tracciabile. Inizia con una valutazione consigliata per vedere a che punto sei, poi usa valutazioni personalizzate per confrontare i target Azure e costruire il tuo piano di migrazione.

Leggi il walkthrough completo e scarica l’estensione VS Code per provarla sul tuo codebase.

Microsoft Foundry Marzo 2026 — GPT-5.4, Agent Service GA e il Refresh dell'SDK Che Cambia Tutto

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

I post mensili “Novità in Microsoft Foundry” sono solitamente un mix di miglioramenti incrementali e occasionali funzionalità di rilievo. L’edizione di marzo 2026? Praticamente tutte funzionalità di rilievo. Foundry Agent Service raggiunge la GA, GPT-5.4 arriva in produzione, l’SDK riceve un importante rilascio stabile, e Fireworks AI porta l’inferenza di modelli aperti su Azure. Vediamo cosa conta per gli sviluppatori .NET.

Foundry Agent Service è pronto per la produzione

Questa è la grande notizia. Il runtime di agenti di nuova generazione è generalmente disponibile — costruito sull’API Responses di OpenAI, compatibile a livello di protocollo con gli agenti OpenAI, e aperto a modelli di diversi provider. Se state costruendo con l’API Responses oggi, migrare a Foundry aggiunge sicurezza enterprise, networking privato, RBAC di Entra, tracing completo e valutazione sulla vostra logica di agenti esistente.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

Aggiunte chiave: networking privato end-to-end, espansione dell’autenticazione MCP (incluso il passthrough OAuth), anteprima di Voice Live per agenti voce-a-voce, e agenti ospitati in 6 nuove regioni.

GPT-5.4 — affidabilità oltre l’intelligenza pura

GPT-5.4 non riguarda l’essere più intelligente. Riguarda l’essere più affidabile. Ragionamento più solido nelle interazioni lunghe, migliore aderenza alle istruzioni, meno fallimenti a metà workflow, e capacità integrate di computer use. Per gli agenti in produzione, quell’affidabilità conta molto più dei punteggi nei benchmark.

Modello	Prezzo (per M token)	Ideale Per
GPT-5.4 (≤272K)	$2.50 / $15 output	Agenti in produzione, coding, workflow documentali
GPT-5.4 Pro	$30 / $180 output	Analisi approfondita, ragionamento scientifico
GPT-5.4 Mini	Economico	Classificazione, estrazione, chiamate leggere a strumenti

La mossa intelligente è una strategia di routing: GPT-5.4 Mini gestisce il lavoro ad alto volume e bassa latenza mentre GPT-5.4 si occupa delle richieste con ragionamento pesante.

L’SDK è finalmente stabile

L’SDK azure-ai-projects ha rilasciato versioni stabili in tutti i linguaggi — Python 2.0.0, JS/TS 2.0.0, Java 2.0.0, e .NET 2.0.0 (1 aprile). La dipendenza da azure-ai-agents è sparita — tutto vive sotto AIProjectClient. Installate con pip install azure-ai-projects e il pacchetto include openai e azure-identity come dipendenze dirette.

Per gli sviluppatori .NET, questo significa un singolo pacchetto NuGet per l’intera superficie di Foundry. Basta destreggiarsi tra SDK di agenti separati.

Fireworks AI porta i modelli aperti su Azure

Forse l’aggiunta più interessante dal punto di vista architetturale: Fireworks AI elabora oltre 13 trilioni di token al giorno a ~180K richieste/secondo, ora disponibile tramite Foundry. DeepSeek V3.2, gpt-oss-120b, Kimi K2.5, e MiniMax M2.5 al lancio.

La vera storia è il bring-your-own-weights — caricate pesi quantizzati o fine-tunati da qualsiasi luogo senza cambiare lo stack di serving. Deploy tramite serverless pay-per-token o throughput provisionato.

Altri punti salienti

Phi-4 Reasoning Vision 15B — ragionamento multimodale per grafici, diagrammi e layout di documenti
Evaluations GA — valutatori pronti all’uso con monitoraggio continuo della produzione integrato in Azure Monitor
Priority Processing (Preview) — corsia di calcolo dedicata per carichi di lavoro sensibili alla latenza
Voice Live — runtime voce-a-voce che si connette direttamente agli agenti Foundry
Tracing GA — ispezione end-to-end delle tracce degli agenti con ordinamento e filtraggio
Deprecazione di PromptFlow — migrazione a Microsoft Framework Workflows entro gennaio 2027

Conclusione

Marzo 2026 è un punto di svolta per Foundry. Agent Service GA, SDK stabili in tutti i linguaggi, GPT-5.4 per agenti di produzione affidabili, e inferenza di modelli aperti via Fireworks AI — la piattaforma è pronta per carichi di lavoro seri.

Leggete il riepilogo completo e create il vostro primo agente per iniziare.

SQL MCP Server — Il modo giusto per dare accesso ai database agli agenti AI

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

Siamo onesti: la maggior parte dei server MCP per database disponibili oggi sono spaventosi. Prendono una query in linguaggio naturale, generano SQL al volo e lo eseguono contro i tuoi dati di produzione. Cosa potrebbe andare storto? (Tutto. Tutto potrebbe andare storto.)

Il team di Azure SQL ha appena presentato SQL MCP Server, e adotta un approccio fondamentalmente diverso. Costruito come funzionalità di Data API builder (DAB) 2.0, dà agli agenti AI un accesso strutturato e deterministico alle operazioni sul database — senza NL2SQL, senza esporre il tuo schema, e con RBAC completo ad ogni passaggio.

Perché non NL2SQL?

Questa è la decisione di design più interessante. I modelli non sono deterministici, e le query complesse sono le più propense a produrre errori sottili. Le query esatte che gli utenti sperano che l’AI possa generare sono anche quelle che richiedono più scrutinio quando prodotte in modo non deterministico.

Invece, SQL MCP Server usa un approccio NL2DAB. L’agente lavora con il livello di astrazione delle entità di Data API builder e il suo query builder integrato per produrre T-SQL accurato e ben formato in modo deterministico. Stesso risultato per l’utente, ma senza il rischio di JOIN allucinati o esposizione accidentale di dati.

Sette strumenti, non settecento

SQL MCP Server espone esattamente sette strumenti DML, indipendentemente dalle dimensioni del database:

describe_entities — scoprire entità e operazioni disponibili
create_record — inserire righe
read_records — interrogare tabelle e viste
update_record — modificare righe
delete_record — rimuovere righe
execute_entity — eseguire stored procedure
aggregate_records — query di aggregazione

Questo è intelligente perché le finestre di contesto sono lo spazio di pensiero dell’agente. Inondarle con centinaia di definizioni di strumenti lascia meno spazio per il ragionamento. Sette strumenti fissi mantengono l’agente concentrato sul pensare piuttosto che sul navigare.

Ogni strumento può essere abilitato o disabilitato individualmente:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

Iniziare in tre comandi

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

Ecco un SQL MCP Server funzionante che espone la tua tabella Customers. Il livello di astrazione delle entità significa che puoi creare alias per nomi e colonne, limitare i campi per ruolo e controllare esattamente cosa vedono gli agenti — senza esporre dettagli interni dello schema.

La storia della sicurezza è solida

Qui è dove la maturità di Data API builder ripaga:

RBAC ad ogni livello — ogni entità definisce quali ruoli possono leggere, creare, aggiornare o eliminare, e quali campi sono visibili
Integrazione con Azure Key Vault — stringhe di connessione e segreti gestiti in modo sicuro
Microsoft Entra + OAuth personalizzato — autenticazione di livello produzione
Content Security Policy — gli agenti interagiscono attraverso un contratto controllato, non SQL grezzo

L’astrazione dello schema è particolarmente importante. I nomi interni delle tue tabelle e colonne non vengono mai esposti all’agente. Definisci entità, alias e descrizioni che hanno senso per l’interazione AI — non il tuo diagramma ERD del database.

Multi-database e multi-protocollo

SQL MCP Server supporta Microsoft SQL, PostgreSQL, Azure Cosmos DB e MySQL. E poiché è una funzionalità di DAB, ottieni endpoint REST, GraphQL e MCP simultaneamente dalla stessa configurazione. Stesse definizioni di entità, stesse regole RBAC, stessa sicurezza — su tutti e tre i protocolli.

L’auto-configurazione in DAB 2.0 può persino ispezionare il tuo database e costruire la configurazione dinamicamente, se sei a tuo agio con meno astrazione per la prototipazione rapida.

La mia opinione

Ecco come dovrebbe funzionare l’accesso aziendale ai database per gli agenti AI. Non “hey LLM, scrivimi un po’ di SQL e YOLO sulla produzione.” Invece: un livello di entità ben definito, generazione deterministica delle query, RBAC ad ogni passaggio, caching, monitoraggio e telemetria. È noioso nel miglior modo possibile.

Per gli sviluppatori .NET, la storia dell’integrazione è pulita — DAB è uno strumento .NET, l’MCP Server gira come container, e funziona con Azure SQL, che la maggior parte di noi sta già usando. Se stai costruendo agenti AI che hanno bisogno di accesso ai dati, inizia qui.

Conclusione

SQL MCP Server è gratuito, open-source e gira ovunque. È l’approccio prescrittivo di Microsoft per dare agli agenti AI un accesso sicuro ai database. Consulta il post completo e la documentazione per iniziare.

azd ora permette di eseguire e debuggare agenti IA localmente — Ecco cosa è cambiato a marzo 2026

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Sette rilasci in un mese. È quello che il team dell’Azure Developer CLI (azd) ha pubblicato a marzo 2026, e la funzionalità principale è quella che stavo aspettando: un loop locale di esecuzione e debug per agenti IA.

PC Chan ha pubblicato il riepilogo completo, e anche se c’è molto contenuto, lasciatemi filtrare ciò che conta davvero per gli sviluppatori .NET che costruiscono app con IA.

Eseguire e debuggare agenti IA senza deploy

Questa è la novità principale. La nuova estensione azure.ai.agents aggiunge comandi che danno un’esperienza di inner-loop adeguata per gli agenti IA:

azd ai agent run — avvia il tuo agente localmente
azd ai agent invoke — gli invia messaggi (locale o in produzione)
azd ai agent show — mostra lo stato del container e la sua salute
azd ai agent monitor — trasmette i log del container in tempo reale

Prima, testare un agente IA significava fare deploy su Microsoft Foundry ogni volta che facevi un cambiamento. Ora puoi iterare localmente, testare il comportamento del tuo agente, e fare deploy solo quando sei pronto.

GitHub Copilot configura il tuo progetto azd

azd init ora offre un’opzione “Set up with GitHub Copilot (Preview)”. Invece di rispondere manualmente ai prompt, un agente Copilot genera la configurazione per te. Quando un comando fallisce, azd offre troubleshooting assistito dall’IA — tutto senza lasciare il terminale.

Container App Jobs e miglioramenti del deployment

Container App Jobs: azd ora fa deploy di Microsoft.App/jobs tramite la config esistente host: containerapp.
Timeout configurabili: Nuovo flag --timeout su azd deploy e campo deployTimeout in azure.yaml.
Fallback di build remoto: Quando il build ACR fallisce, azd passa automaticamente a Docker/Podman locale.
Validazione preflight locale: I parametri Bicep vengono validati localmente prima del deploy.

Miglioramenti DX

Rilevamento automatico pnpm/yarn per progetti JS/TS
Supporto pyproject.toml per Python
Directory template locali — azd init --template accetta percorsi del filesystem
Messaggi di errore migliori in modalità --no-prompt
Variabili d’ambiente di build iniettate in tutti i sottoprocessi di build (.NET, Node.js, Java, Python)

Per concludere

Il loop locale di debug per agenti IA è la star di questa release, ma l’accumulo di miglioramenti al deployment e alla DX rende azd più maturo che mai. Se fai deploy di app .NET su Azure — specialmente agenti IA — questo aggiornamento vale la pena.

Consulta le note di rilascio complete per tutti i dettagli.

KubeCon Europe 2026: Cosa dovrebbero davvero sapere gli sviluppatori .NET

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

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

Conosci quella sensazione quando esce un post di annunci enorme e scrolli pensando “bello, ma cosa cambia davvero per me”? Mi succede ogni stagione KubeCon.

Microsoft ha appena pubblicato il riassunto completo di KubeCon Europe 2026 — scritto da Brendan Burns in persona — e onestamente? C’è sostanza vera. Non solo checklist di feature, ma miglioramenti operativi che cambiano come gestisci le cose in produzione.

Vediamo cosa conta davvero per noi sviluppatori .NET.

mTLS senza la tassa del service mesh

Il punto sui service mesh: tutti vogliono le garanzie di sicurezza, nessuno vuole il carico operativo. AKS sta finalmente colmando questo divario.

Azure Kubernetes Application Network ti dà mutual TLS, autorizzazione application-aware e telemetria del traffico — senza deployare un mesh pesante con sidecar. Combinato con Cilium mTLS in Advanced Container Networking Services, ottieni comunicazione crittografata pod-a-pod usando certificati X.509 e SPIRE per la gestione delle identità.

Cosa significa in pratica: le tue API ASP.NET Core che parlano con worker in background, i tuoi servizi gRPC che si chiamano a vicenda — tutto crittografato e verificato a livello di rete, senza modifiche al codice applicativo. È enorme.

Per i team che migrano da ingress-nginx, c’è anche Application Routing con Meshless Istio con supporto completo per Kubernetes Gateway API. Niente sidecar. Basato su standard. E hanno rilasciato strumenti ingress2gateway per la migrazione incrementale.

Osservabilità GPU che non è un ripensamento

Se stai eseguendo inferenza IA accanto ai tuoi servizi .NET (e siamo onesti, chi non sta iniziando?), probabilmente hai incontrato il punto cieco del monitoraggio GPU. Avevi dashboard fantastiche per CPU/memoria e poi… niente per le GPU senza configurazione manuale degli exporter.

AKS ora espone le metriche GPU nativamente in Prometheus e Grafana gestiti. Stesso stack, stesse dashboard, stessa pipeline di alerting. Nessun exporter custom, nessun agent di terze parti.

Sul lato rete, hanno aggiunto visibilità per flusso per traffico HTTP, gRPC e Kafka con un’esperienza Azure Monitor one-click. IP, porte, workload, direzione del flusso, decisioni di policy — tutto in dashboard integrate.

E quella che mi ha fatto guardare due volte: agentic container networking aggiunge un’interfaccia web dove puoi fare domande in linguaggio naturale sullo stato di rete del tuo cluster. “Perché il pod X non raggiunge il servizio Y?” → diagnostica read-only dalla telemetria live. Genuinamente utile alle 2 di notte.

Networking cross-cluster senza bisogno di un dottorato

Il multi-cluster Kubernetes storicamente è stato un’esperienza “porta la tua colla di rete”. Azure Kubernetes Fleet Manager ora offre networking cross-cluster tramite Cilium cluster mesh gestito:

Connettività unificata tra cluster AKS
Registro globale dei servizi per la scoperta cross-cluster
Configurazione gestita centralmente, non ripetuta per cluster

Se esegui microservizi .NET su più regioni per resilienza o compliance, questo sostituisce molto collante custom fragile. Il Servizio A in West Europe può scoprire e chiamare il Servizio B in East US attraverso il mesh, con policy di routing e sicurezza consistenti.

Aggiornamenti che non richiedono coraggio

Siamo onesti — gli aggiornamenti Kubernetes in produzione sono stressanti. “Aggiornare e sperare” è stata la strategia de facto per troppi team, ed è la ragione principale per cui i cluster restano indietro con le versioni.

Due nuove capacità cambiano questo:

Blue-green agent pool upgrade creano un pool di nodi parallelo con la nuova configurazione. Valida il comportamento, sposta il traffico gradualmente e mantieni un percorso di rollback pulito. Niente più mutazioni in-place su nodi di produzione.

Agent pool rollback permette di riportare un pool di nodi alla versione Kubernetes e all’immagine nodo precedenti dopo che un aggiornamento va storto — senza ricostruire il cluster.

Insieme, danno finalmente agli operatori un vero controllo sul ciclo di vita degli aggiornamenti. Per i team .NET, questo è importante perché la velocità della piattaforma controlla direttamente quanto rapidamente puoi adottare nuovi runtime, patch di sicurezza e capacità di rete.

I workload IA diventano cittadini di prima classe in Kubernetes

Il lavoro upstream open-source è altrettanto importante. Dynamic Resource Allocation (DRA) è appena andato in GA in Kubernetes 1.36, rendendo lo scheduling GPU una feature di prima classe invece di un workaround.

Alcuni progetti da tenere d’occhio:

Progetto	Cosa fa
AI Runway	API Kubernetes comune per l’inferenza — deploy di modelli senza conoscere K8s, con scoperta HuggingFace e stime dei costi
HolmesGPT	Troubleshooting agentico per il cloud-native — ora un progetto CNCF Sandbox
Dalec	Build dichiarativi di immagini container con generazione SBOM — meno CVE nella fase di build

La direzione è chiara: la tua API .NET, il tuo layer di orchestrazione con Semantic Kernel e i tuoi workload di inferenza dovrebbero tutti girare su un modello di piattaforma consistente. Ci stiamo arrivando.

Da dove partirei questa settimana

Se stai valutando questi cambiamenti per il tuo team, ecco la mia lista onesta di priorità:

Osservabilità prima — abilita le metriche GPU e i log di flusso di rete in un cluster non-prod. Guarda cosa ti sei perso.
Prova i blue-green upgrade — testa il workflow di rollback prima del tuo prossimo aggiornamento di cluster in produzione. Costruisci fiducia nel processo.
Pilota il networking identity-aware — scegli un percorso di servizio interno e abilita mTLS con Cilium. Misura l’overhead (spoiler: è minimo).
Valuta Fleet Manager — se gestisci più di due cluster, il networking cross-cluster si ripaga da solo in riduzione di collante custom.

Piccoli esperimenti, feedback veloce. È sempre la mossa giusta.

Per concludere

Gli annunci KubeCon possono essere travolgenti, ma questa tornata muove davvero l’ago per i team .NET su AKS. Migliore sicurezza di rete senza overhead di mesh, vera osservabilità GPU, aggiornamenti più sicuri e fondamenta più solide per l’infrastruttura IA.

Se sei già su AKS, è un ottimo momento per rafforzare la tua baseline operativa. E se stai pianificando di spostare workload .NET su Kubernetes — la piattaforma è appena diventata significativamente più pronta per la produzione.

SQL MCP Server, Copilot in SSMS e un Database Hub con agenti IA: Cosa conta davvero dalla SQLCon 2026

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft ha appena inaugurato SQLCon 2026 insieme a FabCon ad Atlanta, e c’è un sacco di roba da analizzare. L’annuncio originale copre tutto, dai piani di risparmio alle funzionalità di conformità enterprise. Io salterò le slide sui prezzi enterprise e mi concentrerò sugli elementi che contano se sei uno sviluppatore che costruisce cose con Azure SQL e IA.

SQL MCP Server è in public preview

Questa è la notizia principale per me. Azure SQL Database Hyperscale ora ha un SQL MCP Server in public preview che ti permette di connettere in modo sicuro i tuoi dati SQL ad agenti IA e Copilot usando il Model Context Protocol.

Se hai seguito l’onda MCP — e onestamente, è difficile non notarla in questo momento — questa è una grande novità. Invece di costruire pipeline di dati personalizzate per alimentare i tuoi agenti IA con il contesto dal tuo database, ottieni un protocollo standardizzato per esporre i dati SQL direttamente. I tuoi agenti possono interrogare, ragionare e agire su informazioni del database in tempo reale.

Per quelli di noi che costruiscono agenti IA con Semantic Kernel o il Microsoft Agent Framework, questo apre un percorso di integrazione pulito. Il tuo agente deve controllare l’inventario? Cercare un record cliente? Validare un ordine? MCP gli dà un modo strutturato per farlo senza che tu debba scrivere codice di recupero dati su misura per ogni scenario.

GitHub Copilot in SSMS 22 è ora GA

Se passi del tempo in SQL Server Management Studio — e siamo onesti, la maggior parte di noi lo fa ancora — GitHub Copilot è ora disponibile in versione generale in SSMS 22. La stessa esperienza Copilot che già usi in VS Code e Visual Studio, ma per T-SQL.

Il valore pratico è semplice: assistenza via chat per scrivere query, refactoring di stored procedure, risoluzione di problemi di performance e gestione di task amministrativi. Niente di rivoluzionario come concetto, ma averlo direttamente in SSMS significa che non devi cambiare contesto verso un altro editor solo per ottenere aiuto IA sul tuo lavoro coi database.

Gli indici vettoriali hanno avuto un serio upgrade

Azure SQL Database ora ha indici vettoriali più veloci e più capaci con supporto completo per insert, update e delete. Questo significa che i tuoi dati vettoriali restano aggiornati in tempo reale — niente reindicizzazione batch necessaria.

Ecco le novità:

Quantizzazione per dimensioni degli indici più piccole senza perdere troppa accuratezza
Filtro iterativo per risultati più precisi
Integrazione più stretta con il query optimizer per performance prevedibili

Se stai facendo Retrieval-Augmented Generation (RAG) con Azure SQL come vector store, questi miglioramenti sono direttamente utili. Puoi tenere i tuoi vettori insieme ai dati relazionali nello stesso database, il che semplifica notevolmente la tua architettura rispetto a gestire un database vettoriale separato.

Gli stessi miglioramenti vettoriali sono disponibili anche in SQL Database in Fabric, dato che entrambi girano sullo stesso motore SQL sotto il cofano.

Database Hub in Fabric: gestione agentica

Questo punto è più orientato al futuro, ma è interessante. Microsoft ha annunciato il Database Hub in Microsoft Fabric (accesso anticipato), che ti dà un pannello unico su Azure SQL, Cosmos DB, PostgreSQL, MySQL e SQL Server via Arc.

L’aspetto interessante non è solo la vista unificata — è l’approccio agentico alla gestione. Agenti IA monitorano continuamente il tuo parco database, evidenziano cosa è cambiato, spiegano perché è importante e suggeriscono cosa fare dopo. È un modello human-in-the-loop dove l’agente fa il lavoro pesante e tu prendi le decisioni.

Per i team che gestiscono più di una manciata di database, questo potrebbe davvero ridurre il rumore operativo. Invece di saltare tra portali e controllare manualmente le metriche, l’agente porta il segnale a te.

Cosa significa questo per gli sviluppatori .NET

Il filo conduttore di tutti questi annunci è chiaro: Microsoft sta integrando agenti IA in ogni livello dello stack database. Non come un espediente, ma come un livello pratico di strumenti.

Se stai costruendo app .NET supportate da Azure SQL, ecco cosa farei concretamente:

Prova il SQL MCP Server se stai costruendo agenti IA. È il modo più pulito per dare ai tuoi agenti accesso al database senza plumbing personalizzato.
Attiva Copilot in SSMS se non l’hai già fatto — un guadagno di produttività gratuito per il lavoro SQL quotidiano.
Dai un’occhiata agli indici vettoriali se stai facendo RAG e attualmente usi un vector store separato. Consolidare su Azure SQL significa un servizio in meno da gestire.

Per concludere

L’annuncio completo contiene di più — piani di risparmio, assistenti per la migrazione, funzionalità di conformità — ma la storia per gli sviluppatori è nel MCP Server, nei miglioramenti vettoriali e nel livello di gestione agentica. Questi sono gli elementi che cambiano come costruisci, non solo come fai il budget.

Dai un’occhiata all’annuncio completo di Shireesh Thota per il quadro completo, e iscriviti per l’accesso anticipato al Database Hub se vuoi provare la nuova esperienza di gestione.

Azure DevOps MCP Server arriva in Microsoft Foundry: cosa significa per i tuoi agenti IA

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

MCP (Model Context Protocol) sta avendo il suo momento. Se hai seguito l’ecosistema degli agenti IA, probabilmente hai notato che i server MCP stanno spuntando ovunque — dando agli agenti la capacità di interagire con strumenti e servizi esterni attraverso un protocollo standardizzato.

Ora l’Azure DevOps MCP Server è disponibile in Microsoft Foundry, e questa è una di quelle integrazioni che ti fa pensare alle possibilità pratiche.

Cosa sta succedendo realmente qui

Microsoft ha già rilasciato l’Azure DevOps MCP Server come public preview — quello è il server MCP stesso. La novità è l’integrazione con Foundry. Ora puoi aggiungere l’Azure DevOps MCP Server ai tuoi agenti Foundry direttamente dal catalogo degli strumenti.

Per chi non conosce ancora Foundry: è la piattaforma unificata di Microsoft per costruire e gestire applicazioni e agenti alimentati dall’IA su larga scala. Accesso ai modelli, orchestrazione, valutazione, deployment — tutto in un unico posto.

La configurazione

La configurazione è sorprendentemente semplice:

Nel tuo agente Foundry, vai su Add Tools > Catalog
Cerca “Azure DevOps”
Seleziona l’Azure DevOps MCP Server (preview) e clicca su Create
Inserisci il nome della tua organizzazione e connetti

Tutto qui. Il tuo agente ora ha accesso agli strumenti Azure DevOps.

Controllare a cosa può accedere il tuo agente

Questa è la parte che apprezzo: non sei bloccato con un approccio tutto-o-niente. Puoi specificare quali strumenti sono disponibili per il tuo agente. Quindi se vuoi che legga solo i work item ma non tocchi le pipeline, puoi configurarlo. Principio del minimo privilegio, applicato ai tuoi agenti IA.

Questo conta per gli scenari enterprise dove non vuoi che un agente attivi accidentalmente una pipeline di deployment perché qualcuno gli ha chiesto di “aiutare con il release.”

Perché è interessante per i team .NET

Pensa a cosa abilita nella pratica:

Assistenti per la pianificazione degli sprint — agenti che possono recuperare work item, analizzare dati di velocità e suggerire la capacità dello sprint
Bot di code review — agenti che capiscono il contesto della tua PR perché possono effettivamente leggere i tuoi repo e work item collegati
Risposta agli incidenti — agenti che possono creare work item, interrogare i deployment recenti e correlare bug con modifiche recenti
Onboarding degli sviluppatori — “Su cosa dovrei lavorare?” ottiene una risposta reale basata su dati reali del progetto

Per i team .NET che già usano Azure DevOps per le loro pipeline CI/CD e la gestione dei progetti, avere un agente IA che può interagire direttamente con questi sistemi è un passo significativo verso un’automazione utile.

Il quadro più ampio di MCP

Questo fa parte di una tendenza più ampia: i server MCP stanno diventando il modo standard in cui gli agenti IA interagiscono con il mondo esterno. Li vediamo per GitHub, Azure DevOps, database, API SaaS — e Foundry sta diventando l’hub dove tutte queste connessioni convergono.

Se stai costruendo agenti nell’ecosistema .NET, vale la pena tenere d’occhio MCP. Il protocollo è standardizzato, gli strumenti stanno maturando, e l’integrazione Foundry lo rende accessibile senza dover configurare manualmente le connessioni server.

Per concludere

L’Azure DevOps MCP Server in Foundry è in preview, quindi aspettati che si evolva. Ma il workflow principale è solido: connettere, configurare l’accesso agli strumenti e lasciare che i tuoi agenti lavorino con i tuoi dati DevOps. Se sei già nell’ecosistema Foundry, è a pochi clic. Provalo e vedi quali workflow puoi costruire.

Consulta l’annuncio completo per la configurazione passo per passo e maggiori dettagli.

Dal laptop alla produzione: deploy di agenti IA su Microsoft Foundry con due comandi

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

Conosci quel divario tra “funziona sulla mia macchina” e “è in produzione e serve traffico”? Per gli agenti IA, quel divario è stato dolorosamente ampio. Devi provisionare risorse, fare il deploy dei modelli, configurare l’identità, impostare il monitoraggio — e questo è prima che qualcuno possa effettivamente chiamare il tuo agente.

L’Azure Developer CLI ha appena reso tutto questo una questione di due comandi.

Il nuovo workflow `azd ai agent`

Lascia che ti mostri come funziona nella pratica. Hai un progetto di agente IA — diciamo un agente concierge d’hotel. Funziona in locale. Vuoi farlo girare su Microsoft Foundry.

azd ai agent init
azd up

Tutto qui. Due comandi. azd ai agent init genera l’infrastructure-as-code nel tuo repo, e azd up provisiona tutto su Azure e pubblica il tuo agente. Ottieni un link diretto al tuo agente nel portale Foundry.

Cosa succede sotto il cofano

Il comando init genera template Bicep reali e ispezionabili nel tuo repo:

Una Foundry Resource (contenitore di livello superiore)
Un Foundry Project (dove vive il tuo agente)
Configurazione del deployment del modello (GPT-4o, ecc.)
Managed Identity con assegnazioni di ruoli RBAC appropriate
azure.yaml per la mappa dei servizi
agent.yaml con metadati dell’agente e variabili d’ambiente

Il punto chiave: tutto questo è tuo. È Bicep versionato nel tuo repo. Puoi ispezionarlo, personalizzarlo e committarlo insieme al codice del tuo agente. Nessuna scatola nera magica.

Il ciclo interno di sviluppo

Quello che mi piace davvero è l’esperienza di sviluppo locale. Quando stai iterando sulla logica dell’agente, non vuoi fare il redeploy ogni volta che cambi un prompt:

azd ai agent run

Questo avvia il tuo agente in locale. Combinalo con azd ai agent invoke per inviare prompt di test, e hai un ciclo di feedback stretto. Modificare codice, riavviare, invocare, ripetere.

Il comando invoke è anche intelligente nel routing — quando un agente locale è in esecuzione, lo punta automaticamente. Quando non lo è, va all’endpoint remoto.

Monitoraggio in tempo reale

Questa è la funzionalità che mi ha convinto. Una volta che il tuo agente è in deploy:

azd ai agent monitor --follow

Ogni richiesta e risposta che passa attraverso il tuo agente viene trasmessa al tuo terminale in tempo reale. Per il debug di problemi in produzione, non ha prezzo. Niente ricerche in Log Analytics, niente attese per l’aggregazione delle metriche — vedi cosa sta succedendo adesso.

Il set completo dei comandi

Ecco il riferimento rapido:

Comando	Cosa fa
`azd ai agent init`	Scaffold di un progetto agente Foundry con IaC
`azd up`	Provisiona risorse Azure e fa il deploy dell’agente
`azd ai agent invoke`	Invia prompt all’agente remoto o locale
`azd ai agent run`	Esegue l’agente in locale per lo sviluppo
`azd ai agent monitor`	Streama log in tempo reale dall’agente pubblicato
`azd ai agent show`	Controlla salute e stato dell’agente
`azd down`	Pulisce tutte le risorse Azure

Perché è importante per gli sviluppatori .NET

Anche se l’esempio nell’annuncio è basato su Python, la storia dell’infrastruttura è language-agnostic. Il tuo agente .NET ottiene lo stesso scaffolding Bicep, lo stesso setup di managed identity, la stessa pipeline di monitoraggio. E se stai già usando azd per le tue app .NET Aspire o deployment Azure, si integra direttamente nel tuo workflow esistente.

Il divario di deployment per gli agenti IA è stato uno dei maggiori punti di attrito nell’ecosistema. Passare da un prototipo funzionante a un endpoint di produzione con identità, networking e monitoraggio appropriati non dovrebbe richiedere una settimana di lavoro DevOps. Ora richiede due comandi e qualche minuto.

Per concludere

azd ai agent è disponibile ora. Se hai rimandato il deployment dei tuoi agenti IA perché il setup dell’infrastruttura sembrava troppo lavoro, provalo. Consulta il walkthrough completo per la guida passo per passo inclusa l’integrazione di un’app chat frontend.

Foundry Agent Service è GA: Cosa conta davvero per chi costruisce agenti .NET

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

Siamo onesti — costruire un prototipo di agente IA è la parte facile. La parte difficile è tutto quello che viene dopo: metterlo in produzione con un adeguato isolamento di rete, eseguire valutazioni che significhino davvero qualcosa, gestire i requisiti di conformità e non rompere nulla alle 2 di notte.

Il Foundry Agent Service è appena andato in GA, e questo rilascio è focalizzato come un laser su quel gap del “tutto quello che viene dopo”.

Costruito sulla Responses API

Il titolo: il Foundry Agent Service di nuova generazione è costruito sulla OpenAI Responses API. Se stai già costruendo con quel wire protocol, migrare a Foundry richiede modifiche minime al codice. Cosa guadagni: sicurezza enterprise, networking privato, RBAC Entra, tracing completo e valutazione — sopra la tua logica di agente esistente.

L’architettura è intenzionalmente aperta. Non sei vincolato a un provider di modelli o a un framework di orchestrazione. Usa DeepSeek per la pianificazione, OpenAI per la generazione, LangGraph per l’orchestrazione — il runtime gestisce il livello di consistenza.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Networking privato: il bloccante enterprise rimosso

Questa è la funzionalità che sblocca l’adozione enterprise. Foundry ora supporta networking privato completo end-to-end con BYO VNet:

Nessun egress pubblico — il traffico dell’agente non tocca mai internet pubblico
Iniezione di container/subnet nella tua rete per comunicazione locale
Connettività degli strumenti inclusa — server MCP, Azure AI Search, agenti dati Fabric operano tutti su percorsi privati

L’ultimo punto è critico. Non sono solo le chiamate di inferenza a restare private — ogni invocazione di strumento e chiamata di retrieval resta anch’essa all’interno del perimetro della tua rete. Per i team che operano sotto policy di classificazione dei dati che vietano il routing esterno, questo era ciò che mancava.

Autenticazione MCP fatta bene

Le connessioni ai server MCP ora supportano l’intero spettro di pattern di autenticazione:

Metodo di auth	Quando usarlo
Basato su chiave	Accesso condiviso semplice per strumenti interni all’organizzazione
Entra Agent Identity	Servizio a servizio; l’agente si autentica come se stesso
Entra Managed Identity	Isolamento per progetto; nessuna gestione delle credenziali
OAuth Identity Passthrough	Accesso delegato dall’utente; l’agente agisce per conto degli utenti

OAuth Identity Passthrough è quello interessante. Quando gli utenti devono concedere a un agente l’accesso ai propri dati personali — il loro OneDrive, la loro organizzazione Salesforce, un’API SaaS con scope per utente — l’agente agisce per loro conto con flussi OAuth standard. Nessuna identità di sistema condivisa che finge di essere tutti.

Voice Live: voce a voce senza l’idraulica

Aggiungere la voce a un agente significava unire STT, LLM e TTS — tre servizi, tre hop di latenza, tre superfici di fatturazione, tutto sincronizzato a mano. Voice Live collassa tutto in una singola API gestita con:

Rilevamento semantico dell’attività vocale e del fine turno (capisce il significato, non solo il silenzio)
Soppressione del rumore e cancellazione dell’eco lato server
Supporto barge-in (gli utenti possono interrompere a metà risposta)

Le interazioni vocali passano attraverso lo stesso runtime dell’agente del testo. Stessi valutatori, stesse tracce, stessa visibilità dei costi. Per supporto clienti, servizio sul campo o scenari di accessibilità, questo sostituisce ciò che prima richiedeva una pipeline audio personalizzata.

Valutazioni: da checkbox a monitoraggio continuo

Qui è dove Foundry diventa serio sulla qualità in produzione. Il sistema di valutazione ora ha tre livelli:

Valutatori pronti all’uso — coerenza, rilevanza, fondatezza, qualità del retrieval, sicurezza. Connetti a un dataset o al traffico live e ottieni punteggi.
Valutatori personalizzati — codifica la tua logica di business, standard di tono e regole di conformità specifiche del dominio.
Valutazione continua — Foundry campiona il traffico di produzione live, esegue la tua suite di valutatori e mostra i risultati nei dashboard. Imposta alert di Azure Monitor per quando la fondatezza cala o le soglie di sicurezza vengono superate.

Tutto viene pubblicato in Azure Monitor Application Insights. Qualità dell’agente, salute dell’infrastruttura, costi e telemetria dell’applicazione — tutto in un unico posto.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Sei nuove regioni per agenti ospitati

Gli agenti ospitati sono ora disponibili in East US, North Central US, Sweden Central, Southeast Asia, Japan East e altre. Questo conta per i requisiti di residenza dei dati e per comprimere la latenza quando il tuo agente gira vicino alle sue fonti dati.

Perché è importante per gli sviluppatori .NET

Anche se gli esempi di codice nell’annuncio GA sono Python-first, l’infrastruttura sottostante è language-agnostic — e l’SDK .NET per azure-ai-projects segue gli stessi pattern. La Responses API, il framework di valutazione, il networking privato, l’auth MCP — tutto questo è disponibile da .NET.

Se stavi aspettando che gli agenti IA passassero da “demo cool” a “posso davvero consegnare questo al lavoro”, questo rilascio GA è il segnale. Networking privato, autenticazione adeguata, valutazione continua e monitoraggio di produzione sono i pezzi che mancavano.

Per concludere

Foundry Agent Service è disponibile ora. Installa l’SDK, apri il portale e inizia a costruire. La guida quickstart ti porta da zero a un agente funzionante in pochi minuti.

Per il deep-dive tecnico completo con tutti gli esempi di codice, consulta l’annuncio GA.

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.

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

Foundry Local 1.1: Trascrizione in Tempo Reale, Embeddings e l'API di Risposta

Trascrizione Audio in Diretta

Embeddings di Testo

API di Risposta

Miglioramenti alle Dimensioni del Pacchetto

Perché È Importante

Cosmos DB Shell È in Anteprima Pubblica — E Ha un Server MCP Integrato

Cosa lo Rende Diverso dalle Altre CLI di Database

La Base Open Source È Importante

Tre Scenari Che Diventano Più Semplici

Per Iniziare

Il Tuo Agente IA Ha un Problema di Identità (Ed Ecco il Template che lo Risolve)

Il Problema Principale: Autenticazione ≠ Autorizzazione

Come Funziona la Catena di Token

Cosa Distribuisce il Template

Il Principio di Design che Vale la Pena Adottare

Conclusione

Endpoint Privati, VNet, NSG — Aspire Gestisce la Rete Ora

I Blocchi di Costruzione

Descrivendolo nel tuo AppHost

Perché Questo è Importante per le Applicazioni Reali

Conclusione

Aspire 13.3: Supporto Kubernetes, Log del Browser e la Skill Aspireify

Aspireify: Onboarding Assistito da Agente

Deployment di Kubernetes e AKS di Prima Classe

Log del Browser nel Dashboard

Risultati dei Comandi Strutturati

Conclusione

SDD Conference 2026

Argomenti

Speaker

Biglietti e informazioni

Eliminare il Lavoro Ripetitivo della Migrazione con l'Agentic Platform Engineering

L’input: contoso-migration

Passo 1: Validazione e autenticazione

Passo 2: Estrazione dell’intenzione

Passo 3: Mappatura dei servizi

Passo 4: Agente critico

Passo 5: Output generato

Confronto della postura di sicurezza

Cosa lo differenzia da un convertitore di sintassi

SQL MCP Server su Azure App Service — Senza Container

Cos’è il SQL MCP Server?

Il Problema del Container (e la Soluzione)

Autenticazione Senza Chiavi API Condivise

Deploy su App Service

Perché Importa per gli Sviluppatori .NET

Conclusione

Azure MCP Server Ora è un .mcpb — Installalo senza Nessun Runtime

Cos’è un MCP Bundle?

Come installarlo

Cosa puoi fare

Per iniziare

Azure SDK Aprile 2026: AI Foundry 2.0 e Cosa Devono Sapere gli Sviluppatori .NET

Azure.AI.Projects 2.0.0 — Breaking Change che Hanno Senso

Cosmos DB Java: Correzione Critica di Sicurezza (RCE)

Nuove Librerie di Provisioning per .NET

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

Foundry Toolboxes: Un unico endpoint per tutti i tool degli agenti

Cos’è una Toolbox?

I quattro pilastri (due disponibili oggi)

Il Flusso di Deployment con `azd`