Foundry | The .NET Blog

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

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

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

Foundry Local è Generalmente Disponibile

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

GPT-5.5

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

Tracing di Agent Framework in Foundry

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

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

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

CodeAct con Hyperlight (Alpha)

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

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

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

Dashboard di Monitoraggio degli Agenti (Anteprima)

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

Evaluator Personalizzati per la Valutazione Continua (Anteprima)

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

Inventario degli Agenti nel Piano di Controllo

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

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

Il Tuo Agente MAF Locale Ha Appena Trovato Casa in Produzione

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

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

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

Cosa Fa Realmente Foundry Hosted Agents

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

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

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

La Differenza nel Codice È Minima

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

In .NET:

using Microsoft.Agents.AI.Foundry.Hosting;

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

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

app.Run();

In Python:

server = ResponsesHostServer(agent)
server.run()

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

Due Protocolli, Un Agente

Gli Hosted Agents supportano due stili di endpoint:

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

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

Il Flusso di Deployment con `azd`

Quando esegui azd up con un agente MAF:

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

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

Conclusione

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

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

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

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

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

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

Trascrizione Audio in Diretta

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

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

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

Embeddings di Testo

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

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

API di Risposta

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

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

Miglioramenti alle Dimensioni del Pacchetto

Due modifiche riducono la dimensione del pacchetto JavaScript:

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

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

Perché È Importante

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

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

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

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

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.

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

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

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

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.

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

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

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

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

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

Perché questa combinazione ha senso

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

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

Opzioni di autenticazione

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

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

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

Configurazione

Il flusso generale:

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

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

La mia opinione

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

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

Conclusione

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

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

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

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

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.

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)

Se vieni dal pacchetto azure-ai-agents, gli agenti sono ora operazioni di prima classe su AIProjectClient in azure-ai-projects. Rimuovi la dipendenza standalone e usa get_openai_client() per gestire le risposte.

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.

Foundry | The .NET Blog

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

Foundry Local è Generalmente Disponibile

GPT-5.5

Tracing di Agent Framework in Foundry

CodeAct con Hyperlight (Alpha)

Dashboard di Monitoraggio degli Agenti (Anteprima)

Evaluator Personalizzati per la Valutazione Continua (Anteprima)

Inventario degli Agenti nel Piano di Controllo

Il Tuo Agente MAF Locale Ha Appena Trovato Casa in Produzione

Cosa Fa Realmente Foundry Hosted Agents

La Differenza nel Codice È Minima

Due Protocolli, Un Agente

Il Flusso di Deployment con azd

Conclusione

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

Trascrizione Audio in Diretta

Embeddings di Testo

API di Risposta

Miglioramenti alle Dimensioni del Pacchetto

Perché È Importante

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

La progressione di GPT-5

Cosa è cambiato davvero

Prezzi

Perché Foundry è importante

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

Addestramento Globale per o4-mini

Nuovi Valutatori di Modello: Famiglia GPT-4.1

La Trappola del Formato Dati RFT

Perché Questo È Importante per gli Sviluppatori .NET

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

Perché questa combinazione ha senso

Opzioni di autenticazione

Configurazione

La mia opinione

Conclusione

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

Foundry Agent Service è pronto per la produzione

GPT-5.4 — affidabilità oltre l’intelligenza pura

L’SDK è finalmente stabile

Fireworks AI porta i modelli aperti su Azure

Altri punti salienti

Conclusione

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

Cosa sta succedendo realmente qui

La configurazione

Controllare a cosa può accedere il tuo agente

Perché è interessante per i team .NET

Il quadro più ampio di MCP

Per concludere

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

Il nuovo workflow azd ai agent

Cosa succede sotto il cofano

Il ciclo interno di sviluppo

Monitoraggio in tempo reale

Il set completo dei comandi

Perché è importante per gli sviluppatori .NET

Per concludere

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

Costruito sulla Responses API

Networking privato: il bloccante enterprise rimosso

Autenticazione MCP fatta bene

Voice Live: voce a voce senza l’idraulica

Valutazioni: da checkbox a monitoraggio continuo

Sei nuove regioni per agenti ospitati

Perché è importante per gli sviluppatori .NET

Per concludere

Il Flusso di Deployment con `azd`

Il nuovo workflow `azd ai agent`