Il punto di rottura sta nei giunti, non negli anelli

Scenario tipico da esame: un distributore qualifica i lead in Dynamics 365 Sales, gestisce il post-vendita in Dynamics 365 Customer Service e riapprovvigiona in Dynamics 365 Supply Chain Management; un agente costruito in Microsoft Copilot Studio apre il caso quando l’opportunità raggiunge una certa fase e propaga l’esito verso l’ERP. Vincolo dichiarato: la sincronizzazione fra customer engagement apps e finance and operations apps passa da dual-write, che la documentazione descrive come integrazione bidirezionale e quasi in tempo reale fra le finance and operations apps e Dataverse.

Un piano di test che verifica l’agente dentro Sales, poi dentro Customer Service, poi dentro Supply Chain Management può chiudersi con tre suite verdi e la catena rotta. Le rotture stanno nei passaggi di consegne, e sono di tre famiglie.

Identità: chi agisce dopo l’handoff? Il controllo Authentication for agents nel Power Platform admin center, in preview, impone a livello di ambiente quali metodi di autenticazione un maker può scegliere in Copilot Studio, da No authentication fino a Require Microsoft authentication. Se lo scenario nasce con l’utente autenticato e prosegue con un trigger autonomo, il principal cambia: il test deve dichiarare quale identità porta il record oltre il confine.

Permessi: la guida ai multi-agent patterns è esplicita nel dire che un connected agent può avere accessi che il parent non possiede, e che una delega può quindi aggirare una restrizione che il parent rispetta. È un difetto che non si manifesta mai testando i due agenti separatamente: emerge solo nel percorso completo.

Formato dei dati: dual-write porta in Dataverse concetti come company e party, la date effectivity e l’estensione dei decimali sul tipo currency (funzionalità opt-in). Arrotondamenti, azienda legale implicita, righe con validità temporale sono esattamente i punti in cui un valore corretto in un’app diventa un valore sbagliato nell’altra.

Progettare lo scenario: percorso di business, non sequenza di schermate

Uno scenario end-to-end ben progettato dichiara un esito di business osservabile e, per ogni confine attraversato, tre cose: quale identità agisce, quale record fa da testimone dell’avvenuto passaggio, entro quale latenza il testimone deve comparire. Solo così la suite fallisce dove il difetto è, invece di fallire a valle.

La copertura va spinta oltre il caso felice. La guida ai multi-agent patterns raccomanda di provare interrogazioni che non corrispondono al dominio di nessun subagent e di verificare che il parent gestisca con grazia il caso in cui nessuno abbia trovato nulla: in una catena multi-app è la stessa cosa che chiedersi che succede quando l’app a valle rifiuta il record.

Attenzione a non confondere tre pratiche distinte. Evaluation misura la qualità delle risposte rispetto a criteri dichiarati; monitoring e telemetria osservano il comportamento in esercizio — in Copilot Studio la pagina Activity con la activity map e le trascrizioni, in Microsoft Foundry le tracce e la observability; il testing end-to-end verifica che il processo arrivi in fondo. La pagina sulla valutazione degli agenti di Microsoft 365 Copilot lo dice in modo netto: la evaluation non sostituisce le revisioni di responsible AI, la moderazione dei contenuti, il security testing contro il prompt injection, la user research né il performance testing. Chi le fonde in un’unica voce di piano perde un rischio per strada.

Ultima distinzione da tenere ferma: l’ALM di Power Platform — solution, environment, pipeline — governa la promozione degli artefatti low-code; il ciclo di vita di un deployment in Foundry è un’altra cosa e va gestito con i suoi strumenti. Uno scenario che attraversa entrambi ha due catene di promozione, non una.

Costruire i test case con l’aiuto dell’AI

Il vocabolario ufficiale del test case è quello della documentazione sulla evaluation degli agenti: un prompt, un comportamento atteso, una o più assertion, un grader (keyword match, exact match, text similarity, LLM-as-judge, tool verification), un quality signal per classificare i fallimenti e i grounding data che rendono l’asserzione verificabile. La stessa pagina fissa dei riferimenti di copertura utili come argomento in una design review: 20-50 casi in prototipazione, 50-100 in preproduzione, oltre 100 in produzione, con pass rate atteso fra 80% e 90% e regressioni core vicine al 100%.

Dove entra l’AI nella creazione dei casi. In Microsoft Foundry, Generate a synthetic evaluation dataset (preview) sintetizza coppie domanda-risposta partendo dalla definizione di un agente, da un prompt inline o da un documento di riferimento; Convert agent traces into evaluation datasets (preview) trasforma il traffico reale in dataset usando l’intelligent sampling, che scarta il rumore e seleziona un insieme rappresentativo. Sempre in Foundry si può far generare un rubric evaluator dal contesto dell’agente. Per i declarative agent di Microsoft 365 Copilot la documentazione segnala Work IQ Dev Tools (preview) per creare ed eseguire evaluation.

Il criterio architetturale, però, è uno solo: il generatore produce candidati, non verità. La documentazione stessa raccomanda di partire dal minimo consentito di campioni, ispezionare le righe e rigenerare quando cambiano le istruzioni dell’agente. E c’è una trappola specifica del multi-app: un dataset sintetizzato dalle istruzioni dell’agente misura la coerenza dell’agente con sé stesso, non con la regola aziendale che vive nell’app a valle. I casi che attraversano un confine vanno ancorati a grounding data reali e ai reclami effettivi, che diventano casi di regressione permanenti.

Il gate: quando lo scenario autorizza il rilascio

Il Power Platform Well-Architected chiede rilasci piccoli, incrementali e quality-gated, con health model, esposizione progressiva e stop immediato al primo segnale, scegliendo consapevolmente fra rollback e roll forward — e avverte che tornare indietro su modifiche di dati o schema è complesso. Su una catena dual-write questo è il vincolo decisivo: se lo stato non è facilmente reversibile, il gate va spostato prima, sullo scenario end-to-end in ambiente che rispecchia la produzione. Nel ciclo di vita dell’agente descritto dal Center of Excellence, la fase Deploy passa per release gate che confermano accuratezza, sicurezza e prontezza, con un owner nominato. L’esame chiede proprio questo: dato il vincolo, quale gate e in quale punto.