Partire dall’inventario, non dalla lavagna bianca

Il primo esercizio di architettura, davanti a una richiesta di automazione, non è disegnare un agente: è verificare se Microsoft lo abbia già scritto. La documentazione di Dynamics 365 Sales elenca Sales Qualification Agent, Sales Opportunity Agent, Sales Close Agent, Sales Research Agent, Recommended Actions Agent e AI-powered Data Enrichment; il lato servizio porta Case Management Agent e Customer Intent Agent, mentre Dynamics 365 Contact Center raggruppa Customer Assist Agent, Quality Assurance Agent e Service Operations Agent nella pagina Contact Center Agents del Copilot Service admin center. Su finance e supply chain trovi Account Reconciliation Agent e Procurement Agent, più Expense agent, Time agent e Approvals agent nella lista del deployment wizard.

Sviluppare il caso d’uso significa allora mappare un processo reale su una di queste capability e dichiarare che cosa resta scoperto. Il framework build / buy / extend della formazione ufficiale è esplicito: si compra quando il processo è standardizzato e il time-to-value conta più della personalizzazione, si estende quando il modello di base funziona ma serve conoscenza di dominio, si costruisce quando il processo è differenziante o i vincoli di compliance non sono soddisfatti dai prodotti. Un agente prebuilt vale come “buy” solo se il perimetro coincide: Procurement Agent gestisce le variazioni dei fornitori sugli ordini di acquisto attraverso supplier communications e impact analysis, e classifica ogni cambio come Has impact o No impact — non è un agente di sourcing strategico, e proporlo come tale è un errore di scoping, non di configurazione.

Il caso d’uso deve anche dichiarare il grado di autonomia. Account Reconciliation Agent raccomanda un’azione sulle eccezioni di tipo Voucher amount mismatch, e la persona sceglie fra la raccomandazione e alternative come Reverse, Link transactions o Accept without change: è un pattern di suggerimento con decisione umana, diverso da Case Management Agent che può creare e aggiornare i case in autonomia e che espone perfino l’opzione di sovrascrivere le modifiche fatte dai rappresentanti. Un requisito di separazione dei compiti in ambito contabile si soddisfa con il primo pattern, non con il secondo.

Vincoli che decidono, non dettagli di configurazione

Tre vincoli spostano un’architettura più di qualunque preferenza funzionale. Il primo è lo stato di rilascio: Procurement Agent e Account Reconciliation Agent sono documentati come production-ready preview, la shadow mode di Case Management Agent è una preview vera e propria, e per Account Reconciliation Agent la documentazione avverte che al momento è il team Microsoft ad attivare l’agente su richiesta. Un piano di rollout che mette una preview sul percorso critico della chiusura contabile va rinegoziato o messo dietro un fallback.

Il secondo è la prova prima della produzione. Case Management Agent offre le simulation, che rieseguono la stessa pipeline di field prediction su record storici o su un file Excel e restituiscono una percentuale di prediction match: è evaluation, cioè misura della qualità dell’output prima del rilascio, e non va confusa con il monitoring runtime né con il testing funzionale. Attenzione al vincolo economico: la documentazione avverte che le simulazioni consumano crediti Copilot o AI esattamente come le predizioni normali.

Il terzo è l’identità e il costo per esecuzione. L’agent deployment wizard del Copilot Hub nel Power Platform admin center segue sempre gli stessi passi — verifica dei prerequisiti, creazione dell’agent identity con le sue licenze e i suoi security role Dataverse, connessioni e connection reference, eventuali mailbox, abilitazione. Ogni agente gira sotto un’identità propria: è lì che si applicano principio del minimo privilegio e audit, non nel prompt.

Attraversare il confine fra le due famiglie di app

Una soluzione che tocca sia le app di customer experience e service sia quelle di finance e supply chain deve dichiarare esplicitamente il confine che sta superando, perché i due lati hanno meccaniche diverse.

Sul lato Dataverse l’ALM è quello classico di Power Platform: si esporta l’agente come solution, includendo componenti come SalesAgentProfile e SalesAgentConfigurationV2 (più Sequence per il solo Sales Qualification Agent), e la documentazione consiglia una solution per profilo agente. L’agente arriva nel target in stato draft: application user Dataverse e app registration sono environment-specific e vanno ricreati a mano, le assignment rule e le knowledge source vanno riverificate. Sul lato finance e operations, invece, l’attivazione passa da Feature management, dalla feature Agent management con Immersive Home come prerequisito, e dalle schede Library e Manage della pagina Agents; la documentazione dichiara che nella versione corrente la funzionalità non supporta l’estensibilità e che l’annullamento delle azioni di un agente per un singolo utente si ottiene cancellando i batch job. Sono due cicli di vita, non uno.

Il ponte dati fra le due famiglie è dual-write, l’infrastruttura di integrazione bidirezionale e near-real-time fra finance and operations apps e Dataverse. Scenario tipico d’esame: un distributore vuole che, quando Procurement Agent rileva un ritardo di fornitura con impatto, il caso cliente in Dynamics 365 Customer Service riporti la nuova data promessa, con il vincolo che il dato di ordine resti autoritativo nell’ERP. La risposta architetturale nomina il meccanismo di sincronizzazione, non un secondo agente.

Che cosa verifica l’esame

Le domande su questo obiettivo puniscono tre confusioni. La prima: Sales agent in Microsoft 365 Copilot porta i dati CRM dentro Outlook e Teams e funziona anche con Salesforce — è un prodotto di estensibilità Microsoft 365, non uno degli agenti dentro Dynamics 365 Sales. La seconda: Analyze demand plans with Copilot in Supply Chain Management è una funzionalità Copilot con domande predefinite (confronti fra periodi, outlier via IQR, deviazioni via MAPE), non un agente autonomo con identità e attività proprie. La terza: Customer Intent Agent scopre gli intent dalle conversazioni passate e costruisce una intent library con generative AI — non è la vecchia orchestrazione NLU su trigger phrase, e va citato come tale quando il vincolo è “riduzione del tempo di handling senza riscrivere i topic”.