Torna al catalogo
Microsoft Copilot Studio
Edizione 2026. Un approfondimento tecnico su Microsoft Copilot Studio, che copre Generative Orchestration, Agent Flows, Tools, Enterprise Grounding e molto altro (2026).
In Riproduzione
Click play to start
0:00
0:00
1
Generative Orchestration
Scopri il cambio di paradigma dalle classiche frasi di attivazione alla Generative Orchestration in Microsoft Copilot Studio. Scopri come l'intelligenza artificiale seleziona dinamicamente Topics e Tools in base alle descrizioni, eliminando del tutto la necessità di una mappatura conversazionale rigida. Questo episodio spiega come il routing intelligente gestisce senza sforzo le query multi-intent.
2
AI-Based Agent Authoring
Impara a usare il linguaggio naturale per accelerare il processo di creazione del tuo bot. Esploriamo l'authoring di agenti basato sull'IA, che ti consente di generare Topics, Prompts e Flows complessi semplicemente descrivendoli. Comprendi come gli LLM vengono utilizzati in fase di build-time per prototipare rapidamente gli agenti.
3
Topics e Nodes
Immergiti nell'anatomia strutturale di un agente. Questo episodio analizza i System topics rispetto ai Custom topics e la logica deterministica dei Nodes necessaria per specifiche regole di business. Impara a mappare percorsi conversazionali precisi utilizzando variabili e condizioni.
4
State e Variables
Dai una memoria al tuo agente. Scopri come lavorare con le Variables in Copilot Studio per passare il contesto tra i Topics, eliminando le domande ripetitive. Esploriamo anche l'uso delle environment variables per archiviare in modo sicuro i segreti di Azure Key Vault.
5
Entities e Slot Filling
Estrai dati strutturati dal linguaggio naturale non strutturato. Questo episodio spiega le prebuilt entities, le custom closed lists, le regex entities e la magia del proactive slot filling, che consente all'IA di saltare le domande quando l'utente fornisce le informazioni in anticipo.
6
Enterprise Knowledge Grounding
Trasforma i tuoi dati aziendali esistenti in un esperto conversazionale. Impara a connettere SharePoint, Dataverse e siti web pubblici come fonti di Knowledge per le Generative Answers. Scopri i limiti e le capacità del grounding della tua IA.
7
Tenant Graph Grounding
Sprigiona tutta la potenza di Microsoft Graph e della ricerca semantica per un recupero ad alta precisione. Questo episodio esplora il Tenant Graph Grounding, utilizzando le licenze Microsoft 365 Copilot per cercare in enormi documenti aziendali con una profonda comprensione semantica.
8
Prompt Tools
Consenti al tuo agente di eseguire al volo compiti specifici di elaborazione dati o riepilogo. Impara a creare Prompt Tools, definire template, specificare input e impostare formati di risposta direttamente all'interno di Copilot Studio.
9
Agent Flows
Collega Copilot Studio ad automazioni di backend complesse e multi-step utilizzando gli Agent Flows. Questo episodio illustra nel dettaglio come aggiungere i flussi di Power Automate come Tools, ponendo l'accento sul limite critico di esecuzione di 100 secondi e sui requisiti di risposta sincrona.
10
Power Platform Connectors
Attingi a migliaia di API esistenti negli ecosistemi Microsoft e di terze parti. Scopri come utilizzare i Power Platform Connectors come Tools attivi nei tuoi agenti Copilot Studio per interagire con servizi esterni senza alcuno sforzo.
11
Il Computer Use Tool
Automatizza i sistemi legacy privi di API utilizzando l'automazione basata sulla visione. Scopri l'anteprima del Computer Use Tool, che sfrutta modelli come Claude Sonnet 4.5 per interagire con le interfacce grafiche tramite mouse e tastiera virtuali, completo di guardrail di sicurezza aziendale.
12
User Authentication
Metti in sicurezza il tuo agente e sblocca esperienze personalizzate. Approfondisci la User Authentication in Copilot Studio, confrontando 'Authenticate with Microsoft' con le configurazioni Manual OAuth2. Impara a configurare gli scope e a garantire l'accesso con privilegi minimi.
13
Voice e IVR
Allontana il tuo agente dalla tastiera e portalo sulla linea telefonica. Scopri le funzionalità di Interactive Voice Response (IVR) di Copilot Studio. Scopri lo speech recognition, il DTMF (input da tastierino), il barge-in e la personalizzazione delle voci degli agenti con SSML.
14
Agent Analytics
Non puoi migliorare ciò che non misuri. Questo episodio analizza la dashboard Analytics in Copilot Studio, spiegando la vista ibrida per le sessioni conversazionali rispetto a quelle autonome, e come esportare le trascrizioni per un'analisi approfondita.
15
Model Context Protocol
Prepara i tuoi agenti per il futuro con lo standard aperto per il contesto IA. Impara a integrare Copilot Studio con server Model Context Protocol (MCP) esterni per acquisire dinamicamente Resources, Tools e Prompts.
Episodi
1
Generative Orchestration
3m 38sScopri il cambio di paradigma dalle classiche frasi di attivazione alla Generative Orchestration in Microsoft Copilot Studio. Scopri come l'intelligenza artificiale seleziona dinamicamente Topics e Tools in base alle descrizioni, eliminando del tutto la necessità di una mappatura conversazionale rigida. Questo episodio spiega come il routing intelligente gestisce senza sforzo le query multi-intent.
Ciao, sono Alex di DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 1 di 15. La maggior parte dei bot builder passa ore a cercare di prevedere e mappare ogni possibile frase che un utente potrebbe digitare. Aggiungi cinquanta varianti di una richiesta di supporto, e il sistema fallisce comunque quando qualcuno digita una frase che non avevi previsto. La Generative Orchestration elimina completamente questa necessità usando il matching dinamico delle descrizioni.
Spesso, quando senti la parola generativo in questo contesto, pensi che significhi generare testo conversazionale. Non è questo il caso. La Generative Orchestration riguarda esclusivamente il routing dinamico e la selezione dei tool. È l'intelligenza che decide quale azione intraprendere, invece di limitarsi a scrivere una risposta.
Nell'orchestrazione classica, crei un topic e definisci manualmente una lista di trigger phrase. Il motore di natural language understanding si basa su quelle frasi esatte per fare il routing dell'utente. La Generative Orchestration elimina completamente le trigger phrase. Invece, scrivi una descrizione chiara in plain text per ogni topic e tool nel tuo agent. Il large language model sottostante legge la query dell'utente, valuta tutte le descrizioni disponibili e determina dinamicamente il match migliore. Non stai più mappando gli input ai trigger. Stai semplicemente descrivendo cosa fanno i tuoi tool.
Questo cambia completamente il modo in cui un agent gestisce input complessi. Pensa a un utente che chiede: Che tempo fa a Seattle e a che ora apre il negozio?
In un setup classico, questo si rompe. Il sistema rileva due intent in conflitto e o ne indovina uno, oppure lancia un errore di fallback. La Generative Orchestration lo gestisce senza problemi. Il modello fa il parsing dell'intera frase e riconosce due obiettivi distinti. Scansiona le tue descrizioni. Per prima cosa, trova un tool per il meteo. Estrae Seattle dalla query dell'utente, lo passa al tool del meteo come parametro di input e lo esegue. Poi, si ricorda della seconda metà del prompt dell'utente. Scansiona di nuovo i tuoi topic, trova quello descritto per gestire gli orari del negozio e lo triggera.
Ecco il punto chiave. L'agent concatena queste azioni in automatico. Gestisce la richiesta meteo, poi fa una transizione fluida verso il topic degli orari del negozio, combinando i risultati. Non devi scrivere nessuna logica di routing o codice di transizione perché questo avvenga.
Questo cambiamento significa che la qualità del tuo agent ora dipende interamente dalla qualità delle tue descrizioni. Se la descrizione del tuo tool per il meteo dice semplicemente meteo, il modello potrebbe fare fatica a fare il routing in modo preciso. Se la descrizione dice recupera le condizioni meteo attuali per un nome di città specificato, il routing diventa esatto. Inoltre, se un utente triggera quel tool per il meteo ma dimentica di specificare la città, il motore generativo nota automaticamente che manca un parametro obbligatorio. Genererà dinamicamente una domanda per chiedere la città all'utente prima di eseguire il tool.
Il tuo takeaway principale è questo. La Generative Orchestration trasforma il routing da un fragile esercizio di phrase matching in una ricerca intelligente di funzionalità, liberandoti per poterti concentrare su ciò che il tuo agent può fare, invece di indovinare come l'utente lo chiederà.
Se vuoi supportare lo show, puoi trovarci cercando DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!
2
AI-Based Agent Authoring
3m 13sImpara a usare il linguaggio naturale per accelerare il processo di creazione del tuo bot. Esploriamo l'authoring di agenti basato sull'IA, che ti consente di generare Topics, Prompts e Flows complessi semplicemente descrivendoli. Comprendi come gli LLM vengono utilizzati in fase di build-time per prototipare rapidamente gli agenti.
Ciao, sono Alex di DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 2 di 15. Di solito, creare un flow conversazionale significa trascinare nodi su un canvas, collegare manualmente i logic tree e indovinare ogni possibile trigger phrase che il tuo utente finale potrebbe digitare. Ma cosa succederebbe se potessi semplicemente dire a un'IA esattamente cosa vuoi creare e lasciarle generare la logica strutturale per te? Questo meccanismo si chiama agent authoring basato sull'IA.
È fondamentale distinguerlo dal comportamento dell'IA a runtime. Gli sviluppatori spesso confondono l'IA generativa a build time con l'IA generativa a runtime. Il runtime è quando un utente reale fa una domanda e l'agent genera dinamicamente una risposta usando una knowledge base esterna. L'authoring a build time è completamente diverso. È quando usi un assistente IA all'interno dello studio per costruire il framework statico dell'agent stesso.
Inizi dal canvas di authoring. Invece di cliccare per aggiungere singoli elementi, interagisci con l'authoring pane di Copilot. Supponi di aver bisogno di un flow per gestire i resi hardware. Scrivi una semplice descrizione in inglese richiedendo un topic che chieda all'utente il suo numero d'ordine, verifichi se l'articolo è un laptop o un dispositivo mobile, e poi fornisca l'indirizzo di spedizione corretto per il reso in base al tipo di dispositivo.
Quando invii quel prompt, il modello di natural language understanding elabora le tue istruzioni e le mappa direttamente al node schema interno di Copilot Studio. Genera automaticamente una serie di trigger phrase diverse che un utente reale potrebbe pronunciare per avviare questo specifico flow. Posiziona un question node sul canvas per acquisire il numero d'ordine e gli assegna una variabile. Crea un condition node per ramificare la logica tra un laptop e un dispositivo mobile. Poi popola i message node finali con indirizzi di reso placeholder. L'intero scheletro del topic appare istantaneamente sul tuo schermo.
Ecco il punto chiave. Questo processo di authoring è rigorosamente iterativo. Non sei obbligato ad accettare la generazione iniziale come prodotto finale. Se guardi il flow generato e ti rendi conto di dover acquisire la data di acquisto, non devi interrompere manualmente i collegamenti e inserire un nuovo nodo. Ti basta dire al Copilot di authoring di aggiungere una domanda sulla data di acquisto subito prima di chiedere il numero d'ordine. Il modello sottostante analizza lo stato attuale del tuo canvas, comprende il punto di inserimento sequenziale e modifica il flow in modo sicuro.
Poiché l'IA traduce il linguaggio naturale direttamente in componenti standard di Copilot Studio, mantieni il controllo completo dell'architettura. I nodi generati non sono black box. Sono esattamente gli stessi elementi che avresti creato manualmente. Puoi cliccare nei condition branch, modificare i tipi di variabile o riscrivere a mano il testo del prompt. Il modello linguistico si occupa semplicemente dell'assemblaggio meccanico del canvas.
Il vero potere dell'authoring basato sull'IA non è che scriva flow conversazionali impeccabili al primo colpo, ma che trasforma il lento processo meccanico di node wiring in un dialogo rapido sull'intento di business. Grazie per averci fatto compagnia. Spero tu abbia imparato qualcosa di nuovo.
3
Topics e Nodes
3m 41sImmergiti nell'anatomia strutturale di un agente. Questo episodio analizza i System topics rispetto ai Custom topics e la logica deterministica dei Nodes necessaria per specifiche regole di business. Impara a mappare percorsi conversazionali precisi utilizzando variabili e condizioni.
Ciao, sono Alex di DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 3 di 15. Anche gli agenti AI più avanzati prima o poi hanno bisogno di una logica deterministica per specifiche business rule. Quando un cliente chiede informazioni sulla tua politica di reso o sugli orari del negozio, non puoi permetterti un'ipotesi probabilistica da parte di un language model. Hai bisogno di una risposta rigorosa e garantita. I Topic e i Node ti danno esattamente questo controllo strutturale.
Pensa a un topic come a un percorso di conversazione distinto. È un albero di dialogo predefinito che stabilisce esattamente come il tuo agente gestisce uno specifico intent. Il tuo agente nel suo complesso è essenzialmente una collezione di questi topic che lavorano insieme per instradare l'utente. Un punto di confusione frequente è la distinzione tra System topic e Custom topic. È più semplice di quanto sembri. I System topic gestiscono i comportamenti fondamentali dell'agente. Questi governano eventi principali come salutare un utente, terminare una conversazione, fare escalation verso un operatore umano o intercettare un errore quando l'agente non capisce l'input. Puoi modificarne il testo per adattarlo alla voce del tuo brand, ma non puoi eliminarli. Sono elementi permanenti dell'architettura di sistema. I Custom topic sono i percorsi che costruisci tu stesso, completamente sotto il tuo controllo, per gestire i tuoi specifici scenari di business.
All'interno di ogni topic, la conversazione viene eseguita dall'alto verso il basso attraverso singoli passaggi chiamati node. I node sono i blocchi funzionali del percorso. Per capire come interagiscono, immagina un Custom topic progettato per gestire le richieste sugli orari del negozio.
Quando l'utente innesca questo topic, il primo passaggio nel tuo flow potrebbe essere un Question node. Un Question node fa un prompt all'utente per ottenere informazioni e attende un tipo specifico di risposta. In questo caso, l'agente chiede quale città l'utente intende visitare. Quando l'utente risponde, il node cattura quella risposta.
Questo introduce il Variable management. Il Question node memorizza automaticamente la risposta dell'utente in una variable. Ora hai in memoria un pezzo distinto di state, che ti permette di instradare la conversazione dinamicamente in base a ciò che l'utente ha appena detto.
Ed è qui che la cosa si fa interessante. Invece di fornire una risposta generica, aggiungi un Condition node per valutare quella variable. Un Condition node funge da bivio logico. Controlla lo state attuale della tua variable rispetto alle regole che definisci tu. Se la città memorizzata è uguale a New York, il node dirige il flow lungo un branch. Se la città è uguale a Londra, dirige il flow lungo un altro. Puoi aggiungere tutti i branch di cui hai bisogno per i diversi state, più un fallback branch nel caso in cui la variable non corrisponda a nessuna città conosciuta.
Infine, alla fine di ogni branch condizionale, inserisci un Message node. Un Message node mostra semplicemente del testo o dei media all'utente. Il branch di New York raggiunge un Message node che indica che il negozio apre alle nove del mattino. Il branch di Londra raggiunge un Message node diverso che indica che il negozio apre alle dieci.
Facendo chaining dei node Question, Variable, Condition e Message, definisci esattamente il flow della logica. La cosa più importante da ricordare qui è che i topic isolano le tue business rule deterministiche in percorsi prevedibili, garantendo che il tuo agente risponda in modo affidabile quando la precisione conta più della generation.
Grazie per averci seguito. Alla prossima!
4
State e Variables
3m 39sDai una memoria al tuo agente. Scopri come lavorare con le Variables in Copilot Studio per passare il contesto tra i Topics, eliminando le domande ripetitive. Esploriamo anche l'uso delle environment variables per archiviare in modo sicuro i segreti di Azure Key Vault.
Ciao, sono Alex di DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 4 di 15. Il modo più rapido per frustrare un utente è fargli ripetere le informazioni che ti ha appena fornito. Se il tuo bot chiede un nome, attiva un nuovo workflow e poi chiede di nuovo il nome, la user experience si rompe del tutto. Il meccanismo che impedisce questa amnesia è lo State e le variabili.
Una variabile in Copilot Studio salva i dati estratti dall'utente o recuperati da un sistema di backend. La decisione più importante che prendi quando crei una variabile è definirne lo scope. Spesso chi ci ascolta confonde le variabili a livello di topic con le variabili globali. Una variabile a livello di topic è strettamente locale. Esiste solo finché il suo topic padre è attivo. Nel momento in cui quel topic termina, la variabile viene cancellata dalla memoria. Una variabile globale, invece, persiste per tutta la durata dell'intera conversazione. Qualsiasi topic può leggerla e qualsiasi topic può sovrascriverla.
È forte la tentazione di rendere ogni dato condiviso una variabile globale. Non farlo. L'abuso di variabili globali crea cambiamenti di state imprevedibili quando i topic si interrompono a vicenda. Invece, passa le variabili locali direttamente tra i topic. Pensa a un topic chiamato Greeting. Chiede all'utente il suo nome e lo salva in una variabile locale. Il saluto termina e il flow fa un redirect verso un nuovo topic chiamato Talk to Customer. Per portarti dietro il nome, configuri il topic Talk to Customer per ricevere valori da altri topic. Definisci una variabile di input su questo topic di destinazione. Poi, tornando al tuo topic Greeting, il nodo di redirect ti chiederà automaticamente di mappare un valore a quell'input. Passi la variabile locale del nome attraverso il nodo. Il topic di destinazione la intercetta, il bot continua la conversazione usando il nome corretto e il tuo global state rimane pulito. Quando quel topic di destinazione finisce il suo lavoro, può anche restituire dei valori al topic chiamante originale usando delle variabili di output.
Questo copre i dati generati durante una chat. Ora, la seconda parte riguarda i dati di cui il tuo agent ha bisogno prima ancora che inizi una chat. Se il tuo agent si connette a sistemi esterni, ha bisogno di credenziali. Non devi assolutamente mai salvare API key o connection string nelle variabili di conversazione. Per questo, usi le environment variables. Le environment variables vivono completamente al di fuori della sessione utente. Salvano dati di configurazione che si applicano all'agent stesso, permettendoti di spostare il tuo bot da un ambiente di development a uno di testing, e infine in production, senza fare hardcoding dei valori.
Presta attenzione a questa parte. Quando gestisci dati altamente sensibili, le environment variables si integrano direttamente con Azure Key Vault. Invece di incollare una password in Copilot Studio, crei una environment variable contrassegnata come secret. Questa variabile salva una reference a una chiave specifica nel tuo Azure Key Vault. Durante il runtime, l'agent recupera in modo sicuro il secret per autenticare la richiesta di backend. Il secret non viene mai esposto nell'authoring canvas, non viene mai stampato nei chat log, ed è escluso dalle tue esportazioni di source control.
Lo state più sicuro è uno state con scope, quindi mantieni le variabili di conversazione locali ogni volta che è possibile, passale esplicitamente tra i confini dei topic e delega sempre le credenziali di sistema a environment variables sicure. Grazie per l'ascolto, happy coding a tutti!
5
Entities e Slot Filling
4m 08sEstrai dati strutturati dal linguaggio naturale non strutturato. Questo episodio spiega le prebuilt entities, le custom closed lists, le regex entities e la magia del proactive slot filling, che consente all'IA di saltare le domande quando l'utente fornisce le informazioni in anticipo.
Ciao, sono Alex di DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 5 di 15. Hai creato un bot per prendere ordini, ma costringe gli utenti a passare attraverso cinque domande noiose. L'utente ti ha già fornito tutti i dettagli nel suo primo messaggio, eppure il tuo bot ignora quel contesto e continua a richiederli uno per uno. Questo comportamento rigido frustra gli utenti, ed è esattamente il problema risolto dalle Entities e dallo Slot Filling.
Le Entities sono il modo in cui Copilot Studio riconosce i soggetti del mondo reale dal linguaggio naturale disordinato. Pensa a un'entity come a uno specifico data type che il tuo bot è addestrato a individuare all'interno di una frase. Invece di analizzare l'intera frase "Vorrei spendere venti dollari", l'IA cerca semplicemente l'entity money ed estrae il valore venti.
Copilot Studio include un ampio set di prebuilt entities. Queste gestiscono i concetti di dati standard out of the box. Le prebuilt entities riconoscono età, date, colori, numeri, nomi e denaro. Normalizzano automaticamente i dati. Che l'utente digiti venti dollari, il simbolo del dollaro seguito da 20, o venti sacchi, la prebuilt entity money estrae l'esatto valore numerico e la valuta.
Ma il tuo business opera con una terminologia specifica. Per catturarla, devi creare delle custom entities. Ci sono due tipi principali di custom entities che utilizzerai. Il primo è la closed list entity. Definisci una lista rigorosa di elementi consentiti, e poi associ dei sinonimi a ciascun elemento. Se vendi attrezzatura outdoor, potresti creare un'entity per la categoria di prodotto con un elemento principale chiamato hiking. Aggiungi poi sinonimi come trekking, backpacking e trail walking. Quando l'utente digita uno di questi sinonimi, l'IA mappa il loro input direttamente al valore principale hiking.
Il secondo tipo custom è la regular expression, o regex entity. Usi le regex entities quando gli utenti devono fornire delle string formattate anziché parole specifiche. Un use case comune è un ticket di supporto o un order ID. Se il tuo sistema utilizza numeri di tracciamento che iniziano sempre con le lettere TRK seguite da cinque cifre, definisci quel pattern usando una regex. L'IA scansionerà il messaggio dell'utente ed estrarrà in modo pulito quell'esatta string, ignorando qualsiasi testo circostante.
Identificare l'entity è solo il primo passo. Devi memorizzare quei dati per poterli usare. Questa azione si chiama slot filling. Mappi un'entity estratta a una variabile, riempiendo lo slot con i dati dell'utente.
È qui che la cosa si fa interessante. Copilot Studio utilizza una feature chiamata proactive slot filling. Di default, il motore di natural language understanding valuta ogni messaggio dell'utente rispetto a tutte le variabili richieste dal tuo topic di conversazione. Se l'IA rileva le entities richieste nell'input iniziale dell'utente, riempie immediatamente quegli slot.
Considera un utente che triggera il tuo topic di acquisto dicendo: "Voglio comprare scarponi da hiking a meno di 100 dollari". Hai una custom closed list entity per la categoria di prodotto, e stai usando la prebuilt entity money per il budget. Grazie al proactive slot filling, l'IA elabora l'intera frase in una sola volta. Isola hiking, lo mappa alla tua variabile di categoria e lo memorizza. Isola 100 dollari, li mappa alla tua variabile di budget e li memorizza.
Poiché quegli slot sono già pieni, il bot salta automaticamente e del tutto i question node "Che categoria stai cercando?" e "Qual è il tuo budget?". Il flow di conversazione li salta a piè pari e passa direttamente alla successiva informazione mancante.
Definendo entities rigorose e affidandoti al proactive slot filling per gestire l'estrazione, smetti di scrivere decision tree rigidi e inizi a costruire agenti conversazionali che rispettano il tempo dell'utente.
Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!
6
Enterprise Knowledge Grounding
3m 57sTrasforma i tuoi dati aziendali esistenti in un esperto conversazionale. Impara a connettere SharePoint, Dataverse e siti web pubblici come fonti di Knowledge per le Generative Answers. Scopri i limiti e le capacità del grounding della tua IA.
Ciao, sono Alex di DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 6 di 15. La parte più difficile nel creare un agente conversazionale era prevedere ogni domanda dell'utente e scriverne manualmente le risposte. Passavi settimane a mappare gli alberi di dialogo, solo per poi vedere gli utenti fare domande leggermente fuori copione e finire in un vicolo cieco. L'Enterprise Knowledge Grounding ribalta completamente questo modello. Invece di scrivere le risposte, sono i tuoi dati aziendali esistenti a fare tutto il lavoro pesante.
Un large language model generico è molto articolato, ma non sa assolutamente nulla della tua azienda specifica. L'Enterprise Knowledge Grounding colma questa lacuna collegando il copilot direttamente ai tuoi dati aziendali reali, come siti web pubblici, directory SharePoint, file caricati e tabelle Dataverse.
Prendi ad esempio uno scenario di assistenza clienti. Hai bisogno di un agente che risponda alle domande sul tuo hardware. Invece di creare centinaia di custom topic, carichi i manuali PDF dei tuoi prodotti nel copilot e incolli l'URL del tuo sito di documentazione pubblica. Quando un utente chiede come resettare uno specifico modello di router, il copilot cerca in quelle fonti connesse, recupera il testo pertinente e sintetizza una risposta diretta. Fornisce anche un link di citazione al manuale o alla pagina web specifica, in modo che l'utente possa verificare le informazioni.
Un punto di confusione comune è dove risieda esattamente questa knowledge all'interno dell'architettura. Puoi collegare la knowledge in due posti distinti: a livello di agent o a livello di topic.
La knowledge a livello di agent è globale. Funge da rete di sicurezza per l'intero copilot. Se un utente fa una domanda e non viene triggerato nessun topic creato manualmente, il sistema fa un fallback su questo pool globale di knowledge. Cerca in tutte le tue fonti connesse a livello di agent per generare una risposta. Questo significa che ottieni un valore immediato senza scrivere alcun flusso di conversazione custom.
Ecco il punto chiave. A volte hai bisogno di un controllo rigoroso su quali dati usa l'IA, ed è qui che entra in gioco la knowledge a livello di topic. Puoi configurarlo trascinando un nodo Generative Answers direttamente nell'authoring canvas di uno specifico custom topic.
Se un utente triggera un custom topic per gestire una richiesta di garanzia, non vuoi che l'IA tiri fuori le risposte dal tuo sito web di marketing generale. Usando un nodo Generative Answers all'interno di quello specifico topic, puoi limitare la sua data source esclusivamente a una cartella SharePoint che contiene i documenti legali sulla garanzia. L'IA ha uno scope limitato esattamente al contesto di quello step della conversazione.
Quando connetti queste fonti aziendali, il sistema gestisce l'accesso in modo intelligente. Per i siti web pubblici, il copilot si limita a indicizzare le pagine pubbliche. Per le fonti interne come SharePoint, il copilot usa le credenziali Entra ID della persona che interagisce con il bot. Rispetta rigorosamente i permessi dei file esistenti. Se un dipendente non ha accesso a uno specifico documento interno su SharePoint, il copilot non leggerà quel documento e non lo userà per rispondere alla sua domanda.
Per i dati strutturati, puoi connetterti direttamente alle tabelle Dataverse, permettendo al copilot di fare grounding delle sue risposte sui record live delle tue applicazioni aziendali.
Usare un nodo Generative Answers all'interno di un custom topic ti permette di controllare rigorosamente i confini esatti della knowledge dell'IA in punti specifici di una conversazione, impedendo che dati globali generici vadano a sporcare workflow altamente specifici. Per questo episodio è tutto. Grazie per aver ascoltato, e continua a sviluppare!
7
Tenant Graph Grounding
3m 28sSprigiona tutta la potenza di Microsoft Graph e della ricerca semantica per un recupero ad alta precisione. Questo episodio esplora il Tenant Graph Grounding, utilizzando le licenze Microsoft 365 Copilot per cercare in enormi documenti aziendali con una profonda comprensione semantica.
Ciao, sono Alex di DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 7 di 15. La ricerca standard per keyword va in crisi nel momento in cui un utente fa una domanda complessa su una policy interna. Non ti servono keyword migliori. Ti serve un sistema in grado di comprendere il vero significato della domanda su enormi dataset. Ed è proprio qui che entra in gioco Tenant Graph Grounding.
Tenant Graph Grounding porta una profonda comprensione semantica direttamente ai tuoi dati aziendali. Innanzitutto, chiariamo un equivoco comune. Non si tratta di una ricerca standard su Dataverse e non ha nulla a che vedere con lo scraping di siti web pubblici. Si tratta di una funzionalità avanzata di retrieval aziendale che collega il tuo copilot direttamente a Microsoft Graph. È stata progettata specificamente per gestire la complessa conoscenza interna archiviata nel tuo tenant.
Per utilizzare questa feature, il tuo ambiente deve soddisfare alcuni requisiti stringenti. Ti serve una licenza Microsoft 365 Copilot. I tuoi dati devono essere indicizzati dal Semantic Index per Copilot. Ma la cosa più importante è che il tuo copilot deve essere configurato con l'autenticazione Microsoft Entra ID. Questo non è opzionale. Il copilot deve passare in modo sicuro l'identità della persona che fa la domanda a Microsoft Graph.
Pensa a un copilot interno per le Risorse Umane, progettato per cercare all'interno di enormi manuali per i dipendenti. Questi manuali spesso si trovano su SharePoint o OneDrive sotto forma di documenti enormi. I tool di retrieval standard spesso vanno in crisi con i file di grandi dimensioni, ma Tenant Graph Grounding supporta file fino a 512 megabyte. Quando un dipendente fa una domanda su uno scenario molto specifico, come la policy sul congedo parentale per un caregiver secondario che lavora part-time, un motore di ricerca tradizionale cerca esattamente quelle parole. Se il manuale utilizza una formulazione diversa, la ricerca fallisce.
Ecco il punto chiave. Dato che questa feature utilizza il Semantic Index, mappa le relazioni concettuali tra la query dell'utente e i dati aziendali. Capisce che la query sul congedo parentale corrisponde concettualmente a una sezione intitolata permessi per motivi familiari, anche se le keyword non combaciano perfettamente.
Il flusso logico opera interamente all'interno del perimetro di sicurezza del tuo tenant. Un utente invia un prompt al copilot. Il copilot usa il token di Entra ID di quello specifico utente per eseguire una query su Microsoft Graph. Microsoft Graph cerca quindi nel Semantic Index, ma analizza solo i file che quello specifico utente ha già il permesso di leggere. Se un documento ha delle restrizioni, il Graph semplicemente lo ignora per quell'utente.
Il Graph recupera i match semantici più rilevanti e li restituisce al copilot. Il copilot usa quindi esattamente quei chunk di dati per generare una risposta precisa e grounded. L'intera transazione avviene con una precisione quasi istantanea, bypassando la latenza e l'imprecisione di dover creare i tuoi indici di ricerca custom sui dati di SharePoint.
Tenant Graph Grounding sposta l'intero carico di retrieval dalla tua logica custom direttamente sull'infrastruttura semantica di Microsoft 365, garantendo che il tuo copilot rispetti i confini dei dati aziendali esistenti, offrendo al contempo un'accuratezza contestuale senza pari. Se vuoi supportare il podcast, puoi trovare DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto e continua a sviluppare!
8
Prompt Tools
3m 33sConsenti al tuo agente di eseguire al volo compiti specifici di elaborazione dati o riepilogo. Impara a creare Prompt Tools, definire template, specificare input e impostare formati di risposta direttamente all'interno di Copilot Studio.
Ciao, sono Alex di DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 8 di 15. A volte non hai bisogno di creare un'API complessa o integrare un servizio di parsing esterno per elaborare i dati in arrivo. Ti basta un Large Language Model per analizzare una string di testo disordinata ed elaborarla esattamente come vuoi tu. È qui che entrano in gioco i Prompt Tool.
Innanzitutto, dobbiamo chiarire un dubbio molto comune. I Prompt Tool sono completamente diversi dalle Generative Answers. Le Generative Answers analizzano una knowledge base esterna o un sito web per rispondere dinamicamente alle domande degli utenti. I Prompt Tool non cercano risposte. Sono istruzioni specifiche e altamente ingegnerizzate che dicono a un Large Language Model di eseguire un task rigorosamente definito sui dati che gli fornisci.
Pensa a un Prompt Tool come a una function riutilizzabile in cui la logica sottostante è scritta in linguaggio naturale anziché in codice. Lo crei definendo un prompt template, specificando le variabili di input e fornendo regole di contesto rigorose.
Considera uno scenario comune. Ricevi un blocco di feedback non strutturato e confuso da un cliente. Vuoi estrarre il sentiment di fondo e generare una lista pulita di action item specifici. Invece di scrivere complesse regular expression o uno script di parsing personalizzato, crei un Prompt Tool.
Inizi definendo gli input. In Copilot Studio, crei una variabile di input chiamata feedback text e imposti il suo data type. Questo semplice passaggio dice al tool di aspettarsi una string dinamica ogni volta che viene invocato dal sistema.
Successivamente, scrivi il prompt template. Questo è il set di istruzioni principale inviato al language model. Scrivi con precisione cosa deve fare il modello. Gli indichi di leggere la variabile feedback text, determinare se il tono è positivo, negativo o neutro, e identificare eventuali task che il team di customer support deve gestire in base al testo.
Ecco il punto chiave. Il template è praticamente inutile senza un contesto rigoroso. Non ti limiti a chiedere al modello il sentiment sperando che risponda bene. Definisci l'esatta struttura di output all'interno del contesto del prompt. Istruisci esplicitamente il modello a restituire il risultato formattato come un oggetto JSON rigoroso, contenente una chiave sentiment e un array di action item. Vieti le frasi di riempimento. Questo contesto trasforma una risposta generica e colloquiale del language model in un payload di dati strutturato e prevedibile che i tuoi sistemi a valle possono effettivamente parsare.
Quando il tuo agent attiva questo tool durante una conversazione live, il flusso di esecuzione è completamente automatizzato. L'agent prende la risposta live del cliente e la passa nel tuo input feedback text. Il tool inietta dinamicamente quella string nel tuo template, invia il pacchetto di istruzioni completo al modello e ti restituisce il JSON strutturato. L'agent può quindi utilizzare quegli action item estratti per aggiornare automaticamente un database o indirizzare l'utente a una coda di supporto specializzata.
Definisci il tool una sola volta, e l'agent lo chiama automaticamente ogni volta che riconosce la necessità di elaborare testo non strutturato. Un Prompt Tool ben progettato sposta l'onere dell'elaborazione di testo complesso dal codice della tua applicazione al language model, permettendoti di estrarre dati perfettamente strutturati dal caos più totale utilizzando solo poche righe di semplice inglese. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!
9
Agent Flows
3m 43sCollega Copilot Studio ad automazioni di backend complesse e multi-step utilizzando gli Agent Flows. Questo episodio illustra nel dettaglio come aggiungere i flussi di Power Automate come Tools, ponendo l'accento sul limite critico di esecuzione di 100 secondi e sui requisiti di risposta sincrona.
Ciao, sono Alex di DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 9 di 15. Il tuo agente deve eseguire un workflow backend complesso che coinvolge più sistemi. Magari deve interrogare un database isolato, filtrare i dati e aggiornare un sistema di inventario, tutto in una volta. Una singola API call non può gestire questa orchestrazione. La soluzione è un Agent Flow.
Gli Agent Flow collegano Copilot Studio con Power Automate. Ti permettono di pacchettizzare un'automazione multi-step come un tool standalone che il tuo agente può triggerare in modo autonomo. L'agente si basa interamente sul nome e sulla descrizione che fornisci per il flow. In base a questo testo, l'agente decide se il flow può risolvere la richiesta corrente dell'utente. Quando trova un match, l'agente estrae i parametri necessari dalla conversazione, li passa al flow, attende l'esecuzione e usa l'output finale per generare una risposta.
La struttura di un Agent Flow è rigida. Deve iniziare con un trigger specifico progettato per Copilot, che definisce esplicitamente gli input di tipo text o number. Deve terminare con un'azione specifica che risponde a Copilot, definendo gli output di tipo text o number. Tutto ciò che si trova tra questi due nodi è logica standard di Power Automate. Puoi ciclare sugli array, chiamare custom connector o parsare file.
Considera uno scenario in cui il tuo agente deve recuperare lo storico degli ordini da un database SQL legacy. L'utente chiede i suoi ordini recenti. L'agente triggera il flow, passando la stringa del customer ID come input. All'interno del flow, costruisci la logica per connetterti al database SQL, eseguire la query e formattare le righe grezze del database in una stringa JSON pulita. Il flow quindi ripassa quella stringa formattata all'agente attraverso il nodo di response. L'agente legge la stringa, estrae i dettagli dell'ordine e risponde all'utente in linguaggio naturale.
Ecco il punto chiave. L'esecuzione deve essere completamente sincrona. L'agente avvia il flow e mantiene la connessione aperta, in attesa della response. Se costruisci un flow asincrono, non funzionerà come tool per l'agente. Non puoi includere step che mettono in pausa la logica. Se il tuo flow invia un'email di approvazione e aspetta che un umano clicchi su un pulsante, l'agente andrà in errore. Il pattern del tool richiede un ritorno immediato dei dati.
Questo ci porta a un hard limit di sistema. Hai esattamente cento secondi. Dal momento in cui l'agente triggera il flow, la logica ha cento secondi per eseguire ogni step, fare la query sul database, formattare l'output e rimandare indietro la response. Se il server SQL legacy è sotto carico, o se il tuo flow itera su troppi record, l'esecuzione supererà il limite di timeout. Quando questo accade, l'agente fa cadere completamente la connessione e restituisce un messaggio di errore all'utente.
Per gestire questo limite, devi mantenere l'automazione con uno scope molto ristretto. Se un processo di backend richiede cinque minuti, non eseguirlo all'interno dell'Agent Flow. Usa invece il flow per avviare un background job esterno e restituire immediatamente un tracking ID all'agente.
La tua architettura di automazione deve rispettare la finestra di timeout. Progetta i tuoi flow in modo che vengano eseguiti rapidamente, recuperino esattamente ciò che è necessario e restituiscano il controllo all'agente, assicurandoti che l'utente non venga mai lasciato a parlare con una connessione bloccata.
Questo è tutto per questo episodio. Grazie per l'ascolto e continua a sviluppare!
10
Power Platform Connectors
4m 01sAttingi a migliaia di API esistenti negli ecosistemi Microsoft e di terze parti. Scopri come utilizzare i Power Platform Connectors come Tools attivi nei tuoi agenti Copilot Studio per interagire con servizi esterni senza alcuno sforzo.
Ciao, sono Alex di DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 10 di 15. Passi giornate a scrivere e mantenere integrazioni API custom solo per permettere al tuo agent di comunicare con il mondo esterno. Nel frattempo, migliaia di wrapper predefiniti sono già lì nel tuo environment, in attesa di essere eseguiti. Oggi parliamo dei Power Platform Connector.
I connector sono wrapper API standardizzati. Forniscono a Microsoft Copilot Studio un modo prevedibile per comunicare con i servizi esterni. Prima di vedere come funzionano, dobbiamo chiarire un equivoco comune. Spesso gli utenti confondono l'uso di un sistema esterno come knowledge source rispetto all'usarlo come tool. Se il tuo agent fa una query su un database solo per recuperare fatti e fare grounding delle sue risposte conversazionali, quella è passive knowledge. Usare un connector come tool è diverso. È un'operazione attiva. Stai dando all'agent l'autorità di eseguire action, creare record o triggerare processi esterni per conto dell'utente.
Ci sono tre categorie di connector disponibili. Gli standard connector coprono i servizi Microsoft di base e i comuni endpoint pubblici. I premium connector richiedono licenze specifiche e si connettono a sistemi enterprise come Salesforce o ServiceNow. Se il sistema da raggiungere è un'API proprietaria interna, puoi creare un custom connector. Un custom connector è semplicemente un wrapper OpenAPI che definisci tu stesso. Una volta registrato nel tuo environment, si comporta esattamente come quelli standard e premium. All'agent non importa chi lo ha creato.
Vediamo come gira questa logica usando uno scenario concreto. Vuoi che il tuo agent compili un summary del progetto e lo mandi via email al tuo team di engineering. Invece di costruire a mano una request HTTP, aggiungi l'Office 365 Outlook connector direttamente nel tuo copilot come action. Ogni connector espone operation specifiche. In questo caso, selezioni l'action per inviare un'email.
Questa è la parte che conta. Non scrivi codice procedurale per dettare esattamente quando viene inviata questa email. Invece, definisci i parametri che il connector richiede per funzionare. L'Outlook connector richiede un indirizzo di destinazione, un subject e il body del messaggio. Configuri questi input e fornisci una descrizione chiara e in linguaggio naturale di cosa fa l'action.
Copilot si affida interamente a quella descrizione per determinare quando triggerare il tool. Quando un utente dice all'agent di inviare il weekly status update al team di engineering, l'agent valuta i tool a sua disposizione. Fa il match tra la request dell'utente e la descrizione del tuo Outlook connector. L'agent quindi estrae dinamicamente il nome del destinatario e il testo del summary dalla conversazione in corso. Mappa questi valori estratti sugli input del connector e lancia l'action.
Una volta che l'API esterna processa la request, il connector passa una response indietro all'agent. Potrebbe trattarsi di un semplice success code o di un payload con dettagli specifici sulla transazione. L'agent riceve questi dati, verifica che l'action sia stata completata e genera una response in linguaggio naturale per dire all'utente che l'email è stata inviata.
Standardizzando l'interfaccia, questi wrapper eliminano la necessità di gestire authentication token, header ed error handling per ogni singolo servizio. Configuri la connection una volta sola, e l'agent orchestra l'esecuzione. I connector trasformano il tuo agent da un'interfaccia conversazionale statica a un tool operativo che altera effettivamente lo stato in tutta la tua infrastruttura. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!
11
Il Computer Use Tool
2m 28sAutomatizza i sistemi legacy privi di API utilizzando l'automazione basata sulla visione. Scopri l'anteprima del Computer Use Tool, che sfrutta modelli come Claude Sonnet 4.5 per interagire con le interfacce grafiche tramite mouse e tastiera virtuali, completo di guardrail di sicurezza aziendale.
Ciao, sono Alex di DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 11 di 15. Se un'applicazione non ha un'API, l'automazione tradizionale sbatte contro un muro. O scrivi script fragili che si rompono appena un pulsante si sposta, oppure accetti l'inserimento manuale dei dati. Il tool Computer Use risolve questo problema permettendo alla tua AI di vedere letteralmente lo schermo e di operare direttamente sulla macchina.
Disponibile in preview, questa feature permette al tuo agent di interagire con un'interfaccia grafica usando un mouse e una tastiera virtuali. Si basa sui Computer-Using Agents, alimentati da modelli con capacità di vision come Claude 3.5 Sonnet di Anthropic. È necessario chiarire cosa non è. Questa non è la tradizionale Robotic Process Automation. La RPA standard si basa su hook strutturali sottostanti, come i tag del DOM o gli ID degli elementi della UI. Il tool Computer Use opera interamente sui pixel.
Il flusso logico è un loop continuo. Il tool cattura uno screenshot dell'ambiente desktop e lo passa al modello. Il modello analizza il layout visivo, ragiona sulla richiesta dell'utente e calcola le coordinate precise per la sua prossima mossa. Restituisce quindi in output delle istruzioni al sistema. Il sistema le traduce spostando il cursore virtuale in una specifica posizione X e Y, facendo click con il mouse, o inviando una string di keystroke. Dopo aver eseguito l'azione, il tool fa un altro screenshot per valutare il nuovo stato dello schermo, verificando se si è aperta una finestra o se è apparso del testo, prima di decidere il suo prossimo step.
Immagina uno scenario in cui devi estrarre dati da un'applicazione desktop Windows legacy e inserirli in un form web moderno. L'agent guarda lo screenshot dell'app legacy, individua visivamente il numero di fattura e memorizza quell'informazione. Poi manda in output le istruzioni per spostare il mouse sulla finestra del browser, fare click all'interno del campo target del form web e digitare le cifre. Naviga l'interfaccia esattamente come farebbe un operatore umano, guidato interamente dal contesto visivo sul display.
Dare a un modello AI il controllo fisico di un desktop richiede controlli di sicurezza rigorosi. Ecco il punto chiave. Non fai mai il deploy su un server di produzione o sulla workstation principale di un utente. L'agent deve operare all'interno di una virtual machine o di un container dedicati e isolati. Concedi a questo ambiente i privilegi minimi assoluti richiesti per completare il task specifico. Dato che il modello può navigare sui web browser da solo, devi applicare controlli di rete rigorosi. Applichi una allow list di URL in modo che l'agent possa accedere solo ai domini approvati, impedendogli di interagire con siti web non attendibili o servizi esterni. Ti assicuri anche che la virtual machine non contenga dati sensibili al di fuori del workload immediato.
Trattando l'interfaccia grafica come un semplice stream di input visivo, colmi il divario tra il ragionamento intelligente e il software legacy inaccessibile senza scrivere una singola riga di codice di integrazione. Per questo episodio è tutto. Grazie per l'ascolto, e continua a sviluppare!
12
User Authentication
3m 12sMetti in sicurezza il tuo agente e sblocca esperienze personalizzate. Approfondisci la User Authentication in Copilot Studio, confrontando 'Authenticate with Microsoft' con le configurazioni Manual OAuth2. Impara a configurare gli scope e a garantire l'accesso con privilegi minimi.
Ciao, sono Alex di DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 12 di 15. Un agente è potente tanto quanto i dati a cui può accedere. Ma se il tuo agente fa una query a un sistema privato e accidentalmente mostra il tuo calendario personale a un altro dipendente, hai un'enorme falla di sicurezza. Per evitarlo, devi configurare correttamente la User Authentication.
L'errore più comune che i developer fanno qui è confondere le credenziali del maker con quelle dell'end-user. Se inserisci le tue API key o le credenziali del service principal in un'action dell'agente, il bot esegue quelle action come se fossi tu. Ogni persona che chatta con l'agente bypasserà i propri limiti di sicurezza e accederà ai dati usando i tuoi permessi. La User Authentication forza l'agente a eseguire le query esattamente come la persona che digita il prompt, basandosi interamente sulla sua identità univoca.
In Copilot Studio, scegli principalmente tra due stati di autenticazione: Authenticate with Microsoft e Authenticate manually. Authenticate with Microsoft è il percorso semplificato per i tool interni. Se il tuo agente opera esclusivamente all'interno di Microsoft Teams o Power Apps, questo setting usa automaticamente il token di Microsoft Entra ID della persona attualmente loggata nell'applicazione. Non c'è nessun login prompt separato. Lo user context passa semplicemente all'agente.
Passi ad Authenticate manually quando il tuo agente vive su un sito web esterno custom, o quando ti serve un controllo stretto e granulare sui permessi. Questo metodo si basa sul setup di una connessione OAuth2 a un identity provider, che in genere è un'App Registration in Microsoft Entra ID.
Prendi uno scenario concreto. Stai sviluppando un agente che controlla l'agenda personale di un dipendente. Configuri Authenticate manually e lo colleghi alla tua App Registration di Entra ID. Ecco il punto chiave. L'agente non ottiene un accesso illimitato all'intero account Microsoft dell'utente. Invece, definisci degli scope rigorosi nella tua configurazione. Configuri il nodo di autenticazione per richiedere uno scope specifico chiamato Calendars dot Read.
Quando un utente chiede all'agente la sua agenda, l'agente mette in pausa la sua logica e mostra una sign-in card nella chat. L'utente clicca sul link, si autentica tramite il browser e vede una schermata che gli chiede di concedere all'agente l'accesso in lettura al suo calendario. Una volta dato il consenso, Microsoft Entra ID genera un access token e lo passa in modo sicuro all'agente.
Questo access token è strettamente legato a quel singolo utente ed è limitato esclusivamente allo scope del calendario. Quando l'agente fa l'effettiva HTTP request per recuperare l'agenda, include questo token. La backend API ispeziona il token, conferma l'identità dell'utente e restituisce in modo sicuro solo i suoi specifici eventi del calendario. Configurare bene la User Authentication è ciò che trasforma un chatbot generico in un assistente personalizzato, provando ai tuoi sistemi di backend esattamente chi sta chiedendo i dati, così non fai mai leak di informazioni private tra le sessioni.
Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.
13
Voice e IVR
4m 00sAllontana il tuo agente dalla tastiera e portalo sulla linea telefonica. Scopri le funzionalità di Interactive Voice Response (IVR) di Copilot Studio. Scopri lo speech recognition, il DTMF (input da tastierino), il barge-in e la personalizzazione delle voci degli agenti con SSML.
Ciao, sono Alex di DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 13 di 15. Il futuro del servizio clienti non si limita al testo sullo schermo. Le persone chiamano ancora i servizi di assistenza e, quando lo fanno, si aspettano una risposta immediata e intelligente, non un albero di menu infinito. Colmare questo divario richiede di connettere la tua IA direttamente alle reti telefoniche. Ed è proprio di questo che parleremo oggi: voce e IVR.
Prendere un agent creato in Copilot Studio e farlo rispondere al telefono significa configurarlo per un canale telefonico, generalmente tramite Dynamics 365 o Azure Communication Services. Questo trasforma la tua logica in un sistema Interactive Voice Response, basandosi sulla speech recognition nativa per convertire l'audio del chiamante in testo e su motori text-to-speech per rispondere. Ma tradurre la logica della chat in logica vocale richiede di gestire gli aspetti pratici di una chiamata telefonica.
Pensa a un cliente che chiama un servizio di assistenza. Il bot risponde e inizia a leggere un saluto legale obbligatorio o un elenco di opzioni. Il chiamante sa già di dover parlare con l'ufficio fatturazione. Se si trattasse di una chat testuale, basterebbe digitare la domanda. Al telefono, invece, il chiamante parla sopra il bot. Questo richiede una feature chiamata Barge-in. Senza Barge-in abilitato, il sistema ignora l'audio in entrata finché il bot non ha terminato completamente il suo playback. Con Barge-in attivo, lo speech recognizer ascolta simultaneamente. Nel momento in cui rileva che l'utente sta parlando, interrompe immediatamente l'output text-to-speech del bot ed elabora l'audio in entrata. Questo riproduce il flusso naturale di una conversazione umana ed evita che i chiamanti si sentano intrappolati da una macchina.
Dopo aver interrotto il bot, il chiamante riceve un prompt per inserire il numero di conto. Potrebbe pronunciare i numeri ad alta voce, ma magari si trova in una stanza affollata. Invece, li digita sullo schermo. Questo ci porta al DTMF, o Dual-Tone Multi-Frequency. Spesso si confonde la gestione del DTMF con i text input standard, ma si tratta di meccanismi completamente separati. Il DTMF gestisce le interazioni tramite tastiera telefonica a livello globale su tutta la rete telefonica. Quando un chiamante preme un tasto, la rete invia un tono a una frequenza specifica. Copilot Studio cattura direttamente questi toni. Configuri i nodi di input per ascoltare le sequenze DTMF, estrarre le cifre risultanti e memorizzarle come variabili. Puoi imporre un numero massimo di cifre, impostare dei timeout e definire un termination character, ad esempio indicando all'utente di premere il tasto cancelletto al termine della digitazione.
Ecco il punto chiave. Catturare semplicemente l'input non è sufficiente; il modo in cui il tuo agent risponde determina se il chiamante riaggancia. Il text-to-speech di default può risultare piatto. Per risolvere questo problema, usi SSML, o Speech Synthesis Markup Language. Invece di inviare plain text al voice engine, racchiudi le tue risposte in tag di markup. SSML ti permette di controllare il pitch, regolare lo speaking rate e imporre pronunce specifiche. Se il nome della tua azienda è un acronimo, puoi usare SSML per forzare l'engine a leggerlo lettera per lettera anziché indovinare come si pronuncia come parola. Puoi inserire silenzi precisi, aggiungendo una pausa di mezzo secondo dopo un'istruzione complessa per consentire al chiamante di elaborare le informazioni.
Sviluppare per la voce richiede di trattare la linea telefonica come un'interfaccia unica, tenendo conto delle interruzioni, dei toni della tastiera e dell'audio pacing. I voice agent più efficaci non costringono gli utenti in menu audio rigidi; combinano un barge-in fluido e una gestione precisa del DTMF semplicemente per non intralciare il chiamante. Grazie per l'ascolto. Alla prossima!
14
Agent Analytics
3m 10sNon puoi migliorare ciò che non misuri. Questo episodio analizza la dashboard Analytics in Copilot Studio, spiegando la vista ibrida per le sessioni conversazionali rispetto a quelle autonome, e come esportare le trascrizioni per un'analisi approfondita.
Ciao, sono Alex di DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 14 di 15. Finalmente fai il deploy del tuo agent, lo testi tu stesso e tutto sembra perfetto. Una settimana dopo, la soddisfazione degli utenti cala e i processi in background falliscono silenziosamente. Il problema non è la tua build iniziale, è la mancanza di visibilità sul comportamento in produzione. Il tool per risolvere questo problema è Agent Analytics.
Agent Analytics fornisce una view unificata delle performance del tuo agent una volta che gestisce workload reali. La prima cosa che vedi è la pagina di Summary. Questa funge da centro di controllo. Aggrega KPI come sessioni totali, engagement rate, resolution rate ed escalation rate. Invece di tirare a indovinare se il tuo agent sta aiutando gli utenti, gli AI insight del Summary analizzano l'intent dell'utente e ti mostrano esattamente quali topic portano a risoluzioni positive e quali invece spingono gli utenti ad abbandonare la sessione o a chiedere un operatore umano.
Ecco il punto chiave. Copilot Studio traccia due tipi di sessioni fondamentalmente diversi e la dashboard li presenta in una view ibrida. Primo, hai le sessioni conversazionali. Sono esattamente quello che sembrano. Un utente apre una finestra di chat e interagisce con l'agent. Le analytics tracciano i turni di dialogo, il sentiment dell'utente e il triggering dei topic. Secondo, hai le sessioni autonome. Queste girano interamente in background. Sono triggerate da eventi esterni, come la creazione di un nuovo record in un database o un'email in arrivo, non da un utente che digita un messaggio. Non c'è un'interfaccia di chat. Le analytics tracciano se l'agent ha completato con successo la sua logica in background o se è andato in errore.
Ti servono entrambe le view per mantenere un agent in salute. Considera uno scenario in cui stai controllando questa dashboard ibrida. Le tue metriche conversazionali sembrano a posto, ma noti un picco improvviso nei failure rate. Filtrando per tipo di sessione, scopri che gli errori si verificano tutti nelle sessioni autonome. Un processo triggerato da un evento, che dovrebbe aggiornare gli stati degli ordini, sta fallendo in background. La dashboard di Summary ti dice che c'è un errore, ma non ti dice l'esatta riga di logica che lo ha causato.
È qui che passi dalla dashboard ai dati raw. Copilot Studio salva log di esecuzione dettagliati in Microsoft Dataverse sotto forma di transcript. Scarichi il transcript specifico per la sessione autonoma fallita. Leggere il transcript ti dà il trace passo-passo dell'esecuzione. Puoi vedere l'esatta variabile che ha passato un valore non valido, individuare il node che fallisce e fixare la logica senza dover ricreare l'errore alla cieca.
La dashboard ti dice dove guardare, ma il transcript ti dice cosa fixare. Se vuoi aiutare a mantenere in vita questi approfondimenti tecnici, puoi supportare lo show cercando DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto e continua a sviluppare!
15
Model Context Protocol
3m 36sPrepara i tuoi agenti per il futuro con lo standard aperto per il contesto IA. Impara a integrare Copilot Studio con server Model Context Protocol (MCP) esterni per acquisire dinamicamente Resources, Tools e Prompts.
Ciao, sono Alex di DEV STORIES DOT EU. Microsoft Copilot Studio, episodio 15 di 15. Passi settimane a creare plugin personalizzati per permettere al tuo agent di interrogare i tuoi database interni e attivare azioni. Poi viene lanciata una nuova piattaforma e ti ritrovi a riscrivere da zero esattamente le stesse integrazioni. La soluzione a questo ciclo infinito di lavoro ridondante è il Model Context Protocol.
Il Model Context Protocol, o MCP, è uno standard aperto che connette i modelli AI a data source e tool esterni. Adottando uno standard aperto, rendi i tuoi agent a prova di futuro. Scrivi la logica di integrazione una volta sola, la ospiti su un server MCP, e qualsiasi client AI compatibile può usarla all'istante. Copilot Studio agisce come uno di questi client.
Immagina uno scenario in cui il tuo team di engineering si affida a 50 diversi script diagnostici interni e file di log in real-time. Non vuoi creare e mappare a mano 50 azioni separate dentro Copilot Studio. Invece, configuri il tuo agent per connettersi direttamente al tuo server MCP interno proprietario. Quando l'agent si inizializza, chiede al server cosa può fare. Il server risponde con una lista di capability, garantendo subito all'agent l'accesso a tutti e 50 i tool di engineering e alle resource dei file live.
Un server MCP espone tre componenti principali al tuo agent. Questi sono Resource, Tool e Prompt. Le Resource sono data source in sola lettura. Quando il tuo agent ha bisogno di controllare un file di configurazione live o un record a database, il server MCP fornisce quei dati come resource, caricandoli direttamente nel context del modello. I Tool sono funzioni eseguibili. Se l'agent decide che deve riavviare una macchina virtuale o aggiornare un ticket di engineering, chiama il tool MCP appropriato e il server esterno esegue l'azione. I Prompt sono template di istruzioni predefiniti forniti dal server. Guidano l'agent esattamente su come formattare le query o interpretare i dati specifici per quel sistema esterno.
Ecco il punto chiave. Spesso si pensa che, quando connetti un server MCP, Copilot Studio importi e salvi copie permanenti di quei tool nella sua interfaccia utente. Non è così che funziona. I tool e le resource sono ospitati in modo completamente esterno. Copilot Studio legge dinamicamente ciò che il server espone a runtime. Se il tuo team di engineering aggiunge un cinquantunesimo tool diagnostico, o modifica i parametri di uno script esistente, gli basta aggiornare il server MCP esterno. Copilot Studio riflette automaticamente queste modifiche. Non devi mai loggarti nell'interfaccia di Studio per ripubblicare o aggiornare l'azione.
Dato che la logica risiede interamente sul server, mantieni una single source of truth per i dati e le azioni della tua organizzazione. L'agent rimane leggero, funzionando semplicemente da reasoning engine che decide quando comunicare con il server.
Separando i tuoi tool dalla specifica piattaforma dell'agent, centralizzi le tue integrazioni e garantisci che la tua AI abbia sempre le capability più recenti, indipendentemente dall'interfaccia client di cui fai il deploy. Ti incoraggio vivamente a leggere la documentazione ufficiale, provare a connettere un server MCP hands-on, o visitare devstories dot eu per suggerire argomenti che vorresti vedere trattati in una serie futura. Per questo episodio è tutto. Grazie per l'ascolto, e continua a sviluppare!