Season 7 15 Episoade 58 min 2026

Microsoft Copilot Studio

Ediția 2026. O analiză tehnică aprofundată a Microsoft Copilot Studio, acoperind generative orchestration, agent flows, tools, enterprise grounding și multe altele (2026).

Framework-uri AI/ML Orchestrare LLM Prototipare vizuală

🌐 English 🇪🇸 Español 🇫🇷 Français 🇵🇹 Português 🇮🇹 Italiano 🇵🇱 Polski 🇩🇪 Deutsch 🇷🇴 Română

Se redă acum

Click play to start

0:00

Generative Orchestration

Descoperă schimbarea de paradigmă de la frazele de declanșare clasice (trigger phrases) la Generative Orchestration în Microsoft Copilot Studio. Află cum inteligența artificială selectează dinamic topics și tools pe baza descrierilor, eliminând complet nevoia unei mapări conversaționale rigide. Acest episod explică modul în care rutarea inteligentă gestionează fără efort interogările cu intenții multiple (multi-intent).

3m 55s

AI-Based Agent Authoring

Învață cum să folosești limbajul natural pentru a accelera procesul de creare a boților. Explorăm AI-based agent authoring, care îți permite să generezi topics, prompts și flows complexe pur și simplu descriindu-le. Înțelege cum sunt utilizate modelele LLM la momentul compilării (build-time) pentru a prototipa rapid agenți.

3m 45s

Topics și Nodes

Pătrunde în anatomia structurală a unui agent. Acest episod analizează diferența dintre System topics și Custom topics, precum și logica deterministă a nodurilor (node logic) necesară pentru reguli de business specifice. Învață cum să planifici rute conversaționale precise folosind variables și conditions.

3m 50s

State și Variables

Oferă-i agentului tău o memorie. Descoperă cum să lucrezi cu variables în Copilot Studio pentru a transmite contextul între topics, eliminând întrebările repetitive. De asemenea, explorăm utilizarea environment variables pentru stocarea în siguranță a secretelor din Azure Key Vault.

3m 47s

Entities și Slot Filling

Extrage date structurate din limbaj natural nestructurat. Acest episod explică prebuilt entities, custom closed lists, regex entities și magia proactive slot filling, care permite inteligenței artificiale să sară peste întrebări atunci când utilizatorul oferă informațiile de la bun început.

4m 23s

Enterprise Knowledge Grounding

Transformă datele existente ale companiei tale într-un expert conversațional. Învață cum să conectezi SharePoint, Dataverse și site-uri web publice ca surse de cunoștințe (knowledge sources) pentru Generative Answers. Descoperă limitele și capacitățile de grounding pentru AI-ul tău.

4m 15s

Tenant Graph Grounding

Dezlănțuie întreaga putere a Microsoft Graph și a căutării semantice (semantic search) pentru o extragere a datelor de înaltă precizie. Acest episod explorează Tenant Graph Grounding, utilizând licențele Microsoft 365 Copilot pentru a căuta în documente masive de tip enterprise cu o înțelegere semantică profundă.

4m 01s

Prompt Tools

Oferă-i agentului tău capacitatea de a efectua din mers sarcini specifice de procesare a datelor sau de rezumare. Învață cum să creezi Prompt Tools, să definești templates, să specifici inputs și să setezi formatele de răspuns direct în Copilot Studio.

3m 49s

Agent Flows

Conectează Copilot Studio cu automatizări backend complexe, în mai mulți pași, folosind Agent Flows. Acest episod detaliază modul în care poți adăuga fluxuri Power Automate ca tools, subliniind limita critică de execuție de 100 de secunde și cerințele pentru răspunsuri sincrone.

4m 12s

Power Platform Connectors

Accesează mii de API-uri existente din ecosistemul Microsoft și de la terți. Descoperă cum să folosești Power Platform Connectors ca tools active în agenții tăi din Copilot Studio pentru a interacționa fără efort cu servicii externe.

4m 13s

Computer Use Tool

Automatizează sistemele legacy care nu au API-uri folosind automatizarea bazată pe viziune (vision-based automation). Descoperă versiunea preview a Computer Use Tool, care utilizează modele precum Claude Sonnet 4.5 pentru a interacționa cu interfețele grafice prin intermediul unui mouse și al unei tastaturi virtuale, completat cu măsuri de securitate enterprise (security guardrails).

3m 33s

User Authentication

Securizează-ți agentul și deblochează experiențe personalizate. Aprofundează User Authentication în Copilot Studio, comparând 'Authenticate with Microsoft' cu configurările Manual OAuth2. Învață cum să configurezi scopes și să asiguri accesul cu cele mai mici privilegii (least privilege access).

3m 41s

Voice și IVR

Mută-ți agentul de la tastatură pe linia telefonică. Descoperă capacitățile Interactive Voice Response (IVR) din Copilot Studio. Învață despre speech recognition, DTMF (intrări de la tastatură), barge-in și personalizarea vocilor agenților cu SSML.

4m 10s

Agent Analytics

Nu poți îmbunătăți ceea ce nu măsori. Acest episod analizează dashboard-ul Analytics din Copilot Studio, explicând vizualizarea hibridă pentru sesiunile conversaționale versus cele autonome, și cum să exporți transcripts pentru o analiză detaliată.

3m 26s

Model Context Protocol

Pregătește-ți agenții pentru viitor cu standardul deschis pentru contextul AI. Învață cum să integrezi Copilot Studio cu servere externe Model Context Protocol (MCP) pentru a prelua dinamic Resources, Tools și Prompts.

3m 57s

Episoade

Generative Orchestration

3m 55s

Descarcă

Salut, sunt Alex de la DEV STORIES DOT EU. Microsoft Copilot Studio, episodul 1 din 15. Majoritatea developerilor de boți petrec ore întregi încercând să prezică și să mapeze fiecare frază posibilă pe care un user ar putea să o scrie. Adaugi cincizeci de variații pentru un support request, iar sistemul tot eșuează când cineva scrie o frază pe care nu ai anticipat-o. Generative Orchestration elimină complet această nevoie folosind dynamic description matching. Adesea, când oamenii aud cuvântul generativ în acest context, presupun că înseamnă generare de text conversațional. Nu este cazul aici. Generative Orchestration se referă strict la dynamic routing și tool selection. Este inteligența care decide ce acțiune să ia, în loc să genereze pur și simplu un răspuns. În orchestrarea clasică, construiești un topic și definești manual o listă de trigger phrases. Motorul de natural language understanding se bazează pe acele fraze exacte pentru a face routing utilizatorului. Generative Orchestration elimină complet aceste trigger phrases. În schimb, scrii o descriere clară, în plain-text, pentru fiecare topic și tool din agentul tău. Large language model-ul din spate citește user query-ul, evaluează toate descrierile disponibile și determină dinamic cea mai bună potrivire. Nu mai mapezi inputuri la triggere. Pur și simplu descrii ce fac tool-urile tale. Asta schimbă complet modul în care un agent gestionează inputuri complexe. Imaginează-ți un user care întreabă: Cum e vremea în Seattle și când se deschide magazinul? Într-un setup clasic, asta crapă. Sistemul detectează două intent-uri conflictuale și fie ghicește unul, fie aruncă o eroare de fallback. Generative Orchestration gestionează asta fără efort. Modelul parsează întreaga propoziție și recunoaște două obiective distincte. Îți scanează descrierile. Mai întâi, găsește un tool de vreme. Extrage Seattle din user query, îl dă mai departe către tool-ul de vreme ca input parameter și îl execută. Apoi, își amintește a doua jumătate din user prompt. Îți scanează din nou topicurile, îl găsește pe cel descris că gestionează programul magazinului și îi dă trigger. Aici e ideea de bază. Agentul face chain automat între aceste acțiuni. Rezolvă request-ul de vreme, apoi face o tranziție fluidă către topicul cu programul magazinului, combinând rezultatele. Nu scrii deloc routing logic sau cod de tranziție ca să faci asta să se întâmple. Această schimbare înseamnă că acum calitatea agentului tău depinde în întregime de calitatea descrierilor tale. Dacă descrierea pentru tool-ul de vreme spune pur și simplu vreme, modelul s-ar putea să aibă dificultăți să facă routing cu precizie. Dacă descrierea spune preia condițiile meteo actuale pentru un anumit nume de oraș, routing-ul devine exact. Mai mult, dacă un user dă trigger acelui tool de vreme, dar uită să specifice orașul, generative engine-ul observă automat că lipsește un required parameter. Va genera dinamic o întrebare pentru a cere orașul de la user înainte de a executa tool-ul. Ideea principală cu care trebuie să rămâi este asta. Generative Orchestration transformă routing-ul dintr-un exercițiu fragil de phrase-matching într-un capability search inteligent, lăsându-te liber să te concentrezi pe ce poate face agentul tău, în loc să ghicești cum va formula userul cererea. Dacă vrei să susții emisiunea, ne poți găsi căutând DevStoriesEU pe Patreon. Asta e tot pentru acest episod. Mulțumesc că ai ascultat și continuă să construiești!

AI-Based Agent Authoring

3m 45s

Descarcă

Salut, sunt Alex de la DEV STORIES DOT EU. Microsoft Copilot Studio, episodul 2 din 15. De obicei, construirea unui flow conversațional înseamnă să tragi nodes pe un canvas, să conectezi manual arborii logici și să ghicești fiecare trigger phrase posibil pe care end user-ul tău l-ar putea tasta. Dar cum ar fi dacă ai putea pur și simplu să-i spui unui AI exact ce vrei să construiești și să-l lași să genereze logica structurală pentru tine? Acest mecanism se numește agent authoring bazat pe AI. Este esențial să faci distincția între asta și comportamentul AI-ului la runtime. Developerii confundă adesea AI-ul generativ de la build time cu AI-ul generativ de la runtime. Runtime este atunci când un user live pune o întrebare, iar agentul generează dinamic un răspuns folosind o bază de cunoștințe externă. Authoring-ul la build time este complet diferit. Asta se întâmplă atunci când folosești un asistent AI în interiorul studioului pentru a construi framework-ul static al agentului în sine. Începi în authoring canvas. În loc să dai click pentru a adăuga elemente individuale, interacționezi cu authoring pane-ul din Copilot. Să presupunem că ai nevoie de un flow pentru a gestiona retururile de hardware. Tastezi o descriere simplă în limba engleză prin care soliciți un topic care îi cere user-ului numărul comenzii, verifică dacă articolul este un laptop sau un dispozitiv mobil, și apoi oferă adresa corectă de returnare în funcție de tipul de echipament. Când trimiți acel prompt, modelul de natural language understanding procesează instrucțiunile tale și le mapează direct la schema internă de nodes din Copilot Studio. Generează automat un set divers de trigger phrases pe care un user real le-ar putea spune pentru a iniția acest flow specific. Plasează un question node pe canvas pentru a captura numărul comenzii și îi atribuie o variabilă. Stabilește un condition node pentru a ramifica logica între un laptop și un dispozitiv mobil. Apoi populează acele message nodes finale cu adrese de returnare de tip placeholder. Întregul schelet al topic-ului apare instantaneu pe ecran. Iată ideea cheie. Acest proces de authoring este strict iterativ. Nu ești obligat să accepți generarea inițială ca produs final. Dacă te uiți la flow-ul generat și realizezi că trebuie să capturezi data achiziției, nu trebuie să întrerupi manual conexiunile și să inserezi un node nou. Pur și simplu îi spui authoring Copilot-ului să adauge o întrebare care să solicite data achiziției chiar înainte de a cere numărul comenzii. Modelul din spate analizează starea actuală a canvas-ului tău, înțelege punctul de inserare secvențială și modifică flow-ul în siguranță. Deoarece AI-ul traduce limbajul natural direct în componente standard Copilot Studio, păstrezi controlul arhitectural complet. Acele nodes generate nu sunt black boxes. Sunt exact aceleași elemente pe care le-ai fi creat manual. Poți da click pe condition branches, poți ajusta tipurile de variabile sau poți rescrie manual textul din prompt. Modelul de limbaj se ocupă pur și simplu de asamblarea mecanică a canvas-ului. Adevărata putere a authoring-ului bazat pe AI nu constă în faptul că scrie flow-uri conversaționale impecabile din prima încercare, ci în faptul că transformă procesul mecanic lent de wiring de nodes într-un dialog rapid despre intenția de business. Mersi că ai stat cu mine. Sper că ai învățat ceva nou.

Topics și Nodes

3m 50s

Descarcă

Salut, sunt Alex de la DEV STORIES DOT EU. Microsoft Copilot Studio, episodul 3 din 15. Chiar și cei mai avansați agenți AI au nevoie, până la urmă, de logică deterministă pentru reguli de business specifice. Când un client întreabă despre politica ta de retur sau despre programul magazinului, nu îți poți permite o estimare probabilistă de la un language model. Ai nevoie de un răspuns strict, garantat. Topics și Nodes îți oferă exact acest control structural. Gândește-te la un topic ca la un path de conversație discret. Este un arbore de dialog predefinit care dictează exact cum gestionează agentul tău un anumit intent. Agentul tău per ansamblu este, în esență, o colecție de astfel de topics care lucrează împreună pentru a ruta utilizatorul. Un punct frecvent de confuzie este distincția dintre System topics și Custom topics. E mai simplu decât pare. System topics gestionează comportamentele fundamentale ale agentului. Acestea guvernează evenimente core, cum ar fi salutul unui utilizator, încheierea unei conversații, escaladarea către un om sau prinderea unei erori atunci când agentul nu înțelege inputul. Le poți modifica textul pentru a se potrivi cu vocea brandului tău, dar nu le poți șterge. Sunt elemente permanente ale arhitecturii de sistem. Custom topics sunt acele paths pe care le construiești tu, aflate în întregime sub controlul tău, pentru a gestiona scenariile tale specifice de business. În interiorul fiecărui topic, conversația se execută de sus în jos prin pași individuali numiți nodes. Aceste nodes sunt blocurile funcționale de bază ale acelui path. Ca să înțelegi cum interacționează, imaginează-ți un custom topic conceput pentru a gestiona întrebările despre programul magazinului. Când utilizatorul face trigger la acest topic, primul pas din flow-ul tău ar putea fi un Question node. Un Question node îi dă un prompt utilizatorului pentru informații și așteaptă un anumit tip de răspuns. În acest caz, agentul întreabă ce oraș intenționează utilizatorul să viziteze. Când utilizatorul răspunde, acel node capturează răspunsul. Aici intervine partea de Variable management. Acel Question node stochează automat răspunsul utilizatorului într-o variabilă. Acum ții o bucată distinctă de state în memorie, ceea ce îți permite să rutezi conversația dinamic, pe baza a ceea ce tocmai a spus utilizatorul. Aici devine interesant. În loc să oferi un răspuns generic, adaugi un Condition node pentru a evalua acea variabilă. Un Condition node acționează ca un fork logic pe acest drum. Verifică acel current state al variabilei tale în raport cu regulile pe care le definești. Dacă orașul stocat este egal cu New York, acel node direcționează flow-ul pe un branch. Dacă orașul este egal cu Londra, direcționează flow-ul pe un altul. Poți adăuga oricâte branches ai nevoie pentru diferite states, plus un fallback branch dacă variabila nu face match cu niciun oraș cunoscut. În final, la sfârșitul fiecărui branch condițional, plasezi un Message node. Un Message node afișează pur și simplu text sau media înapoi către utilizator. Acel branch pentru New York ajunge la un Message node care spune că magazinul se deschide la nouă dimineața. Acel branch pentru Londra ajunge la un alt Message node care spune că magazinul se deschide la zece. Făcând chaining cu aceste nodes de tip Question, Variable, Condition și Message, dictezi exact cum curge logica. Cea mai importantă idee de reținut aici este că aceste topics îți izolează regulile deterministe de business în paths previzibile, asigurându-te că agentul tău răspunde fiabil atunci când precizia contează mai mult decât generarea. Mersi că m-ai ascultat. Pe data viitoare!

State și Variables

3m 47s

Descarcă

Salut, sunt Alex de la DEV STORIES DOT EU. Microsoft Copilot Studio, episodul 4 din 15. Cea mai rapidă metodă de a frustra un utilizator este să-l pui să repete informațiile pe care tocmai ți le-a dat. Dacă botul tău cere un nume, declanșează un nou workflow, și apoi cere din nou numele, experiența utilizatorului se strică complet. Mecanismul care previne această amnezie este State-ul și variabilele. O variabilă în Copilot Studio stochează date extrase de la utilizator sau preluate dintr-un sistem de backend. Cea mai importantă decizie pe care o iei atunci când creezi o variabilă este definirea scope-ului acesteia. Ascultătorii confundă adesea variabilele la nivel de topic cu variabilele globale. O variabilă la nivel de topic este strict locală. Există doar cât timp topic-ul său părinte este activ. În momentul în care topic-ul respectiv se termină, variabila este ștearsă din memorie. O variabilă globală, pe de altă parte, persistă pe durata întregii conversații. Orice topic o poate citi și orice topic o poate suprascrie. Este tentant să faci din fiecare informație partajată o variabilă globală. Nu face asta. Folosirea excesivă a variabilelor globale creează schimbări de state imprevizibile atunci când topic-urile se întrerup reciproc. În schimb, transmite variabilele locale direct între topic-uri. Gândește-te la un topic numit Greeting. Acesta îi cere utilizatorului numele și îl stochează într-o variabilă locală. Greeting-ul se termină, iar flow-ul redirecționează către un topic nou numit Talk to Customer. Pentru a muta numele, configurezi topic-ul Talk to Customer să primească valori de la alte topic-uri. Definești o variabilă de input pe acest topic de destinație. Apoi, înapoi în topic-ul Greeting, nodul de redirect îți va cere automat să mapezi o valoare la acel input. Transmiți variabila locală cu numele prin nod. Topic-ul de destinație o prinde, botul continuă conversația folosind numele corect, iar state-ul tău global rămâne neaglomerat. Când acel topic de destinație își termină treaba, poate, de asemenea, să returneze valori înapoi la topic-ul apelant inițial folosind variabile de output. Asta acoperă datele generate în timpul unui chat. Acum, a doua parte implică datele de care agentul tău are nevoie înainte ca un chat măcar să înceapă. Dacă agentul tău se conectează la sisteme externe, are nevoie de credențiale. Nu stoca absolut niciodată API keys sau connection strings în variabilele de conversație. Pentru asta, folosești environment variables. Environment variables trăiesc în întregime în afara sesiunii utilizatorului. Ele stochează date de configurare care se aplică agentului în sine, permițându-ți să muți botul dintr-un mediu de development în testing, și în final în producție, fără să faci hardcoding la valori. Fii atent la partea asta. Atunci când lucrezi cu date extrem de sensibile, environment variables se integrează direct cu Azure Key Vault. În loc să dai paste la o parolă în Copilot Studio, creezi o environment variable marcată ca secret. Această variabilă stochează o referință la o cheie specifică din Azure Key Vault. La runtime, agentul preia în siguranță secretul pentru a autentifica request-ul de backend. Secretul nu este niciodată expus în authoring canvas, nu este niciodată printat în chat logs și este exclus din exporturile tale de source control. Cel mai sigur state este un scoped state, așa că păstrează variabilele de conversație locale ori de câte ori este posibil, transmite-le explicit peste limitele topic-urilor și deleagă întotdeauna credențialele de sistem către environment variables securizate. Mulțumesc pentru audiție, happy coding tuturor!

Entities și Slot Filling

4m 23s

Descarcă

Salut, sunt Alex de la DEV STORIES DOT EU. Microsoft Copilot Studio, episodul 5 din 15. Construiești un bot care să preia comenzi, dar acesta obligă utilizatorii să treacă prin cinci întrebări plictisitoare. Utilizatorul ți-a dat deja toate detaliile în primul său mesaj, dar botul tău ignoră acel context și tot îi cere detaliile pe rând. Acest comportament rigid îi frustrează pe utilizatori și este exact problema rezolvată de Entities și Slot Filling. Entities reprezintă modul prin care Copilot Studio recunoaște subiecte din lumea reală dintr-un limbaj natural dezordonat. Gândește-te la un entity ca la un data type specific pe care botul tău este antrenat să îl identifice într-o propoziție. În loc să analizeze toată fraza Aș dori să cheltuiesc douăzeci de dolari, AI-ul caută pur și simplu acel money entity și extrage valoarea douăzeci. Copilot Studio vine cu un set mare de prebuilt entities. Acestea gestionează concepte standard de date out of the box. Aceste prebuilt entities recunosc vârsta, datele, culorile, numerele, numele și banii. Ele normalizează datele automat. Indiferent dacă utilizatorul scrie douăzeci de dolari, semnul de dolar urmat de 20, sau douăzeci de parai, acel prebuilt money entity extrage valoarea numerică exactă și moneda. Dar afacerea ta operează cu o terminologie specifică. Pentru a capta asta, construiești custom entities. Există două tipuri principale de custom entities pe care le vei folosi. Primul este un closed list entity. Definești o listă strictă de elemente permise, iar apoi atașezi sinonime fiecărui element. Dacă vinzi echipamente de outdoor, ai putea crea un entity pentru categoria de produse cu un element principal numit hiking. Apoi adaugi sinonime precum trekking, backpacking și trail walking. Când utilizatorul scrie oricare dintre aceste sinonime, AI-ul îi mapează input-ul direct la valoarea principală de hiking. Al doilea tip custom este un regular expression, sau regex entity. Folosești regex entities atunci când utilizatorii trebuie să furnizeze string-uri formatate, în loc de cuvinte specifice. Un use case comun este un support ticket sau un order ID. Dacă sistemul tău folosește tracking numbers care încep mereu cu literele TRK urmate de cinci cifre, definești acel pattern folosind regex. AI-ul va scana mesajul utilizatorului și va extrage curat exact acel string, ignorând orice text din jur. Identificarea acelui entity este doar primul pas. Trebuie să stochezi acele date pentru a le folosi. Această acțiune se numește slot filling. Mapezi un entity extras la o variabilă, umplând acel slot cu datele utilizatorului. Aici devine interesant. Copilot Studio folosește un feature numit proactive slot filling. By default, motorul de natural language understanding evaluează fiecare mesaj al utilizatorului în raport cu toate variabilele pe care le cere acel topic de conversație. Dacă AI-ul detectează acele entities necesare în input-ul inițial al utilizatorului, umple imediat acele slot-uri. Ia în considerare un utilizator care îți declanșează acel topic de achiziție spunând, Vreau să cumpăr bocanci de hiking sub 100 de dolari. Ai un custom closed list entity pentru categoria de produse și folosești acel prebuilt money entity pentru buget. Datorită acelui proactive slot filling, AI-ul procesează toată propoziția deodată. Izolează hiking, îl mapează la variabila ta de categorie și îl stochează. Izolează 100 de dolari, îi mapează la variabila ta de buget și îi stochează. Pentru că acele slot-uri sunt deja umplute, botul sare complet peste acele question nodes, Ce categorie cauți? și Care este bugetul tău?. Acel conversation flow sare direct peste ele și trece la următoarea informație lipsă. Prin definirea de entities stricte și bazându-te pe proactive slot filling pentru a gestiona extragerea, te oprești din a scrie decision trees rigizi și începi să construiești agenți conversaționali care respectă timpul utilizatorului. Asta e tot pentru acest episod. Mersi pentru audiție și continuă să construiești!

Enterprise Knowledge Grounding

4m 15s

Descarcă

Salut, sunt Alex de la DEV STORIES DOT EU. Microsoft Copilot Studio, episodul 6 din 15. Cea mai grea parte în construirea unui agent conversațional era să prezici fiecare întrebare a utilizatorului și să scrii manual răspunsurile. Petreceai săptămâni întregi mapând dialogue trees, doar ca utilizatorii să întrebe ceva ușor off-script și să ajungă într-un dead end. Enterprise Knowledge Grounding răstoarnă complet acest model. În loc să scrii răspunsuri, datele tale enterprise existente fac tot greul. Un large language model generic este foarte articulat, dar nu știe absolut nimic despre compania ta. Enterprise Knowledge Grounding acoperă acest gol conectând copilotul direct la datele tale reale de business, cum ar fi website-uri publice, directoare SharePoint, fișiere uploadate și tabele Dataverse. Să luăm un scenariu de customer support. Ai nevoie de un agent care să răspundă la întrebări despre hardware-ul tău. În loc să construiești sute de custom topics, uploadezi manualele de produs în format PDF în copilot și dai paste la URL-ul site-ului tău public de documentație. Când un utilizator întreabă cum să dea reset la un anumit model de router, copilotul caută în acele surse conectate, extrage textul relevant și sintetizează un răspuns direct. De asemenea, oferă un link de citare către manualul sau pagina web respectivă, ca utilizatorul să poată verifica informația. O confuzie frecventă este unde mai exact se află acest knowledge în arhitectură. Poți atașa knowledge în două locuri distincte: la nivel de agent sau la nivel de topic. Knowledge-ul la nivel de agent este global. Acționează ca o plasă de siguranță pentru întregul copilot. Dacă un utilizator pune o întrebare și nu se face trigger la niciun topic creat manual, sistemul face fallback la acest pool global de knowledge. Caută în toate sursele tale conectate la nivel de agent pentru a genera un răspuns. Asta înseamnă că obții valoare imediată fără să scrii custom conversation flows. Aici e ideea de bază. Uneori ai nevoie de un control strict asupra datelor pe care le folosește AI-ul, și aici intervine knowledge-ul la nivel de topic. Configurezi asta trăgând un nod Generative Answers direct în authoring canvas-ul unui anumit custom topic. Dacă un utilizator face trigger la un custom topic pentru procesarea unei cereri de garanție, nu vrei ca AI-ul să extragă răspunsuri de pe website-ul tău general de marketing. Folosind un nod Generative Answers în interiorul acelui topic specific, poți restricționa sursa de date exclusiv la un folder SharePoint care conține documente legale de garanție. AI-ul primește scope exact pe contextul acelui pas din conversație. Când conectezi aceste surse enterprise, sistemul gestionează accesul inteligent. Pentru website-uri publice, copilotul pur și simplu indexează paginile publice. Pentru surse interne precum SharePoint, copilotul folosește credențialele Entra ID ale persoanei care interacționează cu botul. Respectă cu strictețe permisiunile existente pe fișiere. Dacă un angajat nu are acces la un anumit document intern din SharePoint, copilotul nu va citi acel document și nu îl va folosi pentru a-i răspunde la întrebare. Pentru date structurate, te poți conecta direct la tabele Dataverse, permițând copilotului să-și bazeze răspunsurile pe record-urile live ale aplicațiilor tale de business. Folosirea unui nod Generative Answers în interiorul unui custom topic îți permite să controlezi strict limitele exacte ale knowledge-ului AI-ului în anumite puncte dintr-o conversație, prevenind ca datele globale generale să încurce workflow-uri foarte specifice. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și keep building!

Tenant Graph Grounding

4m 01s

Descarcă

Salut, sunt Alex de la DEV STORIES DOT EU. Microsoft Copilot Studio, episodul 7 din 15. Căutarea standard după cuvinte cheie nu mai face față în momentul în care un utilizator pune o întrebare nuanțată despre o politică internă. Nu ai nevoie de cuvinte cheie mai bune. Ai nevoie de un sistem care să înțeleagă sensul real al întrebării în dataseturi masive. Exact aici intervine Tenant Graph Grounding. Tenant Graph Grounding aduce o înțelegere semantică profundă direct pe datele tale enterprise. Mai întâi, să clarificăm o concepție greșită des întâlnită. Asta nu e o căutare standard în Dataverse și nu are nicio legătură cu scraping-ul site-urilor web publice. Asta este o capabilitate avansată de retrieval enterprise care îți conectează copilotul direct la Microsoft Graph. Este construită special pentru a gestiona cunoștințe interne complexe stocate în tot tenantul tău. Pentru a folosi acest feature, environmentul tău trebuie să îndeplinească niște cerințe stricte. Ai nevoie de o licență Microsoft 365 Copilot. Datele tale trebuie să fie indexate de Semantic Index for Copilot. Cel mai important, copilotul tău trebuie să fie configurat cu autentificare Microsoft Entra ID. Asta nu este opțional. Copilotul trebuie să transmită în siguranță identitatea persoanei care pune întrebarea către Microsoft Graph. Gândește-te la un copilot intern de HR conceput să caute prin manuale masive pentru angajați. Aceste manuale stau adesea în SharePoint sau OneDrive ca documente masive. Toolurile standard de retrieval se blochează adesea la fișiere mari, dar Tenant Graph Grounding suportă fișiere de până la 512 megabytes. Când un angajat întreabă despre un scenariu foarte specific, cum ar fi politica de concediu parental pentru un îngrijitor secundar care lucrează part-time, un motor de căutare tradițional caută exact acele cuvinte. Dacă manualul folosește o formulare diferită, căutarea eșuează. Aici e ideea cheie. Pentru că acest feature folosește Semantic Index, mapează relațiile conceptuale dintre query-ul utilizatorului și datele enterprise. Înțelege că query-ul despre concediul parental se mapează conceptual la o secțiune intitulată timp liber pentru familie, chiar dacă cuvintele cheie nu se aliniază perfect. Fluxul logic operează în întregime în limitele securizate ale tenantului tău. Un utilizator trimite un prompt către copilot. Copilotul folosește tokenul Entra ID al acelui utilizator specific pentru a face un query către Microsoft Graph. Microsoft Graph caută apoi în Semantic Index, dar se uită doar la fișierele pe care acel utilizator are deja permisiunea să le citească. Dacă un document este restricționat, Graph pur și simplu îl ignoră pentru acel utilizator. Graph aduce potrivirile semantice extrem de relevante și le returnează copilotului. Copilotul folosește apoi exact acele chunk-uri de date pentru a genera un răspuns precis și grounded. Întreaga tranzacție are loc cu o precizie aproape instantanee, ocolind latența și inexactitatea încercării de a-ți construi proprii indecși de căutare custom peste datele din SharePoint. Tenant Graph Grounding transferă toată povara de retrieval de la logica ta custom direct pe infrastructura semantică Microsoft 365, garantând că copilotul tău respectă limitele existente ale datelor enterprise, oferind în același timp o acuratețe contextuală de neegalat. Dacă vrei să susții emisiunea, poți găsi DevStoriesEU pe Patreon. Asta e tot pentru episodul ăsta. Mulțumesc că m-ai ascultat și continuă să construiești!

Prompt Tools

3m 49s

Descarcă

Salut, sunt Alex de la DEV STORIES DOT EU. Microsoft Copilot Studio, episodul 8 din 15. Uneori nu ai nevoie să construiești un API complex sau să integrezi un serviciu extern de parsing pentru a procesa datele primite. Ai nevoie doar de un Large Language Model care să analizeze un string de text dezordonat și să-l proceseze exact așa cum vrei tu. Aici intervin Prompt Tools. Mai întâi, trebuie să clarificăm o confuzie frecventă. Prompt Tools sunt complet diferite de Generative Answers. Generative Answers scanează o bază de cunoștințe externă sau un site web pentru a răspunde dinamic la întrebările utilizatorilor. Prompt Tools nu caută răspunsuri. Acestea sunt instrucțiuni specifice, atent construite, care îi spun unui Large Language Model să execute un task strict definit pe datele pe care i le oferi. Gândește-te la un Prompt Tool ca la o funcție reutilizabilă în care logica din spate este scrisă în limbaj natural în loc de cod. Îl construiești definind un prompt template, specificând variabilele de input și oferind reguli contextuale stricte. Imaginează-ți un scenariu des întâlnit. Primești un bloc de feedback nestructurat și haotic de la clienți. Vrei să extragi sentimentul de bază și să generezi o listă curată de action items specifice. În loc să scrii regular expressions complexe sau un parsing script custom, creezi un Prompt Tool. Începi prin a defini inputurile. În Copilot Studio, creezi o variabilă de input numită feedback text și îi setezi tipul de date. Acest pas simplu îi spune tool-ului să se aștepte la un string dinamic de fiecare dată când este invocat de sistem. Apoi, scrii prompt template-ul. Acesta este setul principal de instrucțiuni trimis modelului de limbaj. Scrii exact ce trebuie să facă modelul. Îl instruiești să citească variabila feedback text, să determine dacă tonul este pozitiv, negativ sau neutru și să identifice orice task-uri pe care echipa de customer support trebuie să le rezolve pe baza textului. Iată ideea cheie. Template-ul este practic inutil fără un context strict. Nu îi ceri modelului doar sentimentul și speri că va răspunde frumos. Definești structura exactă a output-ului în contextul prompt-ului. Instruiești explicit modelul să returneze rezultatul formatat ca un obiect JSON strict, care conține o cheie sentiment și un array de action items. Îi interzici să folosească conversational filler. Acest context transformă un răspuns generic și vorbăreț al modelului de limbaj într-un data payload previzibil și structurat, pe care sistemele tale downstream îl pot parsa efectiv. Când agentul tău declanșează acest tool în timpul unei conversații live, fluxul de execuție este complet automatizat. Agentul preia răspunsul live al clientului și îl dă mai departe în inputul feedback text. Tool-ul injectează dinamic acel string în template-ul tău, trimite pachetul complet de instrucțiuni către model și returnează JSON-ul structurat. Agentul poate apoi să folosească acele action items extrase pentru a actualiza automat o bază de date sau pentru a direcționa utilizatorul către o coadă de suport specializată. Definești tool-ul o singură dată, iar agentul îl apelează automat ori de câte ori recunoaște nevoia de a procesa text nestructurat. Un Prompt Tool bine construit mută povara procesării complexe de text de pe codul aplicației tale pe modelul de limbaj, permițându-ți să extragi date perfect structurate din haos total folosind doar câteva rânduri de engleză simplă. Asta e tot pentru acest episod. Îți mulțumesc că m-ai ascultat și continuă să construiești!

Agent Flows

4m 12s

Descarcă

Salut, sunt Alex de la DEV STORIES DOT EU. Microsoft Copilot Studio, episodul 9 din 15. Agentul tău trebuie să execute un backend workflow complex care acoperă mai multe sisteme. Poate că trebuie să facă un query într-o bază de date izolată, să filtreze datele și să actualizeze un sistem de inventar, toate în același timp. Un singur API call nu poate gestiona această orchestrare. Soluția este un Agent Flow. Agent Flows fac legătura între Copilot Studio și Power Automate. Acestea îți permit să împachetezi o automatizare cu mai mulți pași ca un tool independent căruia agentul tău îi poate da trigger autonom. Agentul se bazează în întregime pe numele și descrierea pe care le oferi pentru flow. Pe baza acelui text, agentul decide dacă flow-ul poate rezolva request-ul curent al utilizatorului. Când găsește un match, agentul extrage parametrii necesari din conversație, îi pasează în flow, așteaptă execuția și folosește output-ul final pentru a genera un răspuns. Structura unui Agent Flow este strictă. Trebuie să înceapă cu un trigger specific conceput pentru Copilot, care definește explicit acele inputs de tip text sau număr. Trebuie să se termine cu o acțiune specifică ce răspunde înapoi către Copilot, definind acele outputs de tip text sau număr. Totul între aceste două nodes este logică standard de Power Automate. Poți face loop prin arrays, poți apela custom connectors sau poți da parse la fișiere. Ia în considerare un scenariu în care agentul tău trebuie să preia istoricul comenzilor dintr-o bază de date SQL legacy. Utilizatorul cere comenzile sale recente. Agentul dă trigger la flow, pasând acel string de customer ID ca input. În interiorul flow-ului, tu construiești logica pentru a te conecta la baza de date SQL, execuți acel query și formatezi rândurile brute din baza de date într-un JSON string curat. Flow-ul pasează apoi acel string formatat înapoi la agent prin response node. Agentul citește acel string, extrage detaliile comenzii și îi răspunde utilizatorului în limbaj natural. Iată ideea cheie. Execuția trebuie să fie complet synchronous. Agentul inițiază flow-ul și ține conexiunea deschisă, așteptând răspunsul. Dacă construiești un flow asynchronous, nu va funcționa ca un agent tool. Nu poți include pași care pun pauză la logică. Dacă flow-ul tău trimite un email de aprobare și așteaptă ca un om să dea click pe un buton, agentul va pica. Acest tool pattern necesită o returnare imediată a datelor. Asta ne aduce la o limită strictă de sistem. Ai la dispoziție exact o sută de secunde. Din momentul în care agentul dă trigger la flow, logica are o sută de secunde să execute fiecare pas, să facă query pe baza de date, să formateze output-ul și să trimită răspunsul înapoi. Dacă serverul SQL legacy este sub load, sau dacă flow-ul tău iterează prin prea multe înregistrări, execuția va depăși limita de timeout. Când se întâmplă asta, agentul închide complet conexiunea și returnează un mesaj de eroare către utilizator. Pentru a gestiona această limită, trebuie să menții automatizarea cu un scope foarte strict. Dacă un backend process durează cinci minute, nu îl rula în interiorul unui Agent Flow. În schimb, folosește flow-ul pentru a porni un background job extern și returnează imediat un tracking ID către agent. Arhitectura ta de automatizare trebuie să respecte fereastra de timeout. Proiectează-ți flow-urile astfel încât să se execute rapid, să recupereze exact ce este nevoie și să returneze controlul către agent, asigurându-te că utilizatorul nu este niciodată lăsat să vorbească cu o conexiune blocată. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și spor la construit!

Power Platform Connectors

4m 13s

Descarcă

Salut, sunt Alex de la DEV STORIES DOT EU. Microsoft Copilot Studio, episodul 10 din 15. Petreci zile întregi scriind și menținând integrări API custom, doar pentru ca agentul tău să poată comunica cu lumea exterioară. Între timp, mii de wrappere predefinite stau deja în environment-ul tău, așteptând să fie executate. Astăzi, ne uităm la conectorii Power Platform. Conectorii sunt wrappere API standardizate. Ei oferă o modalitate predictibilă prin care Microsoft Copilot Studio poate comunica cu serviciile externe. Înainte să ne uităm la cum funcționează, trebuie să clarificăm o confuzie frecventă. Utilizatorii confundă adesea folosirea unui sistem extern ca sursă de knowledge cu folosirea lui ca tool. Dacă agentul tău face un query pe o bază de date doar pentru a extrage informații și a-și fundamenta răspunsurile conversaționale, asta înseamnă knowledge pasiv. Folosirea unui conector ca tool este diferită. Este o operațiune activă. Îi dai agentului autoritatea să execute acțiuni, să creeze înregistrări sau să declanșeze procese externe în numele utilizatorului. Există trei categorii de conectori disponibili. Conectorii standard acoperă serviciile Microsoft de bază și endpoint-urile publice comune. Conectorii premium necesită o licențiere specifică și se conectează la sisteme enterprise precum Salesforce sau ServiceNow. Dacă sistemul pe care vrei să-l accesezi este un API proprietar intern, poți construi un conector custom. Un conector custom este doar un wrapper OpenAPI pe care îl definești tu. Odată înregistrat în environment-ul tău, se comportă exact ca cei standard și premium. Agentului nu-i pasă cine l-a construit. Hai să vedem cum funcționează logica asta pe un scenariu concret. Vrei ca agentul tău să compileze un rezumat al proiectului și să-l trimită pe email echipei tale de inginerie. În loc să construiești manual un HTTP request, adaugi conectorul Office 365 Outlook direct în copilotul tău ca o acțiune. Fiecare conector expune operațiuni specifice. În cazul ăsta, selectezi acțiunea de a trimite un email. Aici e partea care contează. Nu scrii cod procedural ca să dictezi exact când se trimite emailul ăsta. În schimb, definești parametrii de care conectorul are nevoie ca să funcționeze. Conectorul Outlook are nevoie de o adresă de destinație, un subiect și un body text. Configurezi aceste inputuri și oferi o descriere clară, în limbaj natural, a ceea ce face acțiunea. Copilot se bazează în întregime pe descrierea aia ca să determine când să declanșeze tool-ul. Când un utilizator îi spune agentului să trimită status update-ul săptămânal echipei de inginerie, agentul își evaluează tool-urile disponibile. El face match între request-ul utilizatorului și descrierea conectorului tău Outlook. Agentul extrage apoi dinamic numele destinatarului și textul rezumatului din conversația curentă. Mapează valorile extrase pe inputurile conectorului și declanșează acțiunea. După ce API-ul extern procesează request-ul, conectorul dă un response înapoi agentului. Ăsta poate fi un simplu cod de succes sau un payload cu detalii specifice despre tranzacție. Agentul primește datele astea, verifică dacă acțiunea a fost completată și generează un răspuns în limbaj natural prin care îi spune utilizatorului că emailul a fost trimis. Prin standardizarea interfeței, aceste wrappere elimină nevoia de a gestiona tokenuri de autentificare, headere și error handling pentru fiecare serviciu în parte. Configurezi conexiunea o singură dată, iar agentul orchestrează execuția. Conectorii îți transformă agentul dintr-o interfață conversațională statică într-un tool operațional care chiar modifică state-ul în infrastructura ta. Asta e tot pentru acest episod. Mersi că m-ai ascultat și continuă să construiești!

Computer Use Tool

3m 33s

Descarcă

Salut, sunt Alex de la DEV STORIES DOT EU. Microsoft Copilot Studio, episodul 11 din 15. Dacă o aplicație nu are un API, automatizarea tradițională se lovește de un zid. Fie scrii scripturi fragile care crapă în momentul în care un buton se mută, fie accepți introducerea manuală a datelor. Tool-ul Computer Use rezolvă asta permițând AI-ului să vadă la propriu ecranul și să opereze sistemul singur. Disponibil în preview, acest feature permite agentului tău să interacționeze cu o interfață grafică folosind un mouse și o tastatură virtuală. Se bazează pe Computer-Using Agents, susținuți de modele cu capabilități de vision, cum ar fi Claude 3.5 Sonnet de la Anthropic. Trebuie să clarificăm ce NU este acest tool. Nu este un Robotic Process Automation tradițional. RPA-ul standard se bazează pe hook-uri structurale din spate, cum ar fi tag-uri de DOM sau ID-uri de elemente de UI. Tool-ul Computer Use operează exclusiv pe pixeli. Fluxul logic este un loop continuu. Tool-ul face un screenshot al mediului desktop și îl dă mai departe modelului. Modelul analizează layout-ul vizual, face reasoning pe request-ul utilizatorului și calculează coordonatele precise pentru următoarea sa mișcare. Apoi, trimite instrucțiuni înapoi către sistem. Sistemul le traduce prin mutarea cursorului virtual la o anumită poziție X și Y, printr-un click de mouse, sau prin trimiterea unui string de keystroke-uri. După executarea acțiunii, tool-ul face un alt screenshot pentru a evalua noul state al ecranului, verificând dacă s-a deschis o fereastră sau a apărut un text, înainte de a decide următorul pas. Gândește-te la un scenariu în care trebuie să extragi date dintr-o aplicație desktop Windows legacy și să le introduci într-un web form modern. Agentul se uită la screenshot-ul aplicației legacy, localizează vizual numărul facturii și stochează acea informație. Apoi trimite instrucțiuni pentru a muta mouse-ul pe fereastra de browser, a da click în câmpul target din web form și a tasta cifrele. Navighează prin interfață exact așa cum ar face-o un operator uman, ghidat în întregime de contextul vizual de pe display. Să oferi unui model de AI control fizic asupra unui desktop necesită controale stricte de securitate. Aici e ideea de bază. Nu dai niciodată deploy la așa ceva pe un server de producție sau pe workstation-ul principal al unui utilizator. Agentul trebuie să opereze în interiorul unui virtual machine sau container dedicat și izolat. Acordă acestui environment minimul absolut de privilegii necesare pentru a finaliza task-ul specific. Pentru că modelul poate naviga singur în browsere web, trebuie să impui controale stricte de rețea. Aplici un URL allow list, astfel încât agentul să poată accesa doar domenii aprobate, prevenind interacțiunea cu website-uri untrusted sau servicii externe. De asemenea, te asiguri că virtual machine-ul nu conține date sensibile în afara workload-ului imediat. Tratând interfața grafică ca pe un simplu visual input stream, reduci distanța dintre reasoning-ul inteligent și software-ul legacy inaccesibil, fără să scrii o singură linie de integration code. Asta e tot pentru acest episod. Mersi că m-ai ascultat și keep building!

User Authentication

3m 41s

Descarcă

Salut, sunt Alex de la DEV STORIES DOT EU. Microsoft Copilot Studio, episodul 12 din 15. Un agent este la fel de puternic precum datele la care are acces. Dar dacă agentul tău face un query într-un sistem privat și servește accidental calendarul tău personal unui cu totul alt angajat, ai o breșă masivă de securitate. Pentru a preveni asta, trebuie să configurezi corect User Authentication. Cea mai frecventă greșeală pe care o fac developerii aici este să confunde credențialele de maker cu credențialele de end-user. Dacă incluzi propriile API keys sau credențiale de service principal într-o acțiune a agentului, botul execută acele acțiuni în numele tău. Fiecare persoană care vorbește pe chat cu agentul va face bypass la propriile limite de securitate și va accesa date folosind permisiunile tale. User Authentication forțează agentul să ruleze query-uri exact ca persoana care scrie prompt-ul, bazându-se în întregime pe identitatea ei unică. În Copilot Studio, alegi în principal între două stări de autentificare: Authenticate with Microsoft și Authenticate manually. Authenticate with Microsoft este calea simplificată pentru tool-uri interne. Dacă agentul tău operează exclusiv în Microsoft Teams sau Power Apps, această setare folosește automat token-ul Microsoft Entra ID al persoanei logate în acel moment în aplicație. Nu există un prompt separat de login. Contextul de user pur și simplu trece mai departe către agent. Treci pe Authenticate manually atunci când agentul tău rulează pe un website extern custom, sau când ai nevoie de un control strict și granular asupra permisiunilor. Metoda asta se bazează pe setarea unei conexiuni OAuth2 la un identity provider, care este de obicei un App Registration în Microsoft Entra ID. Să luăm un scenariu concret. Construiești un agent care verifică programul personal al unui angajat. Configurezi Authenticate manually și îl legi la acel App Registration din Entra ID. Aici e ideea de bază. Agentul nu primește acces general la întregul cont Microsoft al userului. În schimb, definești scope-uri stricte în configurația ta. Configurezi nodul de autentificare să ceară un scope specific numit Calendars dot Read. Când un user cere agentului programul său, agentul își pune logica pe pauză și afișează un sign-in card în chat. Userul dă click pe link, se autentifică prin browser și vede un ecran care îi cere să acorde agentului read access la calendarul său. Odată ce își dă consent-ul, Microsoft Entra ID generează un access token și îl pasează în siguranță înapoi la agent. Acest access token este legat strict de acel user individual și restricționat exclusiv la scope-ul de calendar. Când agentul face request-ul HTTP propriu-zis pentru a face fetch programului, include acest token. API-ul de backend inspectează token-ul, confirmă identitatea userului și returnează în siguranță doar evenimentele specifice din calendarul lui. Să configurezi corect User Authentication este ceea ce transformă un chatbot generic într-un asistent personalizat, dovedind sistemelor tale de backend exact cine cere datele, astfel încât să nu faci niciodată leak de informații private între sesiuni. Îți mulțumesc că ai petrecut câteva minute cu mine. Până data viitoare, numai bine.

Voice și IVR

4m 10s

Descarcă

Salut, sunt Alex de la DEV STORIES DOT EU. Microsoft Copilot Studio, episodul 13 din 15. Viitorul customer service-ului nu înseamnă doar text pe un ecran. Oamenii încă sună la liniile de suport și, atunci când o fac, se așteaptă la un răspuns imediat și inteligent, nu la un arbore infinit de meniuri. Pentru a acoperi acest decalaj, trebuie să îți conectezi AI-ul direct la rețelele de telefonie. Despre asta vorbim astăzi: Voice și IVR. Să iei un agent construit în Copilot Studio și să-l faci să răspundă la telefon înseamnă să-l configurezi pentru un telephony channel, în general prin Dynamics 365 sau Azure Communication Services. Asta îți transformă logica într-un sistem Interactive Voice Response, bazându-se pe speech recognition nativ pentru a converti audio-ul apelantului în text și pe motoare text-to-speech pentru a răspunde. Dar traducerea logicii de chat în logică de voce necesită gestionarea realităților fizice ale unui apel telefonic. Gândește-te la un client care sună la o linie de suport. Botul răspunde și începe să citească un mesaj de întâmpinare legal obligatoriu sau o listă de opțiuni. Apelantul știe deja că are nevoie de departamentul de facturare. Dacă ar fi un text chat, și-ar tasta pur și simplu întrebarea. La telefon, vorbește peste bot. Asta necesită un feature numit Barge-in. Fără Barge-in activat, sistemul ignoră audio-ul primit până când botul își termină complet playback-ul. Cu Barge-in activ, speech recognizer-ul ascultă simultan. În momentul în care detectează utilizatorul vorbind, oprește instantaneu output-ul text-to-speech al botului și procesează audio-ul primit. Asta reproduce fluxul natural al conversației umane și îi scapă pe apelanți de senzația că sunt blocați de o mașinărie. După ce întrerupe botul, apelantului i se cere un număr de cont. Ar putea spune numerele cu voce tare, dar poate se află într-o cameră aglomerată. În schimb, tastează numerele pe ecran. Asta ne aduce la DTMF, sau Dual-Tone Multi-Frequency. Oamenii confundă adesea DTMF handling-ul cu input-urile text standard, dar sunt mecanisme complet separate. DTMF gestionează interacțiunile cu keypad-ul telefonului la nivel global în întreaga rețea de telefonie. Când un apelant apasă o tastă, rețeaua trimite un ton de frecvență specific. Copilot Studio captează direct aceste tonuri. Configurezi input nodes să asculte secvențe DTMF, să extragă cifrele rezultate și să le stocheze ca variabile. Poți impune un număr maxim de cifre, poți seta timeout-uri și poți defini un caracter de terminare, cum ar fi să instruiești utilizatorul să apese tasta diez după ce a terminat de tastat. Iată ideea cheie. Doar să capturezi input-ul nu este suficient; modul în care agentul tău răspunde determină dacă apelantul închide. Text-to-speech-ul default poate suna plat. Pentru a remedia asta, folosești SSML, sau Speech Synthesis Markup Language. În loc să trimiți plain text către motorul de voce, îți încadrezi răspunsurile în markup tags. SSML îți permite să controlezi pitch-ul, să ajustezi speaking rate-ul și să impui pronunții specifice. Dacă numele companiei tale este un acronim, poți folosi SSML pentru a forța motorul să îl citească literă cu literă, în loc să ghicească cum sună ca un cuvânt. Poți insera tăceri precise, adăugând o pauză de jumătate de secundă după o instrucțiune complexă pentru a lăsa apelantul să proceseze informația. Să construiești pentru voce necesită tratarea liniei telefonice ca o interfață unică, ținând cont de întreruperi, tonuri de keypad și audio pacing. Cei mai eficienți voice agents nu forțează utilizatorii în meniuri audio rigide; ei combină un barge-in seamless și un DTMF handling precis, pur și simplu pentru a nu-i sta în cale apelantului. Mersi că m-ai ascultat. Pe data viitoare!

Agent Analytics

3m 26s

Descarcă

Salut, sunt Alex de la DEV STORIES DOT EU. Microsoft Copilot Studio, episodul 14 din 15. În sfârșit, dai deploy la agentul tău, îl testezi singur și totul arată perfect. O săptămână mai târziu, satisfacția utilizatorilor scade, iar procesele din background dau fail silențios. Problema nu este build-ul tău inițial, ci lipsa ta de vizibilitate asupra comportamentului din producție. Tool-ul care rezolvă asta este Agent Analytics. Agent Analytics oferă o imagine unificată a modului în care agentul tău performează odată ce gestionează workload-uri reale. Primul lucru pe care îl vezi este pagina Summary. Aceasta acționează ca un centru de comandă. Agregă indicatori cheie de performanță, cum ar fi numărul total de sesiuni, engagement rate, resolution rate și escalation rate. În loc să ghicești dacă agentul tău îi ajută pe utilizatori, insight-urile AI din Summary analizează intenția utilizatorului și îți arată exact ce topic-uri aduc rezoluții de succes și care dintre ele îi fac pe utilizatori să abandoneze sesiunea sau să ceară un operator uman. Iată insight-ul cheie. Copilot Studio urmărește două tipuri fundamental diferite de sesiuni, iar dashboard-ul le prezintă într-o vizualizare hibridă. În primul rând, ai sesiuni conversaționale. Acestea sunt exact ceea ce sugerează numele. Un utilizator deschide o fereastră de chat și discută cu agentul. Analytics-ul urmărește schimburile de replici, sentimentul utilizatorului și declanșarea de topic-uri. În al doilea rând, ai sesiuni autonome. Acestea rulează în întregime în background. Sunt trigger-uite de evenimente externe, cum ar fi crearea unei noi înregistrări într-o bază de date sau un e-mail primit, nu de un utilizator care tastează un mesaj. Nu există o interfață de chat. Analytics-ul urmărește dacă agentul și-a finalizat cu succes logica de background sau dacă a dat de o eroare. Ai nevoie de ambele vizualizări pentru a menține un agent sănătos. Imaginează-ți un scenariu în care te uiți pe acest dashboard hibrid. Metricele tale conversaționale arată bine, dar observi un spike brusc al ratelor de fail. Dacă filtrezi după tipul de sesiune, descoperi că toate erorile se întâmplă în sesiunile autonome. Un proces trigger-uit de un eveniment, care ar trebui să actualizeze statusul comenzilor, dă fail în background. Dashboard-ul de Summary îți spune că există un fail, dar nu îți spune linia exactă de logică care l-a cauzat. Aici treci de la dashboard la datele raw. Copilot Studio stochează log-uri de execuție detaliate în Microsoft Dataverse sub formă de transcript-uri. Descarci transcript-ul specific pentru sesiunea autonomă care a dat fail. Citind transcript-ul, obții un trace pas cu pas al execuției. Poți vedea exact variabila care a pasat o valoare invalidă, poți identifica nodul care dă fail și poți repara logica fără să fii nevoit să recreezi eroarea orbește. Dashboard-ul îți spune unde să te uiți, dar transcript-ul îți spune ce să repari. Dacă vrei să mă ajuți să continui cu aceste breakdown-uri tehnice, poți susține emisiunea căutând DevStoriesEU pe Patreon. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și spor la construit!

Model Context Protocol

3m 57s

Descarcă

Salut, sunt Alex de la DEV STORIES DOT EU. Microsoft Copilot Studio, episodul 15 din 15. Petreci săptămâni întregi construind plugin-uri custom pentru a-i permite agentului tău să facă query-uri în bazele de date interne și să facă trigger la acțiuni. Apoi, se lansează o nouă platformă și te trezești că rescrii exact aceleași integrări de la zero. Soluția la acest ciclu nesfârșit de muncă redundantă este Model Context Protocol. Model Context Protocol, sau MCP, este un open standard care conectează modelele de AI la surse de date și tool-uri externe. Adoptând un open standard, îți faci practic agenții future-proof. Scrii logica de integrare exact o singură dată, o hostezi pe un server MCP, și orice client de AI compatibil o poate folosi instant. Copilot Studio acționează ca unul dintre acești clienți. Imaginează-ți un scenariu în care echipa ta de engineering se bazează pe 50 de scripturi interne de diagnoză diferite și pe log-uri în timp real. Nu vrei să creezi și să mapezi manual 50 de acțiuni separate în Copilot Studio. În schimb, îți configurezi agentul să se conecteze direct la serverul tău MCP intern proprietar. Când agentul se inițializează, întreabă serverul ce poate să facă. Serverul răspunde cu o listă de capabilități, oferindu-i imediat agentului acces la toate cele 50 de tool-uri de engineering și resurse de fișiere live. Un server MCP expune agentului tău trei componente principale. Acestea sunt Resources, Tools și Prompts. Resources sunt surse de date read-only. Când agentul tău trebuie să verifice un fișier de configurare live sau o înregistrare din baza de date, serverul MCP furnizează acele date ca o resursă, încărcându-le direct în contextul modelului. Tools sunt funcții executabile. Dacă agentul decide că trebuie să dea restart la o mașină virtuală sau să actualizeze un tichet de engineering, apelează tool-ul MCP corespunzător, iar serverul extern execută acțiunea. Prompts sunt template-uri de instrucțiuni predefinite, furnizate de server. Ele ghidează agentul exact cum să formateze query-urile sau să interpreteze datele specifice acelui sistem extern. Iată ideea cheie. Lumea presupune adesea că atunci când conectezi un server MCP, Copilot Studio importă și salvează copii permanente ale acelor tool-uri în propriul UI. Nu așa funcționează. Aceste tool-uri și resurse sunt hostate complet extern. Copilot Studio citește dinamic ceea ce expune serverul la runtime. Dacă echipa ta de engineering adaugă al 51-lea tool de diagnoză, sau modifică parametrii unui script existent, pur și simplu actualizează serverul MCP extern. Copilot Studio reflectă automat aceste modificări. Nu trebuie niciodată să te loghezi în interfața studio pentru a da republish sau a actualiza acțiunea. Pentru că logica trăiește în întregime pe server, menții un single source of truth pentru datele și acțiunile tale organizaționale. Agentul rămâne lightweight, funcționând doar ca un reasoning engine care decide când să comunice cu serverul. Separând tool-urile de platforma specifică a agentului, îți centralizezi integrările și garantezi că AI-ul tău are mereu cele mai noi capabilități, indiferent de interfața de client pe care o faci deploy. Te încurajez cu tărie să citești documentația oficială, să încerci să conectezi un server MCP hands-on, sau să vizitezi devstories dot eu pentru a sugera subiecte pe care vrei să le vezi acoperite într-o serie viitoare. Asta e tot pentru acest episod. Mersi că ai ascultat și continuă să construiești!