Un agente o molti: il criterio di rottura
La generative orchestration di Copilot Studio supporta sistemi multi-agente in cui un agente chiama altri agenti. Le due forme sono profondamente diverse e vanno tenute distinte: un child agent vive dentro il tuo agente, un connected agent è un agente separato a cui il tuo si collega.
Il child agent è la scelta giusta quando stai costruendo un singolo caso d’uso che risponde a un singolo intento o completa un singolo compito, quando un solo maker o un piccolo team coeso gestisce tutta la soluzione, quando vuoi solo raggruppare in modo logico tools, instructions e knowledge dentro un agente più grande, e quando non ti servono impostazioni di configurazione, autenticazione o pubblicazione separate per i sottoagenti.
Il segnale che è ora di spezzare in agenti connessi è preciso: quando la capacità dell’agente di distinguere fra i tool disponibili in base a nome e descrizione inizia a degradare. La documentazione dà una regola empirica: questo degrado può manifestarsi quando l’agente principale ha più di 30-40 scelte d’azione fra tools, topics e altri agenti, ma può capitare anche con pochi tool dalle descrizioni simili. Altri motivi validi: team diversi che gestiscono agenti in modo indipendente, necessità di pubblicare e mantenere gli agenti separatamente rendendoli disponibili su canali propri, impostazioni dedicate come il modello usato, processi ALM indipendenti, e la volontà di rendere l’agente riutilizzabile da più agenti principali.
Attenzione a un’ambiguità che l’esame sfrutta: un child agent non è un topic, non è un tool e non è una knowledge source. Ha instructions proprie, e puoi aggiungere knowledge e tools che solo lui può usare. Soprattutto ha una propria orchestrazione, quindi limiti sul numero di tool separati da quelli dell’agente principale: è uno dei vantaggi reali del pattern. Il prezzo è la latenza degli hop di orchestrazione aggiuntivi, perché l’agente connesso gira poi sul proprio livello di orchestrazione.
Chi resta proprietario di cosa
Collegare un agente Copilot Studio esistente significa consumare qualcosa che appartiene a qualcun altro, e i prerequisiti lo dicono chiaramente: l’altro agente deve stare nello stesso environment, deve essere pubblicato, deve essere configurato per accettare connessioni da altri agenti, e il maker deve esserne il proprietario oppure avere l’agente condiviso con sé. A seconda dell’impostazione di autenticazione potrebbe servire condividere l’agente connesso anche con gli utenti finali dell’agente principale, perché funzioni a runtime.
Sul lato di chi espone l’agente, l’interruttore sta in Settings: Let other agents connect to and use this one. Per impostazione predefinita qualsiasi agente può collegarsi a un altro agente nello stesso environment, quindi qui si disattiva, non si attiva.
Il percorso di aggiunta è Agents → Add an agent → Connect to an external agent → Copilot Studio. Da ricordare che anche un agente dello stesso environment sta sotto la voce “external”: non farti ingannare dall’etichetta. Dopo aver scelto l’agente ne ritocchi la description per renderla contestuale all’agente chiamante, e se vuoi limitare le informazioni che passano puoi deselezionare Pass conversation history to this agent, così viene trasmesso solo il compito esplicito.
Qui si vede la separazione delle proprietà. La description la controlli tu localmente: gli aggiornamenti della description dell’agente connesso non si sincronizzano automaticamente. Il contenuto invece resta dell’altro team, e vale la regola sul rilascio: “Your main agent can only use the latest version of a connected agent after that agent is published.”
Il limite che vieta le catene
La limitazione da memorizzare è quella che rompe le architetture progettate a catena: se usi un agente come agente principale con uno o più agenti connessi, non puoi usare quello stesso agente come agente connesso di un secondo agente principale. Al contrario, qualunque agente che non abbia agenti connessi può essere agente connesso di più agenti principali. In pratica la topologia sostenibile è a stella su un livello, con foglie riutilizzabili, non un albero arbitrariamente profondo di orchestratori che si chiamano fra loro.
Distingui anche le operazioni di gestione, che sulla pagina Agents hanno nomi diversi per i due oggetti: l’interruttore Enabled rende temporaneamente inattivo un child o un connected agent, Delete elimina un child agent, mentre per un agente connesso la voce è Disconnect agent e rimuove solo la relazione di delega, non l’agente altrui.
Sul comportamento conversazionale il principio guida è la risposta unica: in un setup multi-agente solo l’agente principale parla con l’utente, i sottoagenti sono ricercatori, non rispondenti. La documentazione suggerisce un linguaggio direttivo forte nelle instructions:
Parent: You're the only agent that communicates with the user.
Combine findings from all child agents into a single response.
Child: You're a subagent. Do NOT reply to the user directly.Gli altri tipi di agente collegabile
Oltre al child agent e all’agente Copilot Studio esistente, la stessa pagina permette di collegare un Foundry agent in preview, scegliendo una connection creata con l’endpoint URL del progetto Foundry e indicando l’Agent Id; qui vale un dettaglio operativo, cioè che puoi collegare solo agenti creati nel nuovo portale Microsoft Foundry, mentre un agente del portale precedente porta a un errore “404 - Version not found”. Ci sono poi il Fabric data agent in preview, con le sue limitazioni note (non lo puoi richiamare con il nodo di redirect da un topic, non lo puoi citare nelle instructions e non funziona quando l’agente principale è distribuito su Microsoft 365 Copilot), l’agente costruito con Microsoft 365 Agents SDK, identificato dal messaging endpoint che per default termina con /api/messages, e il collegamento Agent2Agent, dove indichi l’endpoint di comunicazione e non l’URL della agent card, con autenticazione None, API key oppure OAuth 2.0. Nota che le connessioni A2A poggiano sull’infrastruttura dei custom connector: non confonderle con i Copilot connectors né con i connettori Power Platform.
L’esame verifica su questo punto tre cose: che sappia scegliere fra child agent e agente connesso partendo dai vincoli organizzativi e di rilascio, non dalla dimensione del prompt; che ricordi i quattro prerequisiti del collegamento a un agente esistente; e che riconosca il limite sul riuso di un principale come connesso quando ti viene proposta un’architettura a più livelli.