La scelta è di prossimità, non di potenza

Il percorso ufficiale pone la domanda in modo netto: estendere Microsoft 365 Copilot oppure costruire un agente custom. I criteri non riguardano quanto è capace il modello, ma dove vive il lavoro. Si estende Copilot quando le funzionalità di base coprono già la maggior parte del compito, lo scenario sta dentro i flussi di produttività di Microsoft 365, i dati risiedono principalmente lì e la logica custom resta semplice. Si costruisce un agente custom quando servono ragionamento multi-passo, orchestrazione fra tool e API, autonomia operativa o esecuzione fuori da Microsoft 365. La differenza decisiva è la governance: estendendo Copilot si ereditano le protezioni già presenti, mentre l’agente custom richiede che siano policy operative, monitoraggio e controlli sul comportamento del modello a essere definiti da noi.

Tenete separate le tre superfici di costruzione: Microsoft Copilot Studio per gli agenti low-code, l’estensibilità di Microsoft 365 Copilot per declarative agent, API plugin e connector, e Microsoft Foundry per modelli, Foundry Tools e Microsoft Foundry Agents service. Questa unità tiene le due estremità del continuum: il modello su misura e l’agente accanto all’utente.

Un modello custom è un ciclo di vita che ci si assume

Microsoft Foundry offre tre tecniche di fine-tuning: supervised fine-tuning, Reinforcement fine-tuning (RFT) e Direct Preference Optimization (DPO), impilabili — prima SFT per la capacità, poi DPO per allineare le preferenze. I casi in cui il fine-tuning è la risposta giusta sono definiti: ridurre l’accumulo di esempi nel prompt, fissare stile e tono, produrre output conformi a uno schema, migliorare l’uso dei tool e la distillation, cioè usare gli output di un modello grande per addestrarne uno piccolo con costo e latenza inferiori.

Il costo vero non è l’addestramento. La documentazione elenca i vincoli veri: servono dati etichettati di qualità e rappresentativi, il modello custom aggiunge costi di training e di hosting, e il fine-tuning va ripetuto quando i dati cambiano o quando esce un base model aggiornato. Sopra questo corre il ciclo di vita di Foundry Models — Preview, Generally Available, Legacy, Deprecated, Retired — dove un modello ritirato smette semplicemente di rispondere. I modelli fine-tuned hanno due ritiri distinti, uno per il training e uno per il deployment. E i deployment di tipo Standard vengono aggiornati automaticamente, mentre quelli provisioned no: la migrazione è manuale.

Scenario: una compagnia assicurativa deve classificare le richieste di sinistro in una tassonomia interna, con output in uno schema fisso e latenza contenuta. Il fine-tuning con distillation è tecnicamente la risposta migliore; la scelta di un deployment provisioned dà latenza prevedibile ma toglie l’auto-upgrade. Se l’organizzazione non ha un processo che rivaluti e riaddestri il modello a ogni ritiro annunciato, l’architetto deve proporre grounding e prompt engineering, meno eleganti ma sostenibili. È questo il ragionamento che l’esame premia.

Sul deployment: Serverless API è l’opzione preferita; i modelli open-source e a pesi custom passano da managed compute, oggi in public preview, dove il content filtering integrato non è disponibile — un vincolo di responsible AI da dichiarare in fase di design, non da scoprire in collaudo. Il deployment type (Global Standard, Data Zone Standard, Standard, provisioned, batch) descrive dove i dati sono elaborati e come si paga la capacità: non è il model router, che è un meccanismo diverso e va nominato per quello che è.

Agenti in Microsoft 365 Copilot: i permessi sono il progetto

Un declarative agent si definisce con instructions, actions e knowledge e gira sullo stesso orchestrator, sugli stessi foundation model e sugli stessi servizi che alimentano Microsoft 365 Copilot. Un custom engine agent porta invece orchestrazione e modelli propri e richiede app manifest in versione 1.21 o successiva. Entrambi restano app di Microsoft 365: app package con manifest e icone, definizione sotto il nodo copilotAgents, un solo declarative agent per manifest, e validazione Responsible AI prima della pubblicazione.

Le knowledge source disponibili sono un elenco chiuso — Copilot connectors, SharePoint, OneDrive, embedded file content, web search e scoped web search fino a quattro siti pubblici, Dataverse, email, people, pagine di OneNote, messaggi e riunioni di Teams — e ognuna porta un vincolo. SharePoint e OneDrive richiedono che l’utente che interroga abbia una licenza Microsoft 365 Copilot attiva. Se l’amministratore disattiva la web search per l’organizzazione, l’agente non segnala errore: smette solo di usarla. Le Information Barriers di Microsoft Purview non sono supportate sugli embedded file, quindi chiunque possa usare l’agente vede risposte fondate su quel contenuto. Sono esattamente i punti su cui l’esame costruisce le domande: dato un requisito di riservatezza, quale knowledge source resta ammissibile.

Per il ciclo di vita, l’Agents Toolkit usa environment file per tenant e versione, e un Teams app ID diverso produce due installazioni che convivono nello stesso tenant. Non confondetelo con l’ALM di Power Platform fatto di solution, environment e pipeline: dichiarate sempre di quale ciclo state parlando.

Teams e SharePoint: ottimizzare stando dove l’utente già lavora

Gli agenti in SharePoint sono file con estensione .agent: i permessi del file dicono chi può usarli e modificarli, e le risposte dipendono dai permessi del singolo utente sulle sorgenti citate. Le leve di controllo sono la restricted access control policy, la restricted content discovery — che spegne tutte le funzionalità agent su un sito — e la DLP di Microsoft Purview, che sul file .agent va costruita su una condizione di estensione, perché l’etichetta di riservatezza non è ancora applicabile a quel file. Nel Microsoft 365 admin center la sezione Agents del Copilot Control System consente di bloccare un agente, ma il blocco vale solo per Copilot Chat e non per OneDrive, SharePoint o Teams: è una distinzione che una domanda ben scritta usa come distrattore.

In Teams gli agenti collaborativi si costruiscono con il Teams SDK e si estendono agli altri hub di Microsoft 365 con il Microsoft 365 Agents SDK. Un agente costruito in Foundry, infine, può essere pubblicato verso Microsoft 365 Copilot e Teams: la pubblicazione crea una risorsa Azure Bot Service e chiede di scegliere fra visibilità personale, immediata e senza approvazione, e visibilità di organizzazione, che richiede l’approvazione dell’amministratore prima di comparire sotto Built by your org. L’endpoint pubblicato è stabile: si cambia la active version senza ripubblicare nulla. È qui che il modello custom e la prossimità all’utente tornano a incontrarsi.