Il criterio di partenza non è la complessità, è il confine
La domanda “un agente o molti” sembra una questione di ingegneria e invece è una questione di perimetro. Il Cloud Adoption Framework è esplicito: si parte multi-agente solo quando ricorre uno di tre criteri, e sono pochi e precisi. Il caso d’uso attraversa confini di sicurezza e conformità, e regolamenti o policy impongono isolamento dei dati; sono coinvolti team distinti che possiedono aree di conoscenza separate e vogliono cicli di rilascio indipendenti; oppure la roadmap prevede una crescita su funzioni, fonti dati o business unit diverse, con la soglia indicativa delle tre-cinque funzioni distinte oltre la quale un agente monolitico diventa impossibile da mantenere.
Fuori da quei tre casi la documentazione non dice “scegli”, dice testa prima un singolo agente. Ruoli chiari (planner, reviewer, executor) non giustificano da soli la separazione: un singolo agente con persona switching, prompt condizionali e permessi sui tool spesso li emula. Il costo dell’errore è misurabile: ogni agente rielabora contesto ridondante, la latenza si accumula a ogni handoff, la superficie di sicurezza cresce con le credenziali e i punti di transito dei dati fra agenti.
Lo scenario che l’esame usa per il primo criterio è quello dei servizi finanziari, dove un agente prepara la transazione e un altro la valida: la separazione dei compiti è imposta dall’architettura, non dal prompt. In quel caso il prototipo a singolo agente non serve, il vincolo ha già deciso.
Prima la superficie, poi il numero di agenti
L’albero decisionale mette una domanda davanti a tutte: un agente SaaS soddisfa i requisiti funzionali? Se sì, si adotta il prodotto pronto (agenti in Microsoft 365 Copilot come Researcher, agenti Dynamics 365, GitHub Copilot, Fabric data agent). Solo se no si costruisce, e allora le opzioni sono tre: Microsoft Copilot Studio come SaaS low-code, Microsoft Foundry come PaaS che copre sia il no-code sia il pro-code, GPU e container come IaaS per workload con isolamento e modelli propri.
Estendere Microsoft 365 Copilot è la scelta giusta quando l’interazione avviene dentro Word, Excel, Teams o Outlook, i dati vivono già in Microsoft 365 e l’obiettivo è accelerare la produttività ereditando le protezioni Responsible AI della piattaforma: declarative agent, API plugin, Copilot connector (sincronizzati oppure federati via MCP senza indicizzare in Microsoft Graph). Si costruisce invece un agente custom quando servono orchestrazione fra tool, API e altri agenti, autonomia, trigger di sistema o integrazione con sistemi esterni a Microsoft 365.
Dentro Foundry la stessa logica si ripete in piccolo: un prompt agent è dichiarativo e ospitato dalla piattaforma, un hosted agent porta il tuo codice o framework in un container con endpoint gestito. Attenzione a non confondere i tipi di agente (retrieval, task, autonomous nel piano tecnologico) con questa distinzione di deployment: “autonomous” descrive come l’agente viene innescato, non quanti agenti hai.
Comporre una soluzione che attraversa le tre superfici
In Copilot Studio la scelta non è binaria. Gli inline agent (o child agent) sono di fatto sottoprocessi che condividono il contesto dell’agente principale; i connected agent sono agenti separati con orchestrazione, tool e knowledge propri, e vanno usati solo se il sottocompito ha un proprio dominio di strumenti e conoscenza, richiede regole di governance o controlli d’accesso diversi, oppure è riutilizzabile da più agenti principali. La documentazione avverte che un connected agent può avere privilegi che il parent non ha: trattarlo come un’azione potente, non come una funzione qualsiasi.
Il collegamento verso Microsoft Foundry esiste (Add an agent, Connect to an external agent, Microsoft Foundry) ma è in preview e richiede il project endpoint URL più l’Agent Id; funziona solo con agenti creati nel nuovo portale Foundry. Sul lato Microsoft 365 Copilot un declarative agent dichiara gli altri agenti nella proprietà worker_agents del manifest e Copilot Chat fa da broker, con due limiti che l’esame ama: un declarative agent può collegarsi solo ad altri declarative agent, e lo scambio è di solo testo, niente file binari o immagini. Le workflow di Foundry, che aggiungono sequenziale, group chat e human-in-the-loop, sono anch’esse in preview e Microsoft indirizza le nuove implementazioni verso Microsoft Agent Framework.
Che cosa verifica l’esame
Le domande su questo obiettivo non chiedono di configurare, chiedono di giustificare. Data una fabbrica con una sola fonte di conoscenza in SharePoint e tre settimane di tempo, la risposta corretta è un singolo agente con knowledge, non due sottoagenti che si contendono lo stesso indice: la doc dice che il multi-agente aggiunge valore solo quando le fonti sono davvero diverse. Data una banca con separazione dei compiti obbligatoria, la risposta è multi-agente anche se il volume è basso.
La confusione tipica da evitare è scambiare la latenza per un problema di modello quando è un problema di handoff, e presentare “orchestrazione generativa” come sinonimo di multi-agente: la generative orchestration decide quali tool o agenti invocare, ma esiste anche su un agente solo. Il riferimento canonico è /azure/cloud-adoption-framework/ai-agents/single-agent-multiple-agents, affiancato da /microsoft-copilot-studio/guidance/multi-agent-patterns per i pattern di composizione.