Quattro oggetti, quattro mestieri diversi

Quando si progetta l’accesso ai sistemi aziendali, la prima decisione non è tecnica ma tassonomica: quale dei quattro oggetti di Copilot Studio serve davvero. Confonderli è il modo più rapido per costruire una soluzione che funziona in demo e si sfalda in produzione.

Una knowledge source serve a far rispondere l’agente su un contenuto. Nella documentazione classica le fonti supportate sono Public website, Documents, SharePoint, Dataverse ed Enterprise data using connectors; a queste si aggiunge Azure AI Search per collezioni documentali di scala enterprise (la doc di Copilot Studio usa ancora questo nome: non riscriverlo). Le knowledge source lavorano insieme ai generative answers, sia a livello di agente nella pagina Knowledge, sia dentro un topic con un nodo generative answers.

Un tool serve invece a fare qualcosa. La documentazione è netta: “Tools extend what your agent can do beyond answering questions from knowledge sources.” Chiamare un’API, aggiornare un record, aprire un ticket: se l’esito è un effetto su un sistema, è un tool, non una fonte di conoscenza.

Un agent flow serve quando la sequenza deve essere sempre identica. La doc lo dice esplicitamente: “Agent flows are deterministic” e “The same input always produces the same output”. Struttura minima: “An agent flow consists of a trigger and at least one action.” Attenzione al punto che si dimentica più spesso: solo i flow con trigger When an agent calls the flow possono essere aggiunti come tool dentro un agente. Un agent flow non è un’alternativa al tool, diventa un tool.

Un topic, infine, non è nessuna delle tre cose: è un percorso conversazionale autorizzato dal maker, dove l’integrazione viene chiamata da un nodo e “executes at the same position in the topic’s sequence each time”.

Connettori: tre famiglie che si chiamano quasi allo stesso modo

I connettori Power Platform “act as proxies or wrappers around APIs” e si dividono in prebuilt (a loro volta standard e premium) e custom connector, che si costruisce su una propria definizione OpenAPI quando nessun connettore prebuilt copre il servizio. Si possono usare come tool a livello di agente, dentro un topic, come azione in un agent flow e — in preview — come knowledge source in tempo reale, da Add knowledge > Advanced > Real-time connector.

I Copilot connectors (ex Microsoft Graph connectors, con la doc ora sotto /microsoft-365/copilot/connectors/) sono un’altra cosa: indicizzano contenuto non Microsoft dentro Microsoft Graph. Il criterio di scelta documentato è lo spostamento del dato: con i Copilot connectors il contenuto viene copiato e indicizzato (rispettando le ACL della sorgente), con i connettori Power Platform la chiamata avviene a runtime senza replica. Da qui derivano le conseguenze pratiche: i primi portano citazioni e ranking semantico su corpus ampi e si configurano nel Microsoft 365 admin center; i secondi portano dati aggiornati al minuto e transazioni, con latenza dipendente dall’API di destinazione.

Terza via, l’HTTP request node: più veloce da mettere in piedi di un custom connector, ma la doc avverte che “You can’t share it across your organization for reuse like custom connectors”. Se l’integrazione servirà a più agenti, il custom connector si paga una volta. Un MCP server spinge la stessa logica più avanti: modificando la definizione sul server tutti gli agenti che lo consumano usano la versione aggiornata senza ripubblicare. Due limiti da conoscere: “Topics can’t call MCP servers directly” e serve la generative orchestration attiva.

Componenti riusabili: collection, solution, variabili

Il contenitore del riuso interno sono le component collection. I componenti ammessi sono topics, knowledge, tools, child agents, model context protocols, connectors, flows ed entities. Il meccanismo va capito bene: quando aggiungi componenti da un agente a una collection, i componenti vengono spostati nella collection e l’agente li referenzia. Si può designare un primary agent come proprietario dei componenti, e solo in quel caso escludere le dipendenze. In export “When you export a collection, it becomes managed”; per collection complesse — per esempio con connettori o environment variables — la doc rimanda alle solution.

La solution è l’unità di rilascio: “A solution acts as a carrier for your agents”. Ogni agente nasce dentro una solution di default, ma per esportare e importare fra environment serve una solution custom, esportabile come Managed o Unmanaged. Su un agente managed si può poi rimuovere l’eventuale layer non gestito con Remove unmanaged layer.

Qui vive la confusione più costosa fra tre oggetti omonimi. Una environment variable è configurazione di rilascio: concetto Power Platform, in Copilot Studio è read-only, e dopo un cambio di valore gli agenti che la usano vanno ripubblicati (eccezione: le variabili di tipo secret, lette a runtime). Una connection reference è la credenziale verso il servizio. Una variabile globale non c’entra nulla con il rilascio: è stato di conversazione, usabile in tutti i topic. Nelle pipeline automatizzate le prime due si pre-popolano con un deployment settings file:

{
  "EnvironmentVariables": [
    { "SchemaName": "tst_EnvironmentType", "Value": "UAT" }
  ],
  "ConnectionReferences": [
    { "LogicalName": "tst_SharepointSiteURL", "ConnectionId": "..." }
  ]
}

Agenti riusati e il limite che l’esame cerca

Un agente può essere esteso con child agent (leggeri, interni, non pubblicabili a parte), con un agente Copilot Studio esistente, con un agente esposto via protocollo A2A, con un Foundry agent, con un Fabric data agent o con un agente costruito con Microsoft 365 Agents SDK. Per collegare un agente Copilot Studio esistente servono tre condizioni: stesso environment, agente pubblicato, e impostazione Let other agents connect to and use this one attiva. La descrizione, una volta collegato, si governa localmente e non si sincronizza con l’originale.

Il criterio di scelta è la riusabilità: child agent quando non serve pubblicare né riusare il modulo altrove, agenti connessi quando team diversi li mantengono, quando ognuno serve canali propri o quando la precisione dell’orchestratore degrada al crescere delle scelte di azione disponibili.

E qui il limite che vale memorizzare, perché è esattamente il tipo di vincolo che l’esame trasforma in distrattore plausibile: “If you use an agent as a main agent with one or more connected agents, you can’t also use the same agent as a connected agent for a second main agent.” Un agente senza agenti connessi, invece, può essere collegato a più agenti principali. Tradotto in fase di pianificazione: i moduli destinati al riuso vanno tenuti piatti, e l’orchestrazione multi-livello si concentra in cima. Da verificare anche i limiti dei Fabric data agent, che non si possono richiamare con il nodo Redirect né citare nelle instructions.