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.

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.

Microsoft-Foundry | The .NET Blog