Ai | The .NET Blog

NL2SQL è la SQL Injection dell'Era Agentiva

Emiliano Montesdeoca — Wed, 03 Jun 2026 00:00:00 +0000

C’è una versione del discorso su NL2SQL che suona perfetta: gli utenti fanno domande in linguaggio naturale, gli agenti generano SQL, i dati tornano. Meno schermate, meno query, meno codice. Semplice.

Poi ci pensi per altri cinque minuti.

I Problemi di cui Nessuno Parla nella Demo

Gli schemi non sono stati progettati per spiegare le cose. Nomi di tabelle criptici, nomi di colonne incoerenti, relazioni tecnicamente valide ma semanticamente invalide senza predicati aggiuntivi — questo è normale per i database aziendali. Non sono bug, sono semplicemente la storia accumulata dei cambiamenti di business. Ma quando chiedi a un modello di inferire l’intento da uno schema che non è stato progettato per comunicare l’intento, il modello ci proverà comunque. Non si arrenderà. Genererà la sua migliore query possibile e restituirà risultati con sicurezza.

I modelli non sono deterministici. Fai la stessa domanda sullo stesso database due volte e potresti ottenere SQL diverso. Il modello sta calcolando probabilità, e lievi variazioni nel contesto producono output diversi. Non puoi testare fino ad ottenere la garanzia che l’agente generi sempre la query corretta.

La revisione dell’utente non scala. “Basta rivedere ogni query prima dell’esecuzione” sembra sicuro. Ma presuppone che gli utenti siano esperti sia nel modello di dati che in SQL — esattamente le persone che non avevano bisogno dell’interfaccia in linguaggio naturale. Introduce anche sovraccarico cognitivo e una nuova classe di bias di conferma, dove gli utenti sopraffatti dalla complessità della query approvano query non valide invece di investigarle.

E poi c’è l’injection. Nello sviluppo SQL tradizionale, la parametrizzazione ha risolto l’injection perché l’input dell’utente riempiva i parametri, non la struttura SQL. Con NL2SQL, il modello genera il SQL stesso. Il prompt, il contesto dello schema, la cronologia della conversazione e i dati recuperati influenzano tutti ciò che viene eseguito. Se qualcuno elabora un prompt che cambia ciò che il modello genera, questa è injection — non a livello di parametro, ma a livello di generazione di query. E a differenza dell’eliminazione di una tabella (ovvio, recuperabile), l’injection NL2SQL produce query che restituiscono risultati errati senza errori visibili. Le decisioni aziendali vengono prese su dati sbagliati.

Cosa Risolve Realmente SQL MCP Server

È qui che l’articolo fa il suo punto pratico più utile. Invece di dare a un agente accesso arbitrario allo schema e sperare nel meglio, SQL MCP Server espone una superficie API curata costruita su Data API builder.

La differenza è importante: l’agente non genera SQL. Chiama endpoint denominati che restituiscono forme di risultato predefinite. Il SQL viene scritto una volta, da uno sviluppatore, ed è deterministico. Il non-determinismo dell’agente è limitato alla scelta di quale endpoint chiamare, non alla costruzione di query arbitrarie.

Questo è analogo a ciò che la parametrizzazione ha fatto per l’injection SQL nel modello di app tradizionale — rimuovi la capacità di costruire query arbitrarie dall’input non attendibile.

La Domanda Giusta

L’articolo non dice “non usare mai NL2SQL.” Dice: sii deliberato su dove lo applichi e cosa esponi. Per l’analisi esplorativa in un ambiente controllato, con uno schema limitato e accesso in sola lettura, NL2SQL potrebbe andare bene. Per i sistemi di produzione dove le decisioni aziendali dipendono dai risultati, un livello API curato è significativamente più sicuro.

Onestà: alcuni problemi si risolvono genuinamente meglio con query strutturate dietro endpoint denominati che con il linguaggio naturale verso SQL. SQL MCP Server ti dà questa opzione senza abbandonare completamente l’interfaccia agentiva.

Post originale: Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?

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

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

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

Foundry Local è Generalmente Disponibile

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

GPT-5.5

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

Tracing di Agent Framework in Foundry

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

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

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

CodeAct con Hyperlight (Alpha)

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

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

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

Dashboard di Monitoraggio degli Agenti (Anteprima)

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

Evaluator Personalizzati per la Valutazione Continua (Anteprima)

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

Inventario degli Agenti nel Piano di Controllo

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

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

Il Pattern Handoff: Quando Un Agente Non Basta

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

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

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

Come Funziona Handoff

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

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

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

Un Esempio Minimale

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

using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Workflows;

AIAgent triage = chatClient.AsAIAgent(
 instructions: "Route to the right specialist.",
 name: "Triage");

AIAgent billing = chatClient.AsAIAgent(
 instructions: "Handle billing questions.",
 name: "Billing");

AIAgent tech = chatClient.AsAIAgent(
 instructions: "Handle technical support.",
 name: "Tech");

var workflow = HandoffWorkflow.Create()
 .Add(triage, targets: [billing, tech])
 .Add(billing, targets: [triage])
 .Add(tech, targets: [triage, billing]);

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

Quando Usare Handoff (e Quando No)

Handoff è una buona scelta quando:

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

Non è la scelta giusta quando:

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

Bordi Posteriori e Human-in-the-Loop

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

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

Conclusione

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

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

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

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

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

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

I Blocchi Fondamentali

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

using Microsoft.Agents.AI.Workflows;

internal sealed class OrderLookup()
 : Executor<OrderCancelRequest, Order>("OrderLookup")
{
 public override async ValueTask<Order> HandleAsync(
 OrderCancelRequest message,
 IWorkflowContext context,
 CancellationToken cancellationToken = default)
 {
 // cercare l'ordine, restituirlo
 return new Order(Id: message.OrderId, ...);
 }
}

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

Puoi modellare:

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

Il Runner In-Memory per lo Sviluppo Locale

Iniziare è veloce:

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

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

Aggiungere Durabilità con Durable Task

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

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

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

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

Hosting Azure Functions

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

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

Perché Questo È Importante

La combinazione è significativa per i veri sistemi IA:

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

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

Post originale: Durable Workflows in the Microsoft Agent Framework

Il Tuo Agente MAF Locale Ha Appena Trovato Casa in Produzione

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

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

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

Cosa Fa Realmente Foundry Hosted Agents

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

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

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

La Differenza nel Codice È Minima

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

In .NET:

using Microsoft.Agents.AI.Foundry.Hosting;

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

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

app.Run();

In Python:

server = ResponsesHostServer(agent)
server.run()

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

Due Protocolli, Un Agente

Gli Hosted Agents supportano due stili di endpoint:

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

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

Il Flusso di Deployment con `azd`

Quando esegui azd up con un agente MAF:

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

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

Conclusione

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

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

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

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

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

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

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

Cosa Fa Davvero Ciascun Progetto

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

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

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

Layer diversi, copertura completa, una pipeline.

Integrarsi È Solo Aggiungere Middleware

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

agent = Agent(
 client=OpenAIChatClient(model="gpt-5.3"),
 name="Contoso Loan Officer",
 instructions="You are a governed loan assistant.",
 tools=[check_credit_score, get_loan_rates, approve_small_loan],
 middleware=[
 AuditTrailMiddleware(audit_log=audit_log, agent_did="loan-agent"),
 GovernancePolicyMiddleware(evaluator=evaluator, audit_log=audit_log),
 CapabilityGuardMiddleware(allowed_tools=["check_credit_score", "get_loan_rates"]),
 RogueDetectionMiddleware(detector=detector, agent_id="loan-agent"),
 ],
)

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

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

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

Cosa Ottieni

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

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

Cinque Scenari di Settore

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

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

Conclusione

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

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

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

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

Azure SQL Può Ora Generare Embedding — In T-SQL Puro, Senza Livello Applicativo

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

Se hai mai costruito una pipeline RAG, conosci la tassa della pipeline: i tuoi dati vivono in SQL, ma per generare embedding devi estrarli, chiamare un’API di embedding, gestire il batching e i limiti di velocità, e archiviare i risultati da qualche parte con ricerca vettoriale. Spesso in un database completamente diverso.

Azure SQL ha appena eliminato la maggior parte di questo con due funzionalità ora generalmente disponibili: CREATE EXTERNAL MODEL e AI_GENERATE_EMBEDDINGS.

Cosa Fanno

Queste due funzionalità T-SQL lavorano come una pipeline integrata:

CREATE EXTERNAL MODEL — registra un endpoint di modello AI esterno come oggetto di database con nome. Imposti la posizione, il formato API, il tipo di modello e le credenziali una volta sola. Riutilizzalo ovunque.

AI_GENERATE_EMBEDDINGS — una funzione T-SQL scalare che chiama il modello registrato e restituisce un array JSON di valori vettoriali. Funziona nelle istruzioni SELECT, INSERT, UPDATE e MERGE.

Insieme formano una pipeline di embedding end-to-end senza lasciare il motore SQL.

Il Flusso di Lavoro Completo

-- Passo 1: Registra il tuo fornitore di embedding una volta
CREATE EXTERNAL MODEL MyEmbeddingModel
WITH (
 LOCATION = 'https://your-aoai-resource.openai.azure.com/',
 API_FORMAT = 'Azure OpenAI',
 MODEL_TYPE = EMBEDDINGS,
 MODEL = 'text-embedding-ada-002'
);

-- Passo 2: Genera embedding inline in T-SQL
UPDATE docs
SET embedding = AI_GENERATE_EMBEDDINGS(content USE MODEL MyEmbeddingModel)
FROM documents AS docs;

-- Passo 3: Cerca con la distanza vettoriale
SELECT TOP 10 id, content
FROM documents
ORDER BY VECTOR_DISTANCE('cosine', embedding,
 AI_GENERATE_EMBEDDINGS(@query USE MODEL MyEmbeddingModel));

Questa è l’intera pipeline: dati in SQL, embedding generati in SQL, ricerca per similarità in SQL. Nessun livello di orchestrazione, nessun ETL, nessun database vettoriale separato.

Formati API e Opzioni Supportate

In GA, API_FORMAT supporta Azure OpenAI e OpenAI. MODEL_TYPE è bloccato su EMBEDDINGS per ora. Il JSON PARAMETERS consente di impostare valori predefiniti a livello di modello incluso il conteggio dei tentativi:

PARAMETERS = '{"sql_rest_options":{"retry_count":3}}'

L’autenticazione usa le credenziali del database, quindi i segreti rimangono fuori dal codice dell’applicazione.

Cosa Questo Abilita per le Applicazioni .NET

Per gli sviluppatori .NET che costruiscono funzionalità AI su dati SQL esistenti, questo è significativo. Non hai bisogno di:

Estrarre dati in un archivio intermedio per gli embedding
Gestire una pipeline di embedding esterna
Configurare un database vettoriale separato (anche se puoi usare Azure AI Search se vuoi un archivio vettoriale completo)
Modificare il livello di accesso ai dati della tua applicazione

Puoi aggiungere la ricerca semantica alle applicazioni SQL esistenti in modo incrementale, usando gli stessi strumenti T-SQL che hai già.

Conclusione

I pattern RAG sui dati SQL sono diventati drammaticamente più semplici. AI_GENERATE_EMBEDDINGS + CREATE EXTERNAL MODEL significa che la tua applicazione SQL esistente può acquisire capacità di ricerca vettoriale senza aggiungere nuova infrastruttura.

Entrambe le funzionalità sono in GA in Azure SQL Database e Azure SQL Managed Instance oggi.

Post originale: Generate Embeddings Function and External Model Object Support Are Now Generally Available in Azure SQL

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

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.

Costruire un'app per conferenze con IA con lo stack componibile di .NET

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

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

Costruire un’app per conferenze con IA con lo stack componibile di .NET — Microsoft ha costruito ConferencePulse, un’app Blazor Server per sessioni di conferenza live, combinando cinque librerie di estensione .NET. È stata utilizzata all’MVP Summit.

Cosa fa ConferencePulse

ConferencePulse funziona durante le sessioni live e fornisce: sondaggi generati dall’IA dal contenuto della sessione, Q&A del pubblico con una pipeline RAG che attinge da una knowledge base live, insight generati automaticamente e riepiloghi delle sessioni prodotti da più agenti IA concorrenti. Lo stack è .NET 10, Blazor Server, Aspire, suddiviso in cinque progetti: Web, Core, Ingestion, Agents, Mcp e AppHost.

Microsoft.Extensions.AI: un’astrazione per tutto

IChatClient è l’astrazione unificata — si configura una volta e la stessa interfaccia funziona per Azure OpenAI, OpenAI, Anthropic o qualsiasi altro provider. Sei righe per ottenere un client completamente configurato con invocazione di funzioni, tracciamento OpenTelemetry e middleware di logging:

services.AddChatClient(new AzureOpenAIClient(...).GetChatClient("gpt-4o"))
 .UseFunctionInvocation()
 .UseOpenTelemetry()
 .UseLogging();

Lo stesso IChatClient viene riutilizzato in seguito per il passaggio di arricchimento dell’ingestion dei dati — nessun client separato necessario per questo.

Pipeline DataIngestion

Il contenuto della sessione scorre attraverso una pipeline: MarkdownReader → HeaderChunker (500 token, 50 token di sovrapposizione) → SummaryEnricher + KeywordEnricher → VectorStoreWriter (Qdrant). Gli arricchitori usano lo stesso IChatClient per generare riepiloghi ed estrarre parole chiave prima dell’indicizzazione. Le domande del pubblico, le coppie Q&A e i risultati dei sondaggi vengono inseriti in tempo reale man mano che la sessione avanza — la knowledge base cresce durante il talk.

VectorData: ricerca indipendente dal provider

VectorStoreCollection.SearchAsync() funziona allo stesso modo sia che il backing store sia Qdrant o Azure AI Search. La ricerca ibrida (vettore + testo completo) è supportata. La pipeline RAG per il Q&A del pubblico interroga questa collezione e riceve i chunk rilevanti da passare come contesto al client di chat.

MCP: contenuto della sessione come strumenti

Il contenuto della sessione è esposto tramite MCP in modo che qualsiasi client compatibile con MCP possa accedervi. Sia il server che il client sono implementati — il server espone la conoscenza della sessione come strumenti MCP, e il client consente di chiamare questi strumenti dall’interno della pipeline dell’agente.

Agent Framework: riepilogo multi-agente in parallelo

Il riepilogo della sessione viene generato da tre agenti che eseguono in modo concorrente — PollSummaryAgent, QuestionSummaryAgent e InsightSummaryAgent — poi uniti. Questo utilizza il pattern di group chat o esecuzione parallela di Microsoft Agent Framework. Ogni agente gestisce una preoccupazione; l’orchestratore unisce gli output.

Il principio di progettazione

Il post fa un punto degno di nota: usa lo strumento più semplice che si adatta. Chiamate dirette a IChatClient per semplici attività di generazione. Chiamata di strumento/funzione per l’estrazione di dati strutturati. Agenti completi solo quando si necessita di ragionamento autonomo multi-step. La stratificazione delle librerie lo impone — è possibile usare Microsoft.Extensions.AI senza includere l’Agent Framework completo.

Consulta il post completo per la struttura completa del progetto e i link al codice sorgente.

Microsoft Agent Framework Parte 3: Dagli Strumenti ai Workflow — I Mattoni si Incastrano

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

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

Se hai seguito la serie Building Blocks for AI in .NET, sai che la Parte 1 ci ha dato IChatClient (l’interfaccia universale dei modelli) e la Parte 2 Microsoft.Extensions.VectorData (ricerca semantica e RAG). Entrambi sono fondamentali e utili da soli. Ma è qui che tutto inizia a connettersi.

La Parte 3 riguarda il Microsoft Agent Framework — e onestamente, è il pezzo che stavo aspettando di vedere arrivare in .NET. La versione 1.0 è uscita ad aprile. L’API è stabile. È ora di costruire agenti veri.

Cos’è un Agente (vs. un Chatbot)

Prima di immergerci nel codice, chiariamo questa distinzione. Un chatbot riceve input, chiama un modello, restituisce output. Loop semplice.

Un agente ha autonomia. Può ragionare su un compito, decidere quali strumenti usare, chiamarli, valutare i risultati e decidere cosa fare dopo — tutto senza che tu scriva logica passo-passo per ogni scenario. Gli dai strumenti e istruzioni, e lui si occupa dell’orchestrazione.

Pensaci così: IChatClient è come avere una conversazione. Un agente è come delegare una lista di compiti a qualcuno.

Il Tuo Primo Agente in 10 Righe

dotnet add package Microsoft.Agents.AI

AIAgent agent = new AzureOpenAIClient(
 new Uri(endpoint),
 new DefaultAzureCredential())
 .GetChatClient(deploymentName)
 .AsAIAgent(
 instructions: "You are good at telling jokes.",
 name: "Joker");

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate."));

Il metodo di estensione .AsAIAgent() è il ponte. Stesso pattern di .AsIChatClient() da MEAI — avvolge l’SDK del provider in un’astrazione stabile. Funziona con Azure OpenAI, OpenAI, GitHub Models, Microsoft Foundry o modelli locali.

Lo streaming funziona anche:

await foreach (var update in agent.RunStreamingAsync("Tell me a joke about a pirate."))
{
 Console.Write(update);
}

Dare Strumenti all’Agente

È qui che gli agenti smettono di essere chatbot sofisticati. Gli strumenti sono funzioni che il modello può decidere di chiamare in base a ciò che l’utente chiede. Nessuna logica di routing da parte tua — il modello lo capisce da solo.

[Description("Get the weather for a given location.")]
static string GetWeather(
 [Description("The location to get the weather for.")] string location)
 => $"The weather in {location} is cloudy with a high of 15°C.";

AIAgent agent = chatClient.AsAIAgent(
 instructions: "You are a helpful assistant",
 tools: [AIFunctionFactory.Create(GetWeather)]);

Due cose da notare. Primo, AIFunctionFactory viene da MEAI — la stessa tool factory che useresti con un IChatClient normale. Se hai già definito strumenti per scenari di chat, funzionano qui anche.

Secondo, gli attributi Description sono molto importanti. È così che il modello capisce cosa fa uno strumento e quando usarlo. Trattali come documentazione per la tua IA, non per gli umani.

Sessioni: Conversazioni con Memoria Vera

AgentSession session = await agent.CreateSessionAsync();

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate.", session));

Console.WriteLine(await agent.RunAsync(
 "Now add some emojis and tell it in the voice of a pirate's parrot.",
 session));

Senza sessione, ogni chiamata a RunAsync è stateless. Con una sessione, l’agente sa a quale barzelletta ti riferisci. AgentSession preserva la cronologia della conversazione tra i turni.

Per servizi stateless in produzione, le sessioni si serializzano in modo pulito:

JsonElement sessionState = await agent.SerializeSessionAsync(session);
// ... conservalo da qualche parte ...
var restoredSession = await agent.DeserializeSessionAsync(sessionState);
Console.WriteLine(await agent.RunAsync("What were we just talking about?", restoredSession));

Questo è fondamentale se il tuo agente gira in un ambiente serverless o con scaling orizzontale.

AIContextProvider: Memoria Persistente tra le Sessioni

Le sessioni preservano la cronologia all’interno di una sessione. Ma che dire del conoscere cose su un utente tra sessioni diverse? AIContextProvider gestisce questo.

Ha due hook:

ProvideAIContextAsync — viene eseguito prima di ogni interazione, inietta contesto nell’agente
StoreAIContextAsync — viene eseguito dopo ogni interazione, permette di apprendere e persistere

Il pattern è elegante: puoi impilare più provider — uno per le preferenze utente, uno per le interazioni recenti, uno che interroga il tuo store VectorData per documenti rilevanti. Quest’ultimo è esattamente il pattern RAG della Parte 2, ora eseguito automaticamente ad ogni chiamata all’agente.

Workflow Multi-Agente

È qui che il framework guadagna il suo nome. Include un sistema di workflow basato su grafi dove gli executor (agenti, funzioni, qualsiasi cosa) si connettono tramite archi.

Alcuni pattern supportati nativamente:

Sequenziale: L’output dell’Agente A alimenta l’Agente B
Concorrente (fan-out/fan-in): Dispatcha a più agenti in parallelo, raccoglie risultati
Routing condizionale: Instrada il lavoro ad agenti diversi in base all’output
Loop scrittore-critico: Un agente scrive, un altro valuta, loop fino all’approvazione
Sub-workflow: Compone workflow gerarchicamente

Un esempio scrittore-critico:

WorkflowBuilder builder = new(writerAgent);
builder
 .AddEdge(writerAgent, criticAgent)
 .AddEdge(criticAgent, writerAgent, condition: result => !result.IsApproved)
 .WithOutputFrom(criticAgent, condition: result => result.IsApproved);
var workflow = builder.Build();

Pulito, leggibile, e il routing basato su condizioni significa che non scrivi la logica del loop tu stesso.

Human-in-the-Loop

Non tutto dovrebbe girare in modo completamente autonomo. Per operazioni sensibili — scritture su database, transazioni finanziarie, invio di comunicazioni — vuoi che un umano approvi prima che l’agente esegua.

Il framework ha supporto integrato per questo tramite FunctionApprovalRequestContent e FunctionApprovalResponseContent. L’agente propone la chiamata allo strumento, il tuo codice applicativo la presenta all’utente, e la risposta determina se l’esecuzione procede.

Questo è il modo giusto di pensare agli agenti in contesti aziendali: non completamente autonomi, ma autonomia con guardrail.

Il Quadro Completo

Se fai un passo indietro:

MEAI ti dà un’interfaccia universale per qualsiasi modello
VectorData dà ai tuoi agenti accesso alla conoscenza della tua organizzazione tramite ricerca semantica
Agent Framework orchestra tutto — usa IChatClient internamente, si compone con context provider, e coordina tramite workflow

Ogni pezzo è stato progettato per comporsi con gli altri. Consulta il post originale di Jeremy Likness e il repository GitHub dell’Agent Framework per gli esempi completi.

Conclusione

Il post Parte 3 del Microsoft Agent Framework chiude il cerchio della serie Building Blocks. Per gli sviluppatori .NET che vogliono costruire agenti AI — non solo chatbot, ma agenti veri che usano strumenti, ricordano cose e coordinano — questo è il percorso.

La versione stabile 1.0 significa che puoi costruire con questo in produzione. Se stavi aspettando di tuffarti nello sviluppo di agenti in .NET, il momento è adesso.

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.

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

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

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

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

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

Cos’è CodeAct?

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

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

La componente di sicurezza: Micro-VM Hyperlight

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

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

Configurazione minima

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

Quando usare CodeAct (e quando no)

Usa CodeAct quando:

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

Resta con il tool-calling tradizionale quando:

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

Provalo ora

pip install agent-framework-hyperlight --pre

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

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

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

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

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

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

Due pattern fondamentali

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

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

Come Agent Framework astrae questo

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

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

Riferimento rapido ai provider

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

Come scegliere

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

Leggi il post completo per l’albero decisionale completo.

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

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

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

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

La progressione di GPT-5

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

Cosa è cambiato davvero

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

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

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

Prezzi

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

Perché Foundry è importante

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

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

Consulta l’annuncio completo per tutti i dettagli.

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.

Windows App Dev CLI v0.3: F5 dal terminale e UI Automation per gli agenti

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

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

L’esperienza F5 di Visual Studio è fantastica. Ma dover aprire VS solo per avviare e fare debug di un’app Windows pacchettizzata è eccessivo — che si tratti di una pipeline CI, di un workflow automatizzato o di un agente AI che esegue i test.

Windows App Development CLI v0.3 è appena uscita e lo affronta direttamente con due funzionalità principali: winapp run e winapp ui.

winapp run: F5 da qualsiasi posto

winapp run prende una cartella di app non pacchettizzata e un manifesto, e fa tutto ciò che VS fa nel debug launch: registra un pacchetto loose, avvia l’app e preserva il LocalState tra i re-deploy.

# Compila l'app, poi avviala come app pacchettizzata
winapp run ./bin/Debug

Funziona per WinUI, WPF, WinForms, Console, Avalonia e altro. Le modalità sono pensate per sviluppatori e workflow automatizzati:

--detach: Avvia e restituisce il controllo al terminale immediatamente. Perfetto per CI.
--unregister-on-exit: Pulisce il pacchetto registrato alla chiusura dell’app.
--debug-output: Cattura i messaggi OutputDebugString e le eccezioni in tempo reale.

Nuovo pacchetto NuGet: dotnet run per le app pacchettizzate

Per gli sviluppatori .NET c’è un nuovo pacchetto NuGet: Microsoft.Windows.SDK.BuildTools.WinApp. Dopo l’installazione, dotnet run gestisce tutto l’inner loop: build, preparare un pacchetto loose-layout, registrare su Windows e avviare — tutto in un unico step.

winapp init
# o
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui: UI Automation dalla riga di comando

Questa è la funzionalità che apre gli scenari agentici. winapp ui fornisce accesso completo UI Automation a qualsiasi app Windows in esecuzione — WPF, WinForms, Win32, Electron, WinUI3 — direttamente dal terminale.

Cosa si può fare:

Elencare tutte le finestre di primo livello
Navigare l’albero completo di UI Automation di una finestra
Cercare elementi per nome, tipo o ID di automazione
Cliccare, invocare e impostare valori
Fare screenshot
Attendere la comparsa di elementi — ideale per la sincronizzazione dei test

Combinare winapp ui con winapp run crea un workflow completo build → avvio → verifica dal terminale. Un agente può eseguire l’app, ispezionare lo stato dell’UI e validare il risultato.

Altre novità

winapp unregister: Rimuove un pacchetto sideloaded quando si è finito.
winapp manifest add-alias: Aggiunge un alias per avviare l’app per nome dal terminale.
Tab completion: Configura il completamento PowerShell con un singolo comando.

Come ottenerlo

winget install Microsoft.WinAppCli
# o
npm install -g @microsoft/winappcli

La CLI è in preview pubblica. Il repository su GitHub ha la documentazione completa e l’annuncio originale ha tutti i dettagli.

VS Code 1.117: Gli Agent Stanno Ottenendo i Propri Branch Git e Io Sono Tutto a Favore

Emiliano Montesdeoca — Sun, 19 Apr 2026 00:00:00 +0000

La linea tra “assistente IA” e “compagno di squadra IA” continua ad assottigliarsi. VS Code 1.117 è appena uscito e le note di rilascio complete sono piene, ma la storia è chiara: gli agent stanno diventando cittadini di prima classe nel tuo workflow di sviluppo.

Ecco cosa conta davvero.

La modalità Autopilot finalmente ricorda la tua preferenza

Prima, dovevi riattivare Autopilot ogni volta che iniziavi una nuova sessione. Fastidioso. Ora la tua modalità di permessi persiste tra le sessioni, e puoi configurare il valore predefinito.

L’Agent Host supporta tre configurazioni di sessione:

Default — gli strumenti chiedono conferma prima di eseguire
Bypass — approva tutto automaticamente
Autopilot — completamente autonomo, risponde alle proprie domande e va avanti

Se stai creando un nuovo progetto .NET con migrazioni, Docker e CI — impostalo su Autopilot una volta e dimenticatene. Quella preferenza resta.

Worktree e isolamento git per le sessioni degli agent

Questa è la grande novità. Le sessioni degli agent ora supportano l’isolamento completo con worktree e git. Questo significa che quando un agent lavora su un task, ottiene il proprio branch e la propria directory di lavoro. Il tuo branch principale resta intatto.

Ancora meglio — Copilot CLI genera nomi di branch significativi per queste sessioni worktree. Basta con agent-session-abc123. Ottieni qualcosa che descrive davvero cosa sta facendo l’agent.

Per gli sviluppatori .NET che gestiscono più feature branch o correggono bug mentre un lungo task di scaffolding è in esecuzione, questo è un punto di svolta. Puoi avere un agent che costruisce i tuoi controller API in un worktree mentre tu fai debug di un problema nel service layer in un altro. Nessun conflitto. Nessun stashing. Nessun casino.

Subagent e team di agent

L’Agent Host Protocol ora supporta i subagent. Un agent può avviare altri agent per gestire parti di un task. Pensalo come delegare — il tuo agent principale coordina, e agent specializzati si occupano dei pezzi.

Siamo ancora all’inizio, ma il potenziale per i workflow .NET è ovvio. Immagina un agent che gestisce le tue migrazioni EF Core mentre un altro configura i tuoi test di integrazione. Non siamo ancora completamente lì, ma il fatto che il supporto al protocollo arrivi ora significa che gli strumenti seguiranno velocemente.

L’output del terminale incluso automaticamente quando gli agent inviano input

Piccolo ma significativo. Quando un agent invia input al terminale, l’output del terminale viene ora automaticamente incluso nel contesto. Prima, l’agent doveva fare un turno extra solo per leggere cosa era successo.

Se hai mai visto un agent eseguire dotnet build, fallire, e poi fare un altro giro solo per vedere l’errore — quella frizione è sparita. Vede l’output immediatamente e reagisce.

L’app Agents su macOS si aggiorna automaticamente

L’app standalone Agents su macOS ora si aggiorna automaticamente. Basta scaricare manualmente nuove versioni. Resta semplicemente aggiornata.

Le cose più piccole che vale la pena sapere

Gli hover su package.json ora mostrano sia la versione installata che l’ultima disponibile. Utile se gestisci strumenti npm insieme ai tuoi progetti .NET.
Le immagini nei commenti JSDoc vengono renderizzate correttamente negli hover e nei completamenti.
Le sessioni Copilot CLI ora indicano se sono state create da VS Code o esternamente — comodo quando salti tra i terminali.
Copilot CLI, Claude Code e Gemini CLI sono riconosciuti come tipi di shell. L’editor sa cosa stai eseguendo.

Il punto chiave

VS Code 1.117 non è un dump di feature appariscenti. È infrastruttura. Isolamento con worktree, permessi persistenti, protocolli per subagent — questi sono i mattoni per un workflow dove gli agent gestiscono task reali e paralleli senza pestare il tuo codice.

Se stai sviluppando con .NET e non ti sei ancora buttato nel workflow agentico, onestamente, ora è il momento di iniziare.

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.

Docker Sandbox permette agli agenti Copilot di refactorizzare il codice senza mettere a rischio la tua macchina

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

Se hai usato la modalità agente di Copilot per qualcosa di più di piccole modifiche, conosci il dolore. Ogni scrittura di file, ogni comando nel terminale — un altro prompt di permessi. Ora immagina di farlo su 50 progetti. Non è divertente.

Il team di Azure ha appena pubblicato un post su Docker Sandbox per gli agenti di GitHub Copilot, e onestamente, è uno dei miglioramenti più pratici che abbia mai visto nel tooling agentico. Utilizza microVM per dare a Copilot un ambiente completamente isolato dove può fare di tutto — installare pacchetti, eseguire build, lanciare test — senza toccare il tuo sistema host.

Cosa ti offre realmente Docker Sandbox

L’idea di base è semplice: avviare una microVM leggera con un ambiente Linux completo, sincronizzare il tuo workspace al suo interno e lasciare che l’agente Copilot operi liberamente dentro. Quando ha finito, le modifiche vengono sincronizzate indietro.

Ecco cosa lo rende più di un semplice “eseguire roba in un container”:

Sincronizzazione bidirezionale del workspace che preserva i percorsi assoluti. La struttura del tuo progetto appare identica dentro la sandbox. Nessun fallimento di build legato ai percorsi.
Docker daemon privato in esecuzione dentro la microVM. L’agente può costruire ed eseguire container senza mai montare il socket Docker del tuo host. Questo è un grande vantaggio per la sicurezza.
Proxy di filtraggio HTTP/HTTPS che controllano cosa l’agente può raggiungere sulla rete. Tu decidi quali registry ed endpoint sono consentiti. Attacchi alla supply chain da un npm install malevolo nella sandbox? Bloccati.
Modalità YOLO — sì, la chiamano proprio così. L’agente gira senza prompt di permessi perché letteralmente non può danneggiare il tuo host. Ogni azione distruttiva è contenuta.

Perché gli sviluppatori .NET dovrebbero interessarsi

Pensa al lavoro di modernizzazione che così tanti team stanno affrontando in questo momento. Hai una soluzione .NET Framework con 30 progetti e devi migrarla a .NET 9. Sono centinaia di modifiche ai file — file di progetto, aggiornamenti dei namespace, sostituzioni di API, migrazioni NuGet.

Con Docker Sandbox, puoi puntare un agente Copilot su un progetto, lasciarlo refactorizzare liberamente dentro la microVM, eseguire dotnet build e dotnet test per validare, e accettare solo le modifiche che funzionano davvero. Nessun rischio che distrugga accidentalmente il tuo ambiente di sviluppo locale mentre sperimenta.

Il post descrive anche l’esecuzione di una flotta di agenti paralleli — ognuno nella propria sandbox — che lavorano su diversi progetti contemporaneamente. Per soluzioni .NET di grandi dimensioni o architetture a microservizi, questo è un enorme risparmio di tempo. Un agente per servizio, tutti in esecuzione isolata, tutti validati indipendentemente.

L’aspetto sicurezza conta

Ecco il punto che la maggior parte delle persone trascura: quando lasci che un agente IA esegua comandi arbitrari, gli stai affidando l’intera macchina. Docker Sandbox ribalta questo modello. L’agente ottiene piena autonomia in un ambiente usa e getta. Il proxy di rete assicura che possa scaricare solo da fonti approvate. Il tuo filesystem host, il Docker daemon e le tue credenziali restano intatti.

Per i team con requisiti di compliance — e questo vale per la maggior parte delle aziende .NET — questa è la differenza tra “non possiamo usare l’IA agentica” e “possiamo adottarla in sicurezza.”

Conclusione

Docker Sandbox risolve la tensione fondamentale del coding agentico: gli agenti hanno bisogno di libertà per essere utili, ma la libertà sulla tua macchina host è pericolosa. Le microVM ti danno entrambe le cose. Se stai pianificando qualsiasi refactoring o modernizzazione .NET su larga scala, vale la pena configurarlo ora. La combinazione dell’intelligenza di codice di Copilot con un ambiente di esecuzione sicuro è esattamente ciò che i team di produzione stavano aspettando.

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

.NET Aspire 13.2 Vuole Essere il Migliore Amico del Tuo Agente IA

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

Conosci quel momento in cui il tuo agente IA scrive del codice solido, ti entusiasmi, e poi tutto crolla quando prova a eseguire la cosa? Conflitti di porte, processi fantasma, variabili d’ambiente sbagliate — improvvisamente il tuo agente sta bruciando token per risolvere problemi di avvio invece di costruire funzionalità.

Il team di Aspire ha appena pubblicato un post molto ben pensato su esattamente questo problema, e la loro risposta è convincente: Aspire 13.2 è progettato non solo per gli umani, ma per gli agenti IA.

Il problema è reale

Gli agenti IA sono incredibili nello scrivere codice. Ma consegnare un’app full-stack funzionante richiede molto di più che generare file. Devi avviare i servizi nell’ordine giusto, gestire le porte, impostare le variabili d’ambiente, connettere i database e ottenere feedback quando qualcosa si rompe. Al momento, la maggior parte degli agenti gestisce tutto questo per tentativi — eseguendo comandi, leggendo output di errore, riprovando.

Aggiungiamo istruzioni Markdown, skill personalizzati e prompt per guidarli, ma sono imprevedibili, non possono essere compilati e costano token solo per essere parsati. Il team di Aspire ha centrato l’insight chiave: gli agenti hanno bisogno di compilatori e API strutturate, non di più Markdown.

Aspire come infrastruttura per agenti

Ecco cosa porta Aspire 13.2 al tavolo dello sviluppo agentico:

Tutto il tuo stack in codice tipizzato. L’AppHost definisce la tua topologia completa — API, frontend, database, cache — in TypeScript o C# compilabile:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

Un agente può leggere questo per capire la topologia dell’app, aggiungere risorse, collegare connessioni e compilare per verificare. Il compilatore gli dice immediatamente se qualcosa è sbagliato. Niente congetture, niente tentativi con i file di configurazione.

Un solo comando per governarli tutti. Invece di far destreggiate gli agenti tra docker compose up, npm run dev e script di avvio database, tutto è semplicemente aspire start. Tutte le risorse si avviano nell’ordine giusto, sulle porte giuste, con la configurazione giusta. I processi a lunga durata non bloccano l’agente — Aspire li gestisce.

Modalità isolata per agenti paralleli. Con --isolated, ogni esecuzione di Aspire ottiene le proprie porte casuali e segreti utente separati. Hai più agenti che lavorano su git worktree? Non entreranno in collisione. Questo è enorme per strumenti come gli agenti in background di VS Code che creano ambienti paralleli.

Occhi da agente attraverso la telemetria. Qui diventa davvero potente. La CLI di Aspire espone dati OpenTelemetry completi durante lo sviluppo — tracce, metriche, log strutturati. Il tuo agente non sta solo leggendo l’output della console sperando per il meglio. Può tracciare una richiesta fallita tra i servizi, profilare endpoint lenti e individuare esattamente dove le cose si rompono. Questa è osservabilità di livello produzione nel ciclo di sviluppo.

L’analogia dei parabordi del bowling

Il team di Aspire usa un’ottima analogia: pensa ad Aspire come ai parabordi della pista da bowling per gli agenti IA. Se l’agente non è perfetto (e non lo sarà), i parabordi impediscono che tiri nel canale. La definizione dello stack previene la misconfigurazioni, il compilatore cattura gli errori, la CLI gestisce i processi e la telemetria fornisce il ciclo di feedback.

Combina questo con qualcosa come Playwright CLI, e il tuo agente può davvero usare la tua app — cliccando nei flussi, controllando il DOM, vedendo le cose rotte nella telemetria, sistemando il codice, riavviando e testando di nuovo. Costruire, eseguire, osservare, sistemare. Questo è il ciclo di sviluppo autonomo che stavamo inseguendo.

Per iniziare

Nuovo con Aspire? Installa la CLI da get.aspire.dev e segui la guida introduttiva.

Già usi Aspire? Esegui aspire update --self per ottenere la 13.2, poi punta il tuo agente di coding preferito al tuo repo. Potresti stupirti di quanto va più lontano con i guardrail di Aspire.

Per concludere

Aspire 13.2 non è più solo un framework per app distribuite — sta diventando infrastruttura essenziale per agenti. Definizioni di stack strutturate, avvio con un comando, esecuzioni parallele isolate e telemetria in tempo reale danno agli agenti IA esattamente ciò di cui hanno bisogno per passare dallo scrivere codice al consegnare app.

Leggi il post completo dal team di Aspire per tutti i dettagli e i video dimostrativi.

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.

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

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

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

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

Cosa sono le MCP Apps?

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

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

La Fluent API in tre passaggi

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

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

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

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

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

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

La superficie dell’API è ben progettata

Alcune cose che mi piacciono molto:

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

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

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

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

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

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

Per iniziare

Aggiungi il pacchetto preview:

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

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

Conclusione

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

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

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.

VS Code 1.115 — Notifiche del Terminale in Background, Modalità Agente SSH e Altro

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

VS Code 1.115 è appena uscito, e sebbene sia un rilascio più leggero in termini di funzionalità principali, i miglioramenti relativi agli agenti sono genuinamente utili se lavori quotidianamente con assistenti di codice basati su IA.

Lasciami evidenziare cosa vale davvero la pena sapere.

I terminali in background comunicano con gli agenti

Questa è la funzionalità di punta. I terminali in background ora notificano automaticamente gli agenti quando i comandi vengono completati, inclusi il codice di uscita e l’output del terminale. I prompt di input nei terminali in background vengono anche rilevati e mostrati all’utente.

Perché è importante? Se hai usato la modalità agente di Copilot per eseguire comandi di build o suite di test in background, conosci il dolore del “ma è già finito?” — i terminali in background erano essenzialmente spara-e-dimentica. Ora l’agente viene notificato quando il tuo dotnet build o dotnet test è completato, vede l’output e può reagire di conseguenza. È un piccolo cambiamento che rende i flussi di lavoro guidati dagli agenti significativamente più affidabili.

C’è anche un nuovo strumento send_to_terminal che permette agli agenti di inviare comandi ai terminali in background con conferma dell’utente, risolvendo il problema dove run_in_terminal con un timeout spostava i terminali in background e li rendeva di sola lettura.

Hosting remoto di agenti tramite SSH

VS Code ora supporta la connessione a macchine remote tramite SSH, installando automaticamente la CLI e avviandola in modalità host di agenti. Questo significa che le tue sessioni di agenti IA possono puntare direttamente ad ambienti remoti — utile per gli sviluppatori .NET che compilano e testano su server Linux o VM nel cloud.

Tracciamento delle modifiche nelle sessioni degli agenti

Le modifiche ai file effettuate durante le sessioni degli agenti ora vengono tracciate e ripristinate, con diff, annulla/ripristina e ripristino dello stato. Se un agente apporta modifiche al tuo codice e qualcosa va storto, puoi vedere esattamente cosa è cambiato e fare il rollback. Tranquillità nel lasciare che gli agenti modifichino la tua codebase.

Riconoscimento delle schede del browser e altri miglioramenti

Alcune aggiunte aggiuntive per la qualità della vita:

Tracciamento delle schede del browser — la chat ora può tracciare e collegare le schede del browser aperte durante una sessione, così gli agenti possono fare riferimento alle pagine web che stai guardando
Incolla file nel terminale — incolla file (incluse immagini) nel terminale con Ctrl+V, trascinamento o clic destro
Copertura dei test nella minimap — gli indicatori di copertura dei test ora appaiono nella minimap per una panoramica visiva rapida
Pinch-to-zoom su Mac — il browser integrato supporta i gesti pinch-to-zoom
Diritti Copilot nelle Sessioni — la barra di stato mostra le informazioni di utilizzo nella vista Sessioni
Favicon in Vai al File — le pagine web aperte mostrano le favicon nella lista di selezione rapida

Per concludere

VS Code 1.115 è un rilascio incrementale, ma i miglioramenti degli agenti — notifiche del terminale in background, hosting di agenti SSH e tracciamento delle modifiche — si sommano a un’esperienza notevolmente più fluida per lo sviluppo assistito dall’IA. Se stai usando la modalità agente di Copilot per progetti .NET, questi sono il tipo di miglioramenti di qualità della vita che riducono l’attrito quotidiano.

Dai un’occhiata alle note di rilascio complete per ogni dettaglio.

Aspire 13.2 include una CLI per la documentazione — e anche il tuo agente IA può usarla

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

Conosci quel momento in cui sei immerso in un Aspire AppHost, stai collegando integrazioni, e devi controllare esattamente quali parametri si aspetta l’integrazione Redis? Fai alt-tab al browser, cerchi su aspire.dev, strizzi gli occhi sulla documentazione delle API, poi torni al tuo editor. Contesto perso. Flusso interrotto.

Aspire 13.2 ha appena rilasciato una soluzione per questo. La CLI aspire docs ti permette di cercare, esplorare e leggere la documentazione ufficiale di Aspire direttamente dal tuo terminale. E siccome è supportata da servizi riutilizzabili, gli agenti IA e le skill possono usare gli stessi comandi per consultare la documentazione invece di allucinare API che non esistono.

Il problema che questo risolve davvero

David Pine lo dice perfettamente nel post originale: gli agenti IA erano terribili nell’aiutare gli sviluppatori a costruire app con Aspire. Raccomandavano dotnet run invece di aspire run, facevano riferimento a learn.microsoft.com per docs che vivono su aspire.dev, suggerivano pacchetti NuGet obsoleti, e — il mio preferito — allucinavano API inesistenti.

Perché? Perché Aspire è stato specifico per .NET molto più a lungo di quanto sia stato poliglotta, e i LLM lavorano con dati di addestramento che precedono le ultime funzionalità. Quando dai a un agente IA la possibilità di consultare la documentazione attuale, smette di tirare a indovinare e inizia a essere utile.

Tre comandi, zero schede del browser

La CLI è di una semplicità rinfrescante:

Elencare tutta la documentazione

aspire docs list

Restituisce ogni pagina di documentazione disponibile su aspire.dev. Serve un output leggibile dalle macchine? Aggiungi --format Json.

Cercare un argomento

aspire docs search "redis"

Cerca sia nei titoli che nei contenuti con punteggio di rilevanza ponderato. Lo stesso motore di ricerca che alimenta internamente gli strumenti di documentazione. Ottieni risultati classificati con titoli, slug e punteggi di rilevanza.

Leggere una pagina intera (o solo una sezione)

aspire docs get redis-integration

Trasmette la pagina completa in markdown nel tuo terminale. Ti serve solo una sezione?

aspire docs get redis-integration --section "Add Redis resource"

Precisione chirurgica. Niente scrolling su 500 righe. Solo la parte che ti serve.

L’aspetto agente IA

Ecco dove diventa interessante per noi sviluppatori che costruiamo con strumenti IA. Gli stessi comandi aspire docs funzionano come strumenti per agenti IA — tramite skill, server MCP, o semplici wrapper CLI.

Invece di far inventare al tuo assistente IA delle API Aspire basate su dati di addestramento obsoleti, può chiamare aspire docs search "postgres", trovare la documentazione ufficiale dell’integrazione, leggere la pagina giusta, e darti l’approccio documentato. Documentazione in tempo reale e aggiornata — non quello che il modello ha memorizzato sei mesi fa.

L’architettura dietro tutto questo è intenzionale. Il team Aspire ha costruito servizi riutilizzabili (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) anziché un’integrazione una tantum. Questo significa che lo stesso motore di ricerca funziona per gli umani nel terminale, gli agenti IA nel tuo editor, e l’automazione nella tua pipeline CI.

Scenari reali

Consultazioni rapide nel terminale: Sei tre file in profondità e hai bisogno dei parametri di configurazione Redis. Due comandi, novanta secondi, di nuovo al lavoro:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

Sviluppo assistito dall’IA: La tua skill di VS Code avvolge i comandi CLI. Chiedi “Aggiungi un database PostgreSQL al mio AppHost” e l’agente consulta i docs reali prima di rispondere. Nessuna allucinazione.

Validazione CI/CD: La tua pipeline valida le configurazioni AppHost contro la documentazione ufficiale in modo programmatico. L’output --format Json si collega in modo pulito a jq e altri strumenti.

Basi di conoscenza personalizzate: Stai costruendo i tuoi strumenti IA? Invia l’output JSON strutturato direttamente nella tua base di conoscenza:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Niente web scraping. Niente chiavi API. Gli stessi dati strutturati usati internamente dagli strumenti di documentazione.

La documentazione è sempre aggiornata

Questa è la parte che apprezzo di più. La CLI non scarica uno snapshot — interroga aspire.dev con caching basato su ETag. Nel momento in cui la documentazione viene aggiornata, la tua CLI e qualsiasi skill costruita su di essa lo riflette. Niente copie obsolete, niente momenti “ma il wiki diceva…”.

Per concludere

aspire docs è una di quelle piccole funzionalità che risolve un problema reale in modo pulito. Gli umani ottengono accesso alla documentazione nativo nel terminale. Gli agenti IA ottengono un modo per smettere di indovinare e iniziare a fare riferimento a docs reali. E tutto è supportato dalla stessa fonte di verità.

Se stai costruendo con .NET Aspire e non hai ancora provato la CLI, esegui aspire docs search "il-tuo-argomento-qui" e vedi come ti sembra. Poi considera di integrare quei comandi nella skill IA o nella configurazione di automazione che stai usando — i tuoi agenti ti ringrazieranno.

Dai un’occhiata all’approfondimento di David Pine su come sono nati gli strumenti di documentazione, e al riferimento ufficiale della CLI per tutti i dettagli.

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

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

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

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

La versione breve

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

Iniziare è quasi ingiustamente semplice

Ecco un agente funzionante in .NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

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

Orchestrazione multi-agente — questa è la cosa seria

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

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

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

Le funzionalità che contano di più

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

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

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

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

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

Le funzionalità in preview da tenere d’occhio

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

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

Migrazione da Semantic Kernel o AutoGen

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

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

Per concludere

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

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

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

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.

L'aggiornamento di marzo di Visual Studio permette di creare agenti Copilot personalizzati — e find_symbol è rivoluzionario

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

Visual Studio ha appena ricevuto il suo aggiornamento Copilot più significativo. Mark Downie ha annunciato il rilascio di marzo, e il titolo sono gli agenti personalizzati — ma onestamente, lo strumento find_symbol potrebbe essere la funzionalità che cambia di più il tuo workflow.

Agenti Copilot personalizzati nel tuo repo

Vuoi che Copilot segua gli standard del tuo team? Gli agenti personalizzati sono definiti come file .agent.md in .github/agents/. Ogni agente ha accesso completo al workspace, comprensione del codice, strumenti, il tuo modello preferito e connessioni MCP.

Agent skill: pacchetti di istruzioni riutilizzabili

Le skill vengono caricate automaticamente da .github/skills/ nel tuo repo o ~/.copilot/skills/ nel tuo profilo.

find_symbol: navigazione consapevole del linguaggio

Il nuovo strumento find_symbol dà alla modalità agente di Copilot una navigazione dei simboli basata sui servizi di linguaggio. Invece di cercare testo, l’agente può trovare tutti i riferimenti di un simbolo e accedere a informazioni su tipi e scope.

Per gli sviluppatori .NET, è un miglioramento enorme — i codebase C# con gerarchie di tipi profonde ne beneficiano enormemente.

Profilare test con Copilot

C’è un nuovo Profile with Copilot nel menu contestuale del Test Explorer. Il Profiling Agent esegue il test e analizza le performance automaticamente.

Perf tip durante il debug dal vivo

L’ottimizzazione delle performance ora avviene durante il debug. Visual Studio mostra il tempo di esecuzione inline. Linea lenta? Clicca sul Perf Tip e chiedi a Copilot suggerimenti.

Correggere vulnerabilità NuGet dal Solution Explorer

Un link Fix with GitHub Copilot appare direttamente nel Solution Explorer quando viene rilevata una vulnerabilità.

Per concludere

Agenti personalizzati e skill fanno il titolo, ma find_symbol è la gemma nascosta — cambia fondamentalmente la precisione di Copilot nel refactoring di codice .NET. Scarica Visual Studio 2026 Insiders per provare tutto.

La Dashboard di Aspire 13.2 ora ha un'API di telemetria — e cambia tutto

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

Se hai sviluppato applicazioni distribuite con .NET Aspire, sai già che la dashboard è la cosa migliore dell’intera esperienza. Tutti i tuoi trace, log e metriche in un unico posto — niente Jaeger esterno, niente configurazione di Seq, niente momenti “fammi controllare l’altro terminale”.

Aspire 13.2 ha appena migliorato tutto significativamente. James Newton-King ha annunciato l’aggiornamento, e onestamente? Le funzionalità di esportazione telemetria e l’API da sole giustificano l’upgrade.

Esportare telemetria come una persona normale

Ecco lo scenario che abbiamo vissuto tutti: stai debuggando un problema distribuito, finalmente lo riproduci dopo venti minuti di setup, e ora devi condividere con il team quello che è successo. Prima? Screenshot. Copia e incolla degli ID delle trace. Il solito caos.

Aspire 13.2 aggiunge un dialog Gestisci log e telemetria dove puoi:

Pulire tutta la telemetria (utile prima di un tentativo di riproduzione)
Esportare telemetria selezionata in un file ZIP nel formato standard OTLP/JSON
Re-importare quel ZIP in qualsiasi dashboard Aspire successivamente

Quest’ultimo punto è la funzionalità killer. Riproduci un bug, esporti la telemetria, la alleghi al tuo work item, e il tuo collega può importarla nella propria dashboard per vedere esattamente quello che hai visto tu. Niente più “riesci a riprodurlo sulla tua macchina?”

Trace, span e log individuali hanno anche un’opzione “Export JSON” nei menu contestuali. Devi condividere una trace specifica? Click destro, copia JSON, incolla nella descrizione della PR. Fatto.

L’API di telemetria è il vero punto di svolta

Questo è ciò che mi entusiasma di più. La dashboard ora espone un’API HTTP sotto /api/telemetry per interrogare i dati di telemetria programmaticamente. Endpoint disponibili:

GET /api/telemetry/resources — elencare risorse con telemetria
GET /api/telemetry/spans — interrogare span con filtri
GET /api/telemetry/logs — interrogare log con filtri
GET /api/telemetry/traces — elencare trace
GET /api/telemetry/traces/{traceId} — ottenere tutti gli span per una trace specifica

Tutto torna in formato OTLP JSON. Questo alimenta i nuovi comandi CLI aspire agent mcp e aspire otel, ma l’implicazione reale è più grande: ora puoi costruire strumenti, script e integrazioni con agenti IA che interrogano direttamente la telemetria della tua app.

Immagina un agente IA che può vedere le tue trace distribuite reali durante il debug. Non è più ipotetico — è ciò che questa API rende possibile.

La telemetria GenAI diventa pratica

Se stai costruendo app con IA usando Semantic Kernel o Microsoft.Extensions.AI, apprezzerai il visualizzatore di telemetria GenAI migliorato. Aspire 13.2 aggiunge:

Descrizioni degli strumenti IA renderizzate come Markdown
Un pulsante GenAI dedicato nella pagina delle trace per accesso rapido
Migliore gestione errori per JSON GenAI troncato o non standard
Navigazione click-to-highlight tra le definizioni degli strumenti

Il post menziona che VS Code Copilot chat, Copilot CLI e OpenCode supportano tutti la configurazione di un OTEL_EXPORTER_OTLP_ENDPOINT. Puntali alla dashboard Aspire e puoi letteralmente guardare i tuoi agenti IA pensare in tempo reale attraverso la telemetria. Questa è un’esperienza di debug che non troverai da nessun’altra parte.

Per concludere

Aspire 13.2 trasforma la dashboard da “bella UI di debug” a “piattaforma di osservabilità programmabile”. Il flusso di esportazione/importazione da solo fa risparmiare tempo reale nel debug distribuito, e l’API di telemetria apre la porta alla diagnostica assistita dall’IA.

Se sei già su Aspire, aggiorna. Se no — questa è una buona ragione per dare un’occhiata a aspire.dev.

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.

VS Code 1.112: Cosa dovrebbe davvero interessare agli sviluppatori .NET

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

VS Code 1.112 è appena atterrato, e onestamente? Questo colpisce diversamente se passi le tue giornate nel mondo .NET. C’è molto nelle note di rilascio ufficiali, ma lascia che ti risparmi un po’ di scrolling e mi concentri su quello che conta davvero per noi.

Copilot CLI è diventato molto più utile

Il grande tema di questo rilascio è l’autonomia dell’agente — dare a Copilot più spazio per fare il suo lavoro senza che tu supervisioni ogni passo.

Steering e coda dei messaggi

Conosci quel momento in cui Copilot CLI è a metà di un task e ti rendi conto che hai dimenticato di menzionare qualcosa? Prima, dovevi aspettare. Ora puoi inviare messaggi mentre una richiesta è ancora in corso — sia per dirigere la risposta corrente che per mettere in coda istruzioni di follow-up.

Questo è enorme per quei task di scaffolding dotnet più lunghi dove stai guardando Copilot configurare un progetto e pensi “oh aspetta, mi serve anche MassTransit lì dentro.”

Livelli di permessi

Questo è quello che mi entusiasma di più. Le sessioni Copilot CLI ora supportano tre livelli di permessi:

Permessi predefiniti — il flusso solito dove gli strumenti chiedono conferma prima di eseguire
Bypass approvazioni — auto-approva tutto e riprova in caso di errore
Autopilota — completamente autonomo: approva strumenti, risponde alle proprie domande e continua finché il task non è completo

Se stai facendo qualcosa come creare una nuova API ASP.NET Core con Entity Framework, migrazioni e Docker setup — la modalità Autopilota significa che descrivi quello che vuoi e vai a prendere un caffè. Lo capirà da solo.

Puoi abilitare l’Autopilota con l’impostazione chat.autopilot.enabled.

Anteprima delle modifiche prima della delega

Quando deleghi un task a Copilot CLI, crea un worktree. Prima, se avevi modifiche non committate, dovevi controllare il Source Control per vedere cosa sarebbe stato influenzato. Ora la vista Chat mostra le modifiche pendenti proprio lì prima che tu decida se copiarle, spostarle o ignorarle.

Piccola cosa, ma ti salva da quel momento “aspetta, cosa avevo in staging?”

Debug delle web app senza lasciare VS Code

Il browser integrato ora supporta il debugging completo. Puoi impostare breakpoint, fare step through del codice e ispezionare variabili — tutto dentro VS Code. Basta passare a Edge DevTools.

C’è un nuovo tipo di debug editor-browser, e se hai già configurazioni di lancio msedge o chrome esistenti, migrare è semplice come cambiare il campo type nel tuo launch.json:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Per gli sviluppatori Blazor, questo è un game changer. Stai già eseguendo dotnet watch nel terminale — ora anche il tuo debugging resta nella stessa finestra.

Il browser ha anche ottenuto livelli di zoom indipendenti (finalmente), menu contestuali con clic destro appropriati, e lo zoom viene ricordato per sito web.

Sandboxing dei server MCP

Questo conta più di quanto potresti pensare. Se usi server MCP — magari ne hai configurato uno personalizzato per le tue risorse Azure o query al database — giravano con gli stessi permessi del tuo processo VS Code. Questo significa accesso completo al tuo filesystem, rete, tutto.

Ora puoi metterli in sandbox. Nel tuo mcp.json:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

Quando un server sandboxato ha bisogno di accedere a qualcosa che non ha, VS Code ti chiede di concedere il permesso. Molto meglio dell’approccio “speriamo che nessuno faccia nulla di strano”.

Scoperta delle personalizzazioni nei monorepo

Se lavori in un monorepo (e siamo onesti, molte soluzioni .NET enterprise finiscono per diventarne uno), questo risolve un vero punto dolente.

Prima, se aprivi una sottocartella del tuo repo, VS Code non trovava il tuo copilot-instructions.md, AGENTS.md o skills personalizzati alla radice del repository. Ora con l’impostazione chat.useCustomizationsInParentRepositories, risale fino alla radice .git e scopre tutto.

Questo significa che il tuo team può condividere istruzioni per agenti, file di prompt e strumenti personalizzati tra tutti i progetti in un monorepo senza che tutti debbano aprire la cartella radice.

/troubleshoot per il debugging degli agenti

Hai mai configurato istruzioni personalizzate o skills e ti sei chiesto perché non vengono rilevati? Il nuovo skill /troubleshoot legge i log di debug dell’agente e ti dice cosa è successo — quali strumenti sono stati usati o saltati, perché le istruzioni non sono state caricate, e cosa sta causando risposte lente.

Abilitalo con:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

Poi scrivi semplicemente /troubleshoot why is my custom skill not loading? nella chat.

Puoi anche esportare e importare questi log di debug ora, il che è ottimo per condividerli con il team quando qualcosa non funziona come previsto.

Supporto file immagine e binari

Gli agenti possono ora leggere file immagine dal disco e file binari nativamente. I file binari vengono presentati in formato hexdump, e gli output delle immagini (come screenshot dal browser integrato) appaiono in una vista carousel.

Per gli sviluppatori .NET, pensa: incolla uno screenshot di un bug UI nella chat e fai capire all’agente cosa c’è che non va, o fagli analizzare l’output del rendering di un componente Blazor.

Riferimenti automatici ai simboli

Piccolo miglioramento di qualità della vita: quando copi il nome di un simbolo (una classe, metodo, ecc.) e lo incolli nella chat, VS Code ora lo converte automaticamente in un riferimento #sym:Name. Questo dà all’agente il contesto completo su quel simbolo senza che tu debba aggiungerlo manualmente.

Se vuoi testo semplice, usa Ctrl+Shift+V.

I plugin possono ora essere abilitati/disabilitati

Prima, disabilitare un server MCP o plugin significava disinstallarlo. Ora puoi attivarli e disattivarli — sia globalmente che per workspace. Clic destro nella vista Estensioni o nella vista Personalizzazioni e hai fatto.

I plugin da npm e pypi possono anche auto-aggiornarsi ora, anche se chiederanno approvazione prima poiché gli aggiornamenti significano eseguire nuovo codice sulla tua macchina.

Per concludere

VS Code 1.112 sta chiaramente spingendo forte sull’esperienza agent — più autonomia, debugging migliore, sicurezza più stretta. Per gli sviluppatori .NET, il debugging del browser integrato e i miglioramenti di Copilot CLI sono le funzionalità di punta.

Se non hai ancora provato a eseguire una sessione completa di Copilot CLI in modalità Autopilota per un progetto .NET, questo rilascio è un buon momento per iniziare. Ricorda solo di impostare i tuoi permessi e lasciare cuocere.

Scarica VS Code 1.112 o aggiorna dall’interno di VS Code tramite Aiuto > Controlla aggiornamenti.

Ai | The .NET Blog

NL2SQL è la SQL Injection dell'Era Agentiva

I Problemi di cui Nessuno Parla nella Demo

Cosa Risolve Realmente SQL MCP Server

La Domanda Giusta

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

Foundry Local è Generalmente Disponibile

GPT-5.5

Tracing di Agent Framework in Foundry

CodeAct con Hyperlight (Alpha)

Dashboard di Monitoraggio degli Agenti (Anteprima)

Evaluator Personalizzati per la Valutazione Continua (Anteprima)

Inventario degli Agenti nel Piano di Controllo

Il Pattern Handoff: Quando Un Agente Non Basta

Come Funziona Handoff

Un Esempio Minimale

Quando Usare Handoff (e Quando No)

Bordi Posteriori e Human-in-the-Loop

Conclusione

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

I Blocchi Fondamentali

Il Runner In-Memory per lo Sviluppo Locale

Aggiungere Durabilità con Durable Task

Hosting Azure Functions

Perché Questo È Importante

Il Tuo Agente MAF Locale Ha Appena Trovato Casa in Produzione

Cosa Fa Realmente Foundry Hosted Agents

La Differenza nel Codice È Minima

Due Protocolli, Un Agente

Il Flusso di Deployment con azd

Conclusione

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

Cosa Fa Davvero Ciascun Progetto

Integrarsi È Solo Aggiungere Middleware

Cosa Ottieni

Cinque Scenari di Settore

Conclusione

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

Azure SQL Può Ora Generare Embedding — In T-SQL Puro, Senza Livello Applicativo

Cosa Fanno

Il Flusso di Lavoro Completo

Formati API e Opzioni Supportate

Cosa Questo Abilita per le Applicazioni .NET

Conclusione

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

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

Costruire un'app per conferenze con IA con lo stack componibile di .NET

Cosa fa ConferencePulse

Microsoft.Extensions.AI: un’astrazione per tutto

Pipeline DataIngestion

VectorData: ricerca indipendente dal provider

MCP: contenuto della sessione come strumenti

Agent Framework: riepilogo multi-agente in parallelo

Il principio di progettazione

Microsoft Agent Framework Parte 3: Dagli Strumenti ai Workflow — I Mattoni si Incastrano

Cos’è un Agente (vs. un Chatbot)

Il Flusso di Deployment con `azd`