Tre piani da non sovrapporre

Un requisito che dice “l’agente deve poter consultare il nostro indice documentale” è una domanda sugli strumenti. Uno che dice “l’operatore deve vedere in una sola schermata le richieste aperte e i relativi contatti” è una domanda sulla superficie di interfaccia. Uno che dice “il responsabile deve sapere ogni mattina che cosa hanno fatto gli agenti durante la notte, e poter intervenire” è una domanda sulla supervisione. Sono tre piani distinti: i Foundry Tools sono ciò che un agente può chiamare, le generative page sono una pagina dentro un’app model-driven, l’agent feed è il canale con cui una persona sorveglia il lavoro degli agenti. Rispondere a uno con l’altro è l’errore che l’esame va a cercare.

Proporre i Foundry Tools a fronte di un requisito

In Microsoft Foundry, Foundry Tools è l’esperienza del portale (Build > Tools) dove si scoprono, configurano e gestiscono gli strumenti; il tool catalog è l’elenco navigabile, e un private tool catalog limita la visibilità ai soli utenti dell’organizzazione. Gli strumenti del Microsoft Foundry Agents service si dividono in built-in — fra cui Web search, Code Interpreter, File Search, Azure AI Search, Azure Functions, Function calling, e in preview Image Generation, Browser Automation, Computer Use, Microsoft Fabric e SharePoint — e custom: MCP, OpenAPI (specifica 3.0 o 3.1) e Agent-to-Agent (A2A), in preview.

Il criterio di scelta segue la natura del dato e di chi esegue: dato già indicizzato in un indice esistente porta ad Azure AI Search, documenti caricati portano a File Search, un’API HTTP già descritta porta all’OpenAPI tool, una capability mantenuta da un altro team e riusata da più agenti porta a MCP, un’esecuzione che deve avvenire nella tua applicazione porta a function calling.

Due vincoli architetturali decidono più della preferenza. Il primo: la via raccomandata per dare strumenti a un agente è il toolbox, che espone un insieme curato dietro un unico endpoint MCP gestito, centralizza credenziali e policy e introduce il versioning — si promuove una nuova versione di default e gli agenti la ereditano senza modifiche al codice. Ma non tutto può stare in un toolbox: function calling (che si esegue lato client), Grounding with Bing, Computer use, Image generation, SharePoint, Fabric data agent e Azure Functions non sono supportati nel toolbox e restano integrazioni dirette. Se il vincolo aziendale è “tutti gli agenti devono passare da un unico punto governato”, una proposta che poggia su quegli strumenti non lo soddisfa.

Il secondo vincolo: la disponibilità di uno strumento dipende sia dal modello sia dalla regione. Se una delle due tabelle di supporto dice “No”, lo strumento non funziona anche se l’altra dice “Sì”. Un cliente che impone la residenza in una regione specifica può quindi vedersi escludere una funzionalità a prescindere dal modello.

Sul contorno: tool search e skills sono in preview e servono rispettivamente a evitare che centinaia di definizioni saturino il contesto e a impacchettare flussi multi-passo versionati e immutabili; tool_choice (auto, required, none) dà il controllo deterministico sulla chiamata; la governance degli strumenti MCP tramite AI gateway è in preview e si appoggia ad Azure API Management per rate limit e filtri IP, con limiti espliciti — vale solo per strumenti MCP creati nel portale che non usano managed OAuth, il routing si applica solo alla creazione dello strumento e il gateway non registra le tracce degli strumenti.

Le generative page code-first

Una generative page è una pagina di un’app model-driven generata da linguaggio naturale: il sistema produce codice React in TypeScript che copre sia il layout sia la logica. Esistono due modi di crearla, e la scelta è architetturale. L’esperienza in-browser su make.powerapps.com richiede un ambiente in Stati Uniti, Gran Bretagna, Australia o Singapore e accetta prompt solo in inglese americano; l’approccio code-first con strumenti di generazione codice (per esempio GitHub Copilot CLI o Claude Code, con il plugin Power Platform Skills) è raccomandato da Microsoft, è disponibile in tutto il mondo sui cloud pubblici, dà accesso ai modelli più recenti, produce anche le tabelle Dataverse di supporto e distribuisce con i comandi PAC CLI, lasciando in locale package.json e genpage.d.ts per IntelliSense.

Per un’organizzazione con ambiente in Europa e pipeline di rilascio già codificata, il code-first non è una preferenza stilistica: è l’unica via. I limiti valgono in entrambi i casi — solo tabelle Dataverse, al massimo sei per pagina, nessuna collaborazione contemporanea fra maker, solo app model-driven. Le operazioni sui dati passano dall’oggetto dataApi (createRow, updateRow, deleteRow, retrieveRow, queryTable, getChoices), la pagina accetta i parametri recordId, entityName e data ed è solution-aware, ma nella solution viaggiano solo il primo prompt e il codice pubblicato, non la conversazione con l’agente. L’Accessibility assistant segnala le violazioni, però la validazione del codice resta responsabilità di chi lo pubblica.

L’agent feed come canale di supervisione

L’agent feed è in preview e vive in cima alla sitemap di un’app model-driven. Dipende dal Power Apps MCP server, configurabile solo da Microsoft Copilot Studio, i cui strumenti determinano il comportamento: request_assistance crea un elemento in Needs Attention e l’agente attende il callback umano, log_for_review registra passivamente in Completed, invoke_data_entry propone un record che non viene mai creato automaticamente senza revisione. Un agente avviato da trigger richiede le Maker-provided credentials. Attenzione al piano di sicurezza: chiunque abbia accesso alla tabella Agent Task vede gli elementi del feed, quindi non si progettano attività indirizzate a singoli utenti come se il feed fosse una casella privata.

Che cosa verifica l’esame

Le domande presentano un requisito e alternative plausibili prese dai tre piani. Riconosci il piano prima del prodotto: un bisogno di dato per l’agente è uno strumento, un bisogno di schermata è una generative page, un bisogno di controllo umano è l’agent feed. E non chiamare “Foundry Tool” il Power Apps MCP server: vive in Power Platform, non nel catalogo di Foundry.