Il criterio è il vincolo dichiarato, non la potenza della piattaforma
Davanti a uno stem che descrive un processo aziendale, la tentazione è scegliere la superficie più capace. È l’errore che l’esame punisce. Le quattro domande che decidono davvero sono: dove vivono gli utenti mentre lavorano, dove vivono i dati e chi ne detiene i permessi, quanta autonomia e quale latenza servono, e quale struttura di costo è sostenibile. Se lo stem nomina uno di questi vincoli in modo esplicito — “gli operatori lavorano in Teams”, “i dati non possono lasciare il dispositivo”, “l’agente deve partire senza intervento umano” — quello è il discriminante; se non ne nomina nessuno, più risposte restano difendibili e conviene rileggere il testo cercando il vincolo nascosto.
Il framework build, buy, extend fornisce la griglia economica: si valutano cinque domini di costo (infrastructure, development and integration, data quality and preparation, expertise and resources, ongoing operations). Un dettaglio che vale una domanda: nella tabella di TCO del percorso ufficiale la preparazione dei dati resta High anche per l’opzione extend, esattamente come per build. Estendere abbassa il costo di sviluppo e di infrastruttura, non quello di bonificare, etichettare e mantenere la conoscenza su cui l’agente si fonda.
Estendere Microsoft 365 Copilot: fin dove arriva un declarative agent
Un declarative agent si configura con instructions, knowledge e actions, ma gira sull’orchestratore e sui foundation model di Microsoft 365 Copilot: non richiede hosting aggiuntivo ed eredita compliance, sicurezza e validazione Responsible AI di Microsoft 365. Le knowledge source disponibili sono SharePoint, OneDrive, Copilot connectors, embedded file content, web search e scoped web search, Dataverse, Email, People, OneNote pages, Teams messages e Teams meetings — con la nota operativa che Dataverse non è configurabile da Agent Builder e va dichiarato nel manifest tramite Microsoft 365 Agents Toolkit.
Scenario tipico: un agente che risponde sulle policy HR a dipendenti che vivono in Teams e Outlook, con i documenti già in SharePoint e nessuna azione autonoma richiesta. Estendere Copilot è la risposta corretta, e sceglierne un’altra significa pagare hosting e governance che nessun vincolo giustifica.
Il limite architetturale da conoscere è però netto: la scoped web search si fonda su ciò che Bing ha indicizzato per quei siti, quindi contenuti generati dinamicamente possono risultare mancanti o non aggiornati. Se lo scenario chiede dati strutturati e in continuo cambiamento, la knowledge source web non è la risposta: serve un API plugin basato su una specifica OpenAPI, che interroga la fonte direttamente. Allo stesso modo, i declarative agent sono pensati per l’uso individuale e non supportano interazioni proattive.
Agente custom: quale delle tre superfici, e perché
Quando il vincolo supera quei confini si passa al custom engine agent, che porta orchestrazione e modelli propri, richiede hosting fuori da Microsoft 365 con costo aggiuntivo, e in cambio abilita produttività di gruppo, messaggistica proattiva, canali esterni e comunicazione agent-to-agent. Attenzione: compliance e pratiche Responsible AI diventano responsabilità di chi progetta.
Qui l’esame verifica soprattutto una distinzione che molti sbagliano: “agente custom” non significa “Microsoft Foundry”. Microsoft Copilot Studio è una piattaforma SaaS gestita su Power Platform e produce anch’essa custom engine agent, oggi su tre harness (GitHub Copilot harness per processi multistep con ragionamento, standard harness per conversazioni regolate da topic, Copilot chat harness per portare conoscenza aziendale dentro Microsoft 365 Copilot Chat). Il Microsoft 365 Agents SDK copre il multicanale pro-code, il Teams SDK i casi collaborativi dentro canali e riunioni. In Microsoft Foundry la scelta è fra un prompt agent — istruzioni, modello e Foundry Tools, ospitato dal servizio — e un hosted agent, dove si porta il proprio codice in container e Foundry fornisce endpoint gestito, scaling, identità e osservabilità. Un agente del Microsoft Foundry Agents service può poi essere pubblicato verso Copilot e Teams dal portale oppure tramite un’app proxy costruita con Agents Toolkit: resta un agente sotto governance Azure, non diventa un declarative agent.
Modello custom o small language model: l’ultima leva, non la prima
Creare un modello è raramente la risposta a un problema di conoscenza: quello si risolve con il grounding. Il fine-tuning ha senso quando lo scenario cita prompt diventati lunghissimi per gestire casi limite, uno stile o un tono da rendere costanti, output in uno schema rigido, o un uso di tool da rendere affidabile senza elencare tutte le definizioni. Le tecniche disponibili sono supervised fine-tuning, Reinforcement fine-tuning (RFT) e Direct Preference Optimization (DPO), componibili in sequenza. I contro sono espliciti nella documentazione, ancora ospitata sotto un URL con il vecchio nome: servono dati di qualità e rappresentativi, si aggiungono costi di training e di hosting del modello custom, e l’operazione va ripetuta quando i dati cambiano o esce un nuovo modello base.
Non tutto ciò che si “crea” è un LLM. Un modello AI Builder custom — document processing, prediction, object detection, category classification, entity extraction — resta la risposta giusta per estrarre campi da un modulo proprietario o prevedere un esito su dati storici, mentre i prebuilt coprono scenari comuni (il Text generation prebuilt è in preview).
I casi d’uso degli small language model personalizzati si riconoscono da tre parole nello stem: offline, latenza, dati che non devono lasciare il dispositivo. Foundry Local esegue l’inferenza sull’hardware dell’utente, senza sottoscrizione Azure e senza costo per token, con catalogo curato e accelerazione hardware automatica; è però pensato per un singolo utente e non è uno stack di inferenza server. Il ponte fra i due mondi è la distillation: usare gli output di un modello grande per adattarne uno piccolo e ottenere prestazioni simili sul compito, a costo e latenza inferiori.