Quale leva di estensibilità, e perché la decisione precede lo strumento
In Microsoft Copilot Studio un agente si estende con quattro categorie: topic, tool, knowledge source e altri agenti (in preview). Tool e knowledge che devono raggiungere un altro sistema passano da un connector, prebuilt o custom, e questo dettaglio apparentemente implementativo è la prima leva di governance: se il canale è un connector, allora le data policy di Power Platform governano anche ciò che ci transita.
La seconda decisione, quella che condiziona tutte le altre di questa unità, è l’orchestrazione. Con generative orchestration l’agente sceglie da solo topic, tool, knowledge e agenti collegati leggendone nome e descrizione; con classic orchestration un tool può essere invocato soltanto esplicitamente da dentro un topic, e i topic si attivano per corrispondenza con le trigger phrase. Non è una preferenza stilistica: Model Context Protocol, computer use e deep reasoning richiedono tutti generative orchestration. Se l’organizzazione ha disattivato la generative orchestration a livello di ambiente, gli agenti creati lì possono usare solo la classic, e metà di questa unità diventa non applicabile.
Attenzione a non confondere tre piani che l’esame tiene separati: l’orchestrazione classica basata su NLU dentro Copilot Studio, la superficie di estensibilità di Microsoft 365 Copilot (dove non si aggiungono tool all’esperienza, ma si costruisce un declarative agent che poi si pubblica) e Microsoft Foundry, dove si ragiona di modelli, Foundry Tools e Microsoft Foundry Agents service. Sono tre superfici, non tre nomi della stessa cosa.
Model Context Protocol: standardizzare, oppure no
Un server MCP pubblica resources, tools e prompts; la documentazione precisa che Copilot Studio attualmente supporta tools e resources. Il valore architetturale sta nella dinamicità: il server fornisce nome, descrizione, input e output, e quando i tool cambiano sul server Copilot Studio riflette le modifiche, rimuovendo quelli obsoleti. Il trasporto supportato è Streamable; SSE, deprecato nella specifica, non è più supportato dopo agosto 2025. L’autenticazione si configura come None, API key (in header o query) oppure OAuth 2.0, quest’ultimo in variante Dynamic discovery, Dynamic o Manual.
Il criterio di scelta è esplicito nella guidance: MCP conviene quando serve un modo standardizzato e gestito centralmente di esporre gli stessi tool a più agenti, e soprattutto quando le API a monte cambiano spesso — si aggiorna la definizione una volta sul server e tutti gli agenti usano la versione aggiornata senza ripubblicare. Se un server MCP non esiste o si sta prototipando, chiamare l’API direttamente è più rapido. Due limiti pesano sul design e vanno messi a verbale: non si possono arricchire le descrizioni dei tool con contesto aggiuntivo su quando invocarli, e i topic non possono chiamare direttamente un server MCP.
Scenario tipico: un’assicurazione espone la stessa anagrafica sinistri a sei agenti di reparto, con il vincolo che l’ufficio API rilascia modifiche ogni due settimane. Un connector per agente significherebbe sei aggiornamenti per rilascio; un server MCP centralizza la definizione. Il rovescio è che, non potendo affinare le descrizioni lato agente, la qualità della selezione dipende da come il team che possiede il server ha scritto quelle descrizioni.
Computer Use: quando non c’è API, e il perimetro diventa il progetto
Computer use è un tool che fa interagire l’agente con una macchina Windows — siti web e app desktop — descrivendo il compito in linguaggio naturale. È basato sui Computer-Using Agents (CUA), modelli che uniscono visione e ragionamento; fra i modelli selezionabili figurano Computer-Using Agent (CUA) di OpenAI e Claude Sonnet 4.5 come generally available, mentre Claude Sonnet 4.6 e Claude Opus 4.6 sono marcati experimental. Usare i modelli Anthropic richiede che l’amministratore abbia attivato l’accesso ai modelli esterni per l’ambiente.
Il vero contenuto architetturale sta in tre scelte. Dove gira: hosted browser (preview) e Cloud PC pool (preview), entrambi powered by Windows 365 for Agents, oppure bring-your-own-machine registrata in Power Automate. L’hosted browser non è Entra joined al tenant né gestito dalle policy Intune, può essere sottoposto a throttling e non è raccomandato per la produzione; il Cloud PC pool è Entra joined e Intune enrolled e scala automaticamente; con la macchina propria le esecuzioni sulla stessa macchina vengono accodate ed eseguite in sequenza. Con quali credenziali: Maker-provided credentials è il default e, se si condivide l’agente, chiunque lo usi agisce con gli accessi dell’autore. Entro quale perimetro: Access control limita i siti e le app su cui si può agire, ma la nota è chirurgica — impedisce le azioni, non l’apertura; Enforce HTTPS esclude i siti in HTTP.
La human supervision invia la richiesta di revisione via Outlook al revisore configurato, con un timeout oltre il quale l’esecuzione si ferma. Va progettata sapendo che il comportamento è probabilistico: la documentazione avverte di non affidarsi alla revisione umana come fail-safe, e che disattivarla non rende l’agente pienamente autonomo — senza revisori la sessione fallisce quando l’agente si mette in pausa. Il rischio di prompt injection annidata in screenshot e pagine web è dichiarato, e la mitigazione è ambientale: macchine dedicate, minimo privilegio, allow list.
Reasoning e voice mode: comportamenti che cambiano latenza, regione e canale
Il deep reasoning è in preview, si attiva in Settings dell’agente e richiede generative orchestration. L’agente decide da sé quando applicarlo, oppure lo si forza con la parola reason nelle istruzioni. Ha due conseguenze da mettere in un design review: risposte più lente, e disponibilità limitata a Stati Uniti e UE (Regno Unito escluso), con il modello Azure OpenAI o3 e nessun impegno di data residency in preview.
Sul voice mode la distinzione da non sbagliare è fra basic voice agents, che usano classic orchestration e modelli NLU, e real-time voice agents, che stanno in scenari di generative orchestration e usano un modello speech-to-speech per una conversazione a bassa latenza, con supporto PSTN e SIP, DTMF, barge-in e voice activity detection. Il numero di telefono arriva da Azure Communication Services e i prerequisiti includono Dynamics 365 Contact Center con i canali provisionati. Sui canali di digital messaging la funzionalità è in preview, con limiti espliciti: OAuth e autenticazione Microsoft non supportati, quindi No authentication, e conversazioni oltre i 60 minuti che escalano automaticamente a un operatore umano.
Qui l’esame è prevedibile: la study guide segnala che verte soprattutto su funzionalità generally available. Impara che cosa fanno hosted browser, Cloud PC pool, deep reasoning e real-time agents su digital messaging, ma quando la domanda pone un vincolo di produzione o di data residency, la risposta corretta raramente è la capacità in preview.