Un agente diventa utile quando smette di parlare e agisce: interroga un indice, chiama un’API di fatturazione, esegue codice, delega un pezzo di lavoro a un altro agente. Ogni capacità porta una domanda di progettazione — quale strumento, quale identità, quale autorizzazione — e una di rischio: cosa succede se il modello sbaglia e lo strumento è distruttivo.

Il catalogo degli strumenti e i criteri di scelta

Gli strumenti si dividono per tipo di problema. Per le API esistenti hai il tool OpenAPI, che legge una spec 3.0 o 3.1 con autenticazione anonima, API key o managed identity, e il tool MCP, che punta a un server Model Context Protocol remoto. Per la conoscenza hai file search su vector store (chunking ed embedding automatici, con stato di readiness e policy di scadenza), il tool Azure AI Search per interrogare un tuo indice e rispondere con citazioni, e Foundry IQ come knowledge base riutilizzabile e permission-aware. Il tool Azure AI Search vuole la connessione di progetto e il nome dell’indice; query_type va da simple a vector_semantic_hybrid, che è il default, e le citazioni tornano come annotazioni url_citation, quindi l’indice deve avere un campo recuperabile con l’URL di origine.

Per la ricerca web il criterio è esplicito: parti da Web Search, che non richiede risorse Azure aggiuntive; Grounding with Bing Search serve per parametri come freshness o market e per modelli non OpenAI venduti da Azure; Bing Custom Search (preview) restringe a domini definiti da te. In ogni caso i dati escono dal perimetro di conformità di Azure e questi strumenti ignorano VPN e private endpoint.

Restano il code interpreter, che esegue Python in sandbox sui file caricati, e le funzioni custom, l’unico strumento eseguito lato client. Azure Content Understanding non compare fra gli strumenti collegabili direttamente: lo si usa a monte, in ingestione, per ricavare da documenti, immagini e video una rappresentazione pulita da indicizzare, oppure lo si espone dietro un tool OpenAPI o una funzione.

Toolbox: gli strumenti smettono di essere un problema per agente

Quando gli agenti si moltiplicano, ogni team ricollega gli stessi strumenti con credenziali proprie. Il toolbox risolve questo: raccogli gli strumenti una volta e Foundry li espone dietro un unico endpoint compatibile MCP, con autenticazione centralizzata (Entra e OAuth identity passthrough, credenziali fuori dal codice dell’agente), guardrail a livello di toolbox e versioning. Crei una versione, la testi, la promuovi a default: gli agenti la prendono senza essere ridistribuiti. Un toolbox non è vincolato a Foundry: qualunque runtime MCP-compatibile può consumarlo.

Due funzionalità esistono solo nel toolbox: tool search (preview), che nasconde gli strumenti ed espone i due meta-strumenti tool_search e call_tool, così centinaia di strumenti non saturano il contesto né peggiorano la selezione, e le skills (preview), workflow multi-passo versionati e immutabili che definiscono come si esegue un compito.

Più agenti: quando conviene davvero

Un secondo agente si giustifica quando il lavoro si divide in flussi indipendenti e delimitati, quando contesti separati migliorano la messa a fuoco, quando l’esplorazione parallela riduce il tempo di attesa. Resta meglio un solo agente quando ogni passo dipende dal precedente, quando il compito è breve, quando gli agenti si contenderebbero la stessa risorsa mutabile o quando serve un grafo di esecuzione deterministico. E i sottoagenti aumentano il consumo di token.

Le strade sono tre. L’orchestrazione multi-agente della Responses API (preview) lascia che un agente radice, chiamato /root, crei sottoagenti in parallelo e ne riconcili i risultati; le azioni di collaborazione appaiono come item multi_agent_call gestiti dal servizio, che la tua applicazione non deve eseguire, mentre le function_call restano a carico tuo anche quando provengono da un sottoagente. Il tool A2A chiama un endpoint Agent2Agent remoto tramite una connessione di progetto, e il tuo agente può a sua volta essere esposto come endpoint A2A in ingresso, con agent card e ruolo Foundry Agent Consumer per chi lo chiama. I workflow dichiarativi (preview) offrono pattern sequential, group chat e human-in-the-loop. Da ricordare: il tool Connected Agents dell’API classica non esiste nel nuovo Agent Service.

Autonomia con i freni: approvazioni e guardrail

Un flusso autonomo si rende semiautonomo mettendo una conferma prima delle azioni che scrivono, cancellano o spendono. Sugli strumenti MCP il controllo è require_approval: il default è always; i valori sono always, never o un oggetto che elenca gli strumenti esenti, per esempio {"never": ["search_repos"]}. Quando scatta, la risposta contiene un item mcp_approval_request con nome dello strumento e argomenti: li esamini e rimandi un mcp_approval_response. Usa anche allowed_tools come allow-list, e tratta descrizioni e risultati del server MCP come input non fidato: possono contenere prompt injection indiretta.

Per un hosted agent che deve aspettare una persona esiste la catena @multi_turn_task (preview): il turno finisce, la catena passa in stato suspended sotto lo stesso task_id, e il turno successivo rientra nello stesso handler con ctx.entry_mode uguale a "resumed". L’attesa può durare giorni e sopravvive al riavvio del container; nei metadati tieni solo riferimenti piccoli.

Sopra a tutto ci sono i guardrail, che hanno quattro intervention point: user input, tool call, tool response e output. Gli ultimi due esistono solo per gli agenti, e agli agenti si applica solo l’azione «annotate and block», non la semplice annotazione; il guardrail dell’agente sovrascrive quello del modello. Il guardrail Task Adherence (preview) verifica a runtime che l’agente resti allineato all’obiettivo.

Da ricordare per l’esame

  • OpenAPI e MCP per le API, file search e Azure AI Search per la conoscenza, funzioni custom per il codice tuo.
  • Per la ricerca web parti da Web Search; Grounding with Bing serve per parametri aggiuntivi o modelli non OpenAI.
  • Il toolbox centralizza autenticazione, guardrail e versioni dietro un endpoint MCP: promuovi una nuova versione senza ridistribuire gli agenti.
  • Connected Agents non esiste più: per far parlare due agenti si usa il tool A2A, i workflow o l’orchestrazione multi-agente della Responses API.
  • require_approval sugli strumenti MCP produce un mcp_approval_request da approvare esplicitamente; per l’attesa umana lunga si usa la catena @multi_turn_task con lo stesso task_id.