Alle Broadcasts
Fabric Focus #3: AI-agenter
7 visninger
Microsoft Fabric udvikler sig hurtigt, og der kommer hele tiden nye muligheder for at arbejde smartere med data, analyse og automatisering.
I Fabric Focus går vi hver gang i dybden med et konkret emne i Microsoft Fabric. Det kan være nye funktioner, smarte arbejdsmetoder eller værktøjer, der kan gøre din hverdag lettere og hjælpe dig med at få mere værdi ud af din dataplatform.
Vi tager udgangspunkt i virkelige scenarier og viser, hvordan tingene fungerer i praksis. Målet er ikke at vise alt, men at fokusere på det, der er relevant, brugbart og værd at kende.
Du er også meget velkommen til at sende forslag til emner eller udfordringer, som du gerne vil have, at vi tager op i en kommende session.
Det får du med:
Indsigt i et aktuelt emne inden for Microsoft Fabric
Konkrete eksempler og demonstrationer
Tips og tricks, du kan tage i brug med det samme
Erfaringer fra projekter og løsninger i praksis
Mulighed for at stille spørgsmål undervejs
Agenda:
Månedens fokusområde i Microsoft Fabric
Demonstration og konkrete eksempler
Tips, tricks og erfaringer fra praksis
Spørgsmål og dialog
View transcript
Velkommen til Fabric Fokus Broadcasten. Det her er jo vores tredje broadcast i den serie vi laver, hvor Jes og jeg fortæller om Fabric-platformen, hvordan vi arbejder på den, giver tips og tricks til at vi skal arbejde på den. at jer der ser med, kan forhåbentlig udnytte Fabric endnu bedre og få nogle tricks til, hvordan man kan bruge de nyeste værktøjer, men også eksisterende værktøjer på en god måde, så man kan få mest ud af platformen. Helt sikkert. Og i dag, der skal vi snakke om AI-agenda. Også i dag. Og det gjorde vi også sidst. Men i dag er fokus på, hvor på platformen ser vi, at de passer ind. Det kan både være i udvikling, det kan være i forbrugslædet med powerbæreophorter. Hvor passer det egentlig hen? Og så giver vi et bud på et decideret workflow med AI-agenda. Altså, hvordan kan man arbejde med det? Og Jes ved demo. Til allersidst, så demoer vi det allernyeste inden for både Fabric, men også igen AI-agenda. Og det kommer vi tilbage til. Det bliver rigtig godt. Så vi har lige taget lidt tegninger med hjemmefra, hvor vi vil tage udgangspunkt i en Fabric-platform, hvor vi har en klassisk medaljearkitektur. Og snakke lidt om, hvor ser vi egentlig AI-agenda passe ind. Man kan jo sige, at sidste gang, der gennemgik vi jo hele den her del, hvor vi ligesom snakkede hele backend-delen, hvor vi kan bruge agender til at lave vores notebook, sætte vores pipelines op. Altså, orkestrere hele den her del fra RAW til silver og gold. Og det vi kommer til at fokusere på i dag, det er som sagt hele det store setup. Altså, hvordan administrerer vi det på en god måde? Og så er det den her del med Fabric-apps og data-agents, som vi også har fokus på. Så mere den her, hvad skal man sige, hvordan vi konsumerer det, der kommer ud fra vores, når vi har renset vores data og gjort det klar i vores semantiske model. Og man kan sige, at det her er jo egentlig den helt traditionelle. Altså, det flyder igennem lagene, det ender i et analytisk lag, altså en semantisk model, og vi har en eller and power-bi-rapport på toppen. Det nye er så, at vi får de her data-agents, altså hvor vi kan chatte eller spørge ind til vores data. Så i stedet for at have en rapport, så har vi en agent, vi kan skrive med eller chatte med og få nogle indsigter. Og det allernyeste, altså man kan sige, at data-agents, de er de kommet ud af... De har jo eksisteret længe. Ja, men Fabric-apps, den er sådan ret ny. Den er ret ny, ja. Så den har vi også kigget ind i. Og den er også lidt interessant. Jeg synes, det var ret interessant at dykke lidt ned i den, men den lader vi lige være som en lille slipfinger. Hvad er der interessant ved... Ja, lige præcis. Den åbner op for nogle muligheder. Det er ligesom at åbne Pandoras Eske nærmest. Jeg synes det... Jeg tror, jeg tænkte det kun som reporter, men jeg kan godt se, at det er jo alle mulige værktøjer, du kan bygge oven på dine data. Jamen lige præcis. Så hvis vi lige skal lave sådan en lille indflyvning til et workflow med AI-agent, altså hvordan vi arbejder med det, så vi går stippet ud over bare og sidder og prompte, kloger det eller chat-gbt til at skrive noget kode og så kopiere det ind i en notebook eller et eller andet på vores platform. Så vil vi gerne sætte noget workflow op omkring det, som både kan gøre det mere smidigt at arbejde med, men også kan isolere den måde, agenterne arbejder på. Fordi man kan hurtigt få lavet noget rigtig fedt og brugbart. Man kan også hurtigt få lavet noget rigtig juks. Så det vil vi gerne kunne kontrollere på en god måde med et workflow. Og det er jo også det her med, at man jo hele tiden har brug for at have en god struktur på din platform og få det sat op på en hensigtsmæssig måde. Men man kan sige, at når du også åbner op for agenter, som vi sidste gang åbner op for hele backend-delen, og vi også har det på frontend-delen, altså vi har agenter mange steder i platformen, hvor de udvikler for os, så er det bare endnu mere vigtigt, at vi ligesom har sat et godt framework op for, hvordan arbejder vi og agenterne på platformen. Og det vi tit gør, når vi arbejder ude ved kunder, det er jo, at vi bygger en fabrik-platform, og vi sørger for, at der selvfølgelig er i hvert fald tre miljøer. Et udviklingsmiljø, et testmiljø og et produktionsmiljø. Sådan så, at man hele tiden kan adskille det, der rent faktisk lever ude ved forbrugerne, ude i organisationen, fra det, som vi sidder og udvikler på, og det, der bliver testet. Så man har en logisk adskillelse og et flow fra udvikling. Test noget, der kører stabilt i produktionen. Og det spiller faktisk ind i det workflow, som... Jamen altså, det er et bud på et workflow. Der er mange forskellige måder at gøre det på. Det her er det en måde at gøre det på, som jeg for eksempel bruger ved de kunder, jeg arbejder på. Og igen, som Jess fortæller, det her er jo ikke noget nyt. Her der bruger jeg Fabric Workspaces, der er forbundet til Azure DevOps, og vi bruger Git til versionsstyring. Og det er overhovedet ikke noget nyt. Men når man arbejder med AI-agenter, så er det måske bare endnu vigtigere, at man sørger for at have den ramme op, hvor man kan isolere ens arbejde fra det, som andre udviklere sidder og laver. Sådan så, at man hele tiden har en stabil version af ens udviklingsmiljø. Og det er det, det her workflow illustrerer. Vi har et workspace i vores dev-miljø, og det her workspace fungerer som en stabil version af vores udviklings -data-platform, af vores dev-platform. Og når jeg så gerne vil lave noget nyudvikling, så har jeg forbundet mit workspace til Git, og det ligger så i en branch, vi kalder main. Jeg laver så en ny branch, som vi kunne kalde en feature branch, hvor jeg gerne vil lave noget nyudvikling. Og den her feature branch er egentlig bare en repræsentation af det, der har liggende i min main branch. Og den her feature branch, den er nu isoleret fra alt det kode, der ligger i main. Og den synker jeg så ned i et separat fabric workspace. Så alle de ting, jeg har liggende i mit stabile udviklings-workspace, det ligger nu også her i mit feature-workspace, hvor jeg kan sidde og lege og ødelægge ting, uden at det har nogen indflydelse på den stabile version af udviklings-workspacet. Og det her, hvor AI-agender så kommer ind, det er, hvor man fx kan bruge et programmeringsprogram som VS Code, hvor vi kan bruge AI-agender og skills og instructions og alle de ting, vi efterhånden kender til, til at udvikle nye features. Og det er det step, der ligger her, hvor jeg forbinder min feature branch til VS Code. Og så bruger jeg AI-agender og sidder og chatter og siger, jeg vil gerne bygge en ny notebook, jeg vil gerne ændre det og det og det. og det gør de så. Og ændringerne, de bliver så committed tilbage til den her feature branch. Det kan jeg så vælge at smide op i mit workspace i Fabric og teste det der, hvordan ser det ud, ser det rigtigt ud. Hvis det gør det, så merger jeg mit ændringer tilbage til main branchen. så er der lige nogen, der kigger det igennem, tester, ser det egentlig ud som tiltænkt. De går måske over i det her udviklingsworkspace og kører nogle notebooks, ting og sager. Og alt er godt, så bliver det lagt ind i den stabile version i udviklingen, videre til test osv. Så det her workflow med git, det er ikke nyt. Men det ligner jo fuldstændig det, vi også har gjort, når vi har været mange, der har squabberet sammen. Lige præcis. Og det er jo, havde vi bare lavet en pil i den her vej, VS Code, A-agenter, direkte op i vores udviklingsworkspace. De sidder bare og laver alt muligt, og lige pludselig så har vi et workspace her, der er fyldt med alt muligt skrald. Der er måske noget, der er klar til at blive skubbet i test, men der ligger også alt muligt skrald, som måske aldrig skulle have været der. Så det handler om at få adskilt tingene, og det er det, det her workflow gerne skulle illustrere. Men det er også det der med, når vi, altså det her, det her, det var også vigtigt inden A-agenter. Ja, præcis. Men når vi speeder alting op, og vi mister også lidt sådan fornemmelsen af, hvad er det helt præcis? Vi sidder jo ikke og koder noget på samme måde. Det er vi gået lidt væk fra. Så det her med at få delt tingene op, og ligesom sørge for at begrænse det her, og så bruge mere tid på at teste. Det var vigtigt før, men det bliver bare mega vigtigt, når du lige pludselig arbejder med sådan en hel A-framework, med agenter, der udvikler det hele. Ja. Så en ting er at se det på et billede som det her. Hvordan ser det egentlig ud? I Fabric og i VS Code. Nu hopper vi over i mit Fabric Workspace. Kigger lige på oversigten over Workspaces. Så her. Fabric Focus, det er det, der agerer som mit main udviklingsworkspace. Jeg har så lavet det her feature workspace, som egentlig er en kopi af main workspacet, og det er forbundet til GitHub. Og det er så her, at jeg kan sidde og udvikle Notebooks, pipelines, whatever, alle de ting, som gerne skulle ryge ind i main, og til sidst i produktionen. Det her workspace er forbundet til mine feature brands, og i VS Code, hvor det er jo egentlig der, jeg rigtig gerne vil bruge agenterne, og rent faktisk lave min udvikling. Nu hopper jeg over i VS Code. Der er jeg også forbundet, kan man se hernede i venstre hjørne, til den branch, der hedder feature A. Og jeg har så, hvor vi ikke skal sidde og kigge på, at der er en eller anden agent, der itererer over det, jeg har bedt den om at gøre, men så har jeg gjort det hjemmefra. Jeg har bedt min agent om at lave en tidsdimension. Og det har den så gjort. og jeg har allerede committed den kode, som den har lavet, til mit feature, min feature branch. Så det vil sige, at, hvis vi går over i tegningen, jeg har allerede været i gang her. Jeg har lavet den her commit til min feature branch, og nu kan jeg så gå tilbage, i mit feature workspace, i Fabric, og synke ændringerne, så jeg kan se, hvordan ser det egentlig ud. så tilbage i Fabric, der er jeg jo her i mit feature workspace, under source control, der kan jeg se, der er en update, og det er den her tidsdimensions notebook, som jeg har fået nogle agenter til at lave. Hvis jeg updater den, så burde den meget gerne blive en del, af mit feature workspace også, og så kan jeg køre den derinde, og teste, virker det egentlig så efter hensigten. man kan også godt køre ens notebooks, direkte i VS Code, med forbindelse til en Fabric Runtime, og så videre, og det er det, hvad hedder det, workflowet, kan se forskelligt ud. Godt tilpasse workflowet lidt, men det her, det er sådan rimelig meget, hvad vi vil gå med, som en standard workflow, og så kunne du tilpasse det, alt efter, hvordan arbejdsgangen er, hos den enkelte kunde. Så kan man sige, så ligger den her, NB Time Dimension. og det jeg så vil gøre, det var jo at sige, nu ligger det her, det ligger her, så vil jeg lave en pull request ind til main, og der er så en af mine kolleger, der lige skal tjekke igennem, virker det her covid egentlig, og så går de jo så ind i den her, det her feature workspace, tester det, siger god, og så skyder vi det i main. Og årsagen til, at vi gør det her, som vi har sagt mange gange efterhånd, det er jo, så vi ikke bare alle sammen kører direkte den her vej, på udviklingsworkspacet, så vi får det separeret, og agenderne, at udviklerne kan arbejde isoleret set, og sådan set samarbejde meget bedre, fordi du ser jo også nogle gange, det oplever vi jo også, at nogle gange, altså fordi de er jo autonome på den måde, de har jo selvfølgelig fået nogle instrukser, men nogle gange går de jo, altså gør de jo også nogle ting, hvor vi siger sådan, det er ikke det, I skal gøre, altså sletter nogle ting, gør noget, der sådan ikke er hensigtsmæssigt. Og selvom man selvfølgelig sætter nogle guardrails, i sin instruks omkring, hvad du må og ikke må, så er det ikke ens betydende med, at det bare er noget, den ikke kan se forbi, og gøre alligevel, hvis den vurderer, at det er det rigtige at gøre. Så her der får vi bare skilt det ad, og vi kan nemt gå tilbage, så det er virkelig vigtigt, når vi først begynder at arbejde, sådan mere sådan, større setup med agenter, at vi får sat det rigtige, hvad skal man sige, loge op for, hvordan vi arbejder på platformen. Lige præcis. Så det er et bud på et workflow, i vores udviklingsmiljø. Så kan man sige, der er selvfølgelig også noget, noget valid brug af nogle agenter, i testmiljøet. Du kan godt have nogle testagenter, men ellers er det jo hovedsageligt, det vi bruger, hvor vi udvikler, og hvor vi har vores agenter. Så har vi her i produktionen, hvor det hele kører live, ude i organisationen, og der kan man sige, der kører platformen jo. Den kører jo i produktion, med al det udvikling, vi har lavet, og føder data ind i, for eksempel, en semantisk model. Og der er det så, at der er kommet det her, nye værktøj, der hedder Fabric Apps, som også bare er, stort set rent AI-udvikling. Ja. Du laver simpelthen en app, med natural language. Så man kan sige, platformen er jo ikke udviklet, da AI var lige så udbredt som nu. Så der er jo nogle ting, der ligesom, for eksempel Power BI, der har 10 år på banen, eller mere, 11 tror jeg, men er jo ikke udviklet til, at agenter skal bygge de her rapporter. Det giver nogle udfordringer, og det bliver bedre og bedre, og jeg kan også se, at vi begynder også at nå hen et sted, hvor vi kan bruge agenter til både banedelen, og også det semantiske del, og vi ser også, at den kan bygge nogle rapporter, men vi er der ikke, altså vi er der ikke, hvor den bare sådan lige, hvor du promter, og så bygger den bare den der Power BI-rapport. Og der har de så lavet det her Fabric Apps, hvor du promter simpelthen bare, og så kan du bygge et dashboard, altså en rapport, eller du kan bygge alle mulige ting. bare i kode. Ring kode. Med en agent. Så den har jeg dykket ned i, og det kan være, at vi skal skifte til min skærm, og så dykke lidt ned i, sådan jamen, hvordan kommer vi i gang med at bygge de her Fabric Apps, og hvad er det? Altså, hvis jeg starter med sådan bare at sige sådan, jamen, altså jeg har for eksempel bygget den her, den her rapport, og den har jeg bare formet mig til ved hjælp af en agent. Fabric Apps, de lever bare i Fabric-platformen, altså alt. Al infrastruktur, det er bare rent Fabric, eller hvad? Ja. Så det her, det er en rapport, og så kan man mene om den, hvad man har lyst til, men den er jo sådan rimelig hurtigt lavet, og så er den connected til min CRM-datamodel. Så jeg kan ligesom bygge den videre med andre sider, og ligesom udvide min app, eller min rapport her. Og det man lige skal huske på, det er jo fedt, fordi man bare kan chatte sig til en rapportside, men alting skal også bygges for bunden i kode. Så jeg prøvede for eksempel at lave sådan en datepicker, eller sådan en datoslicer, og det ville den ikke lige, fordi så var der nogle bugs der, og jeg må endelig med at sige sådan, nej ved du hvad, jeg fjerner den lige, fordi vi skal også bruge noget demo, der fungerer. Men lad os bare lige tage, altså der er en guide inde på løen, hvor vi ligesom, hvordan opbygger man ligesom sådan en fabric app. Og der er nogle instrukser, dem kan I bare gå ind og finde bagefter, det behøves vi ikke at gå i detaljer med, men jeg har egentlig gjort en prompt klar, og man kan sige, og gjort den klar over i VS Code, jeg bruger GitHub Copilot, og der kan vi så sætte den i gang, med at bygge en helt ny app, og man kan sige, nu går den så i gang, men altså her der er ligesom, jeg siger, okay det er en broadcast demo app, og det skal væk i det her workspace, som vi har, og så er der nogle andre ting, den ligesom har fået med nogle instrukser. Det vi prøver at bygge, det er sådan en app til, sådan en to-do app. Så du kan have mange andre ting, end bare at bygge rapporter. bare sådan et substitut for en powerbær rapport. Du kan nærmest lave alt, hvad du ellers ville lave i en app. Ja. To-do-lister, eller ting jeg ikke lige kan komme på, men det er jo nærmest, at det sige, at sætte grænser for, hvad du kan bruge med de her fabric apps. Ja, det gik i hvert fald op for mig, at vi lader den bare lige køre, den står bare, og så kan vi vende tilbage, når den lige, det kan godt lige tage et minut tid. men det, der gik op på mig med, at sætte det her op, det var sådan, jeg havde tænkt, okay, det er en måde at bygge rapporter med agenter, men det viser sig jo bare ret hurtigt for mig, at det her, det er en måde at bygge alle mulige dataprodukter. Om det er en app, lidt ligesom vi kender fra en powerapp, altså med noget input, der bliver lavet i en SQL database, eller det er et eller andet helt andet. altså det er sådan, du er ikke begrænset af, kunne ind i en powerbjerg, powerbjerg desktop, når du bygger, du kan bygge alt, og det er bare kode, og det er i fabric, så du bygger på det samme data, du har tilgængeligt, men alt ovenpå, der er ikke nogen begrænsninger. Det var også som du siger, du får heller ikke noget foræret. Når du åbner en powerbjerg desktop, så har du al funktionalitet foræret, lige ud af boksen. Så hvis du skal lave et eller andet rapport, tænker jeg, som godt kan leve i powerbjerg, og du kan bruge alle de standard ting, der er, så skal man selvfølgelig gøre det der, fordi du kommer hurtigt til at bruge meget længere tid på at lave en hulens masse kode og prompts, for at få alt det her funktionalitet til at virke. Så det er måske mere sådan, hvor man siger, det er noget, som du også er inde på, der går ud over, hvad der er muligt i powerbjerg. Det kan være, at du har nogle infoskærm, hvor du gerne vil lave nogle, nogle visninger, som bare ikke er mulige i powerbjerg. Ja. Eller det kan være, at du har et meget konkret projekt omkring et eller andet input data, en eller anden app, eller et eller andet, du skal registrere, eller et eller andet, du skal følge op på, der skal sættes et eller andet workflow i gang. Altså et eller andet, der kræver, at du selvfølgelig har de data tilgængelige, du skal reagere på, men hvor du også har brug for en eller anden visual repræsentation, et eller andet, hvor du skal gøre et eller andet, eller sætte noget i gang. der giver det jo god mening, men lige så snart, at man bare skal bygge en rapport, hvor du bruger nogle af de basale, hvad skal man sige, visninger, der er, så er powerbjerg stadigvæk meget relevant. Altså man kan sige, hvis jeg deler den her rapport, jeg har lavet, så kan man sige, hvis nu for eksempel, jeg vil drille ned, det er jo meget klassisk, du vil gerne drille ned, du vil gerne sige, det er 10 opportunities, hvad er det for nogle opportunities? Det vil jeg jo skulle prompte mig til, at sige, at jeg skal lave en drill page, og at den skal ligesom fungere på den her måde. Det kunne også være, at jeg vil have et bookmark, så jeg kunne trykke på et eller andet, og så kom der et eller andet frem. Igen, det skal jeg prompte mig til, og så ved jeg godt, når du så har bygget det en gang, så kan du jo genbruge det, så det er jo ikke fordi, at det ikke er muligt, at man skal bare huske på, at det er funktionalitet, som du bare klikker, og så er det der i Power BI. Så det er lige, hvor use casen er, men jeg synes, jeg synes, det åbner op for nogle ret fede muligheder. Der er meget spændighed i use cases, det er der helt sikkert. Og det er også ret fedt jo, at hele appen er jo bare en del af din Facebook-platform, og når du deler den med andre, så er det jo entra, det er single sign-on. Sikkerheden er der omkring appen, i forhold til, hvis nu du har fået vibe-coded dig til en eller anden app med klod, og så vil dele dem i en hel masse, så er der ikke samme sikkerhedsslag. Du får også mange ting foreret på den måde, ved at lave en fabric-app, hvis behovet er det til interne værktøjer, eller eksterne rapporter. For mig er det både interne og eksterne, at du lige pludselig kan sætte dit data i spil på en anden måde, end bare rapporter, og du er ikke begrænset af, at du skal også integrere det ind i en power-app, og du har det hele på platformen, og mulighed for at bare bygge det. Hvis du har en idé, så kan du prøve at bygge det. og det er bare kode. Skal vi prøve at se den over? Du har også sådan en video. Den står køre, køre, køre. as expected. Vi kan se, om den har en app. Så vi kan se, at den har lavet en app. Den har forbuddet den til min SQL-database. Så altså, mens vi har stået og haft den her broadcast, så har den jo ligesom lavet det her. Jeg kan godt være bange for, at jeg lige skal lave en deployment, inden vi kan se noget. Men lad os prøve at åbne op no app deployed. det prøver vi lige at sige til vores agent. Kan du bøje den? Se den. Så er det blevet spændende at se. Kan den det? Og Microsoft skriver jo faktisk, selvom de har Fabric Apps inden på Learn, at de er virkelig gode til, altså hvis du skal lave mock-ups og interne værktøjer osv. Måske, som vi også snakker om, knap så gode til, altså det er ikke en erstatning for powerbær-rapporter, som kører, som de altid har gjort i en organisation. Ja. Altså det er lige, det kan vi lige, mens den lige får deployedet den, jeg tror, den er lige ved at være der. Der kan man sige, det man lige skal, altså det er jo et preview feature. Altså den er ikke GA endnu, Fabric Apps. og inden man overhovedet kaster sig ud i at lige skulle i gang med at bygge en Fabric App, så skal det lige slås til, fordi når det er en preview feature, så skal du lige ind og lige slå til, at du må bruge de her nye værktøjer. Og så er det nummer to ting, jeg fandt ud af, det er, at lige nu, hvis du er i Northern Europe, som de fleste af os er med vores tenant, så er det ikke tilgængeligt. Så jeg måtte oprette en tenant i Western Europe, eller min kollega Kasper har oprettet en i Western Europe, og så kunne jeg så bygge den. Men lige snart det bliver GA, så kan vi alle sammen ligesom bare bruge det. Det må man jo formode, at det er tilgængeligt i alle regioner så. Det er det. Måske. Og det er jo så også, så er det jo heller ikke gidsupporteret endnu. Det er det. Så du kan ikke på samme måde, som det workflow, vi har vist tidligere her, have det som en del af din versionsstyring, de her Fabric Apps. Det kommer formentlig også. og så er appen faktisk færdig. Min To Do App, den har bygget, og jeg kan skrive broadcast, og at en, det er en high. Den er vigtig. Den er vigtig. Og vi skal teste, test. Og den er low. Det er ikke så vigtigt at teste. Har vi igen noget? Så der har vi ligesom fået dem her, og den skulle så gerne skrive ned i den tilhørende SQL database, så vi kan se de to linjer. Tables. To Do's. Og der er de så. De ligger der. Test og broadcast, og priority, low og high. Så altså på ingen tid har vi bygget en To Do App, og den lærer data ned i vores SQL database, og vi har bare gjort det ved at chatte lidt med en agent i VS Code. Og jeg synes der, brugerfladen er da rimelig lækkert, hvis du går tilbage til appen der. Det er sikkert til at spille den sammen. Og jeg kan sætte den til completed, og så vil I se over i i hvad hedder det, i i i databasen, hvis jeg lige opdaterer. løb den igen. Ja, så det fungerer, den skriver ned mere eller mindre i realtid, når du laver ændringer, og viser ændringerne også direkte i appen. Det gjorde det i hvert fald, da vi testede det. To Do's, og så skulle du gerne have ændret den til, at den er completed. true. Det virker. Det fungerer meget godt. Jeg synes, det åbner op for et spændende perspektiv omkring at bygge disse der dataprodukter i Fabric Apps. Helt sikkert. Det er et nyt spændende produkt, og man kan sige, det er jo bare natural language, altså du sidder jo bare og promter. Det er jo det samme, jeg gjorde, da jeg skulle lave den her tidsdimensionsnotebook, som jeg viste tidligere. så alt, hvad kan man sige, meget af udviklingen går i den retning, hvor det er ikke os, der skriver kode. Vi er system og platformarkitekter, og kan selvfølgelig altid stadigvæk validere det, som kommer ud af agenten, og stadigvæk huske at begrænse, isolere så meget som muligt. Det her med at skrive kode, osv., det er agenterne, der gør det. Det gør de. Sådan er det. Men det åbner op for nogle spændende ting. Jeg tænker, vi skal runde af, og vi vil lige opsummere, hvad det vi lige har været igennem. Vi har jo fokuseret på, hvor er det agenter, de spiller ind. Vi havde broadcasten sidste gang med backend-delen. Vi har nogle af de nye perspektiver på, hvordan vi konsumerer data. Vi har hele, altså hele opsætningen. Hvordan har du godt framework til at arbejde med? Hvordan kan du arbejde med agenter? Og så til sidst, demo af, hvordan man egentlig bare ved hjælp af noget chat, en prompt, bygger en to-do-app, eller en rapport, eller hvad du har lyst til at bygge oven på din platform. og det var jo egentlig det, vi havde for i dag. Så tak fordi I så med. Så se med næste gang, hvor vi finder på endnu et spændende emne. Jeg kunne godt have noget med AI og fabrik at gøre i hvert fald igen. Det er stadigvæk et hot emne. Tak for i dag. Ja, tak for i dag.