Agents | 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?

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

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.

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.

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

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

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.

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

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

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

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.

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

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

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

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

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

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

Cosa fa Git-APE concretamente

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

Ecco il setup:

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

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

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

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

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

Perché è importante

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

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

La pulizia è altrettanto semplice:

@git-ape destroy my-resource-group

La mia opinione

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

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

Per concludere

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

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

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.

VS Code 1.116 — L'App Agents Ottiene Navigazione da Tastiera e Completamenti per il Contesto dei File

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

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

VS Code 1.116 è il rilascio di aprile 2026, e sebbene sia più leggero di alcuni aggiornamenti recenti, i cambiamenti sono mirati e significativi — specialmente se usate l’app Agents quotidianamente.

Ecco cosa è arrivato, in base alle note di rilascio ufficiali.

Miglioramenti dell’app Agents

L’app Agents continua a maturare con un polishing dell’usabilità che fa una vera differenza nei flussi di lavoro quotidiani:

Scorciatoie da tastiera dedicate — ora potete mettere a fuoco la vista Changes, l’albero dei file all’interno di Changes e la vista delle Personalizzazioni della Chat con comandi e scorciatoie da tastiera dedicati. Se cliccavate ovunque nell’app Agents per navigare, questo porta flussi di lavoro completamente controllabili da tastiera.

Dialogo di aiuto per l’accessibilità — premere Alt+F1 nella casella di input della chat ora apre un dialogo di aiuto per l’accessibilità che mostra i comandi e le scorciatoie disponibili. Gli utenti di screen reader possono anche controllare la verbosità degli annunci. Una buona accessibilità beneficia tutti.

Completamenti per il contesto dei file — digitate # nella chat dell’app Agents per attivare i completamenti per il contesto dei file limitati al vostro workspace corrente. Questa è una di quelle piccole migliorie della qualità della vita che velocizzano ogni interazione — niente più percorsi completi dei file quando si referenzia il codice.

Risoluzione dei link CSS `@import`

Ottimo per gli sviluppatori frontend: VS Code ora risolve i riferimenti CSS @import che usano percorsi di node_modules. Potete fare Ctrl+clic attraverso import come @import "some-module/style.css" quando usate bundler. Piccolo ma elimina un punto di attrito nei workflow CSS.

Conclusione

VS Code 1.116 riguarda il raffinamento — rendere l’app Agents più navigabile, più accessibile e più amichevole con la tastiera. Se passate molto tempo nell’app Agents (e sospetto che molti di noi lo facciano), questi cambiamenti si sommano.

Consultate le note di rilascio complete per l’elenco completo.

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

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

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.

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.

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

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

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

Cos’è CodeAct?

La componente di sicurezza: Micro-VM Hyperlight

Configurazione minima

Quando usare CodeAct (e quando no)

Provalo ora

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

Due pattern fondamentali

Come Agent Framework astrae questo

Riferimento rapido ai provider

Come scegliere

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

Cos’è una Toolbox?

I quattro pilastri (due disponibili oggi)

Esempio pratico

Nessun lock-in con Foundry Agents

Perché è importante adesso

Conclusione

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

La modalità Autopilot finalmente ricorda la tua preferenza

Worktree e isolamento git per le sessioni degli agent

Subagent e team di agent

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

L’app Agents su macOS si aggiorna automaticamente

Le cose più piccole che vale la pena sapere

Il punto chiave

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

Le sei opzioni a colpo d’occhio

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

Il deploy è genuinamente semplice

Gestione conversazioni integrata

Il mio framework decisionale

Per concludere

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

Che cos’è Azure MCP Server?

Il grande affare: deployment remoti self-hosted

Hardening della sicurezza

Dove puoi usarlo?

Perché questo conta per gli sviluppatori .NET

Per iniziare

Per concludere

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

Cosa fa Git-APE concretamente

Perché è importante

La mia opinione

Per concludere

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

VS Code 1.116 — L'App Agents Ottiene Navigazione da Tastiera e Completamenti per il Contesto dei File

Miglioramenti dell’app Agents

Risoluzione dei link CSS @import

Conclusione

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

Eseguire e debuggare agenti IA senza deploy

GitHub Copilot configura il tuo progetto azd

Container App Jobs e miglioramenti del deployment

Miglioramenti DX

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

Risoluzione dei link CSS `@import`