Welkom iedereen bij de MC65FM podcast. Vandaag gaan we verder dan een van de meest gebruikelijke gesprekken over Microsoft 365 Copilot Prompt Engineering, want... zodra organisaties Copilot serieus gaan gebruiken, verandert de vraag al snel van hoe schrijven we betere prompts. Naar hoe koppelen we Copilot aan de applicaties, data, apps, bedrijfsprocessen en kennis die daadwerkelijk in ons bedrijf draaien. En dat is waar Copilot extensibiliteit interessant wordt en uitdagend. Mijn gast vandaag is Evas Harvest, Microsoft MVP Business Application Consultant bij de AI Werkgroep in Zwitserland. Evas werkt met Microsoft 365, Azure, Dynamics 365 en het Power Platform met een specifieke focus op het uitbreiden van Microsoft 365 Copilot via agents en maatwerkontwikkeling. We gaan Microsoft 365 Copilot extensibiliteit verkennen, Copilot Studio, Microsoft Azure AI Foundry, ik weet het ook niet. Ze veranderen de naam steeds Microsoft Graph, maatwerkontwikkeling, MCPS enzovoort.

Dus ja, Evas, welkom bij de MC65 podcast. Ja, hallo iedereen, bedankt dat ik erbij mag zijn. Het is echt een goede gelegenheid voor mij om hier te zijn. Dus bedankt voor de uitnodiging. Ja, ik dank jou.

Voordat we technisch worden, kun je iets vertellen over je reis en hoe je in het Microsoft ecosysteem terecht bent gekomen.

Ja, ja, ja, natuurlijk, want ik ben mijn carrière om eerlijk te zijn niet begonnen in de Microsoft wereld. Ik begon mijn carrière in de Apple wereld. Ik was software engineer op het Mac platform en daarna ging ik over naar iOS en dat soort zaken. En oh, dat is alweer een hele tijd geleden, misschien wel 15 of 20 jaar geleden, toen ik overstapte naar de Microsoft wereld. Om eerlijk te zijn begon ik mijn carrière met C Sharp op SharePoint. En daarna stapte ik over naar de cloud, Azure en M365. Ik begon met on-premises SharePoint, zo ben ik begonnen, en daarna stapte ik over naar alle cloud diensten, uiteindelijk naar het power platform en recentelijk naar al die AI dingen.

Eerlijk gezegd, omdat het nu een groot deel van M365 is, aangezien we nu een agentische transitie doormaken en in een notendop is dat mijn reis. Maar ik begon mijn carrière in de wereld van software engineering, wat vandaag de dag misschien een woord is dat veel mensen vergeten, omdat we nu al die AI dingen hebben, en eigenlijk zijn dit soort activiteiten of banen verschoven naar AI, dus het is heel anders dan 20 jaar geleden vergeleken met nu.

Ja, je werkt, je zegt dat je met SharePoint werkt en ik zie ook dat je met Graph, Speak, Dynamics en Power platform werkt.

Hoe heeft die achtergrond je voorbereid op de huidige generatie AI ontwikkeling? Eigenlijk, eigenlijk heb ik een profiel dat echt, het is echt transversaal, omdat ik in mijn carrière met heel veel verschillende producten heb gewerkt.

Dat kunnen Microsoft en non-Microsoft producten zijn, dus ik heb eigenlijk een brede rijkwijte aan vaardigheden in heel veel verschillende technologieën en tools. Dus, eh, al mijn banen gaven me een goede achtergrond, want nu met AI is het een, het is een breed, het is een breed onderwerp omdat je verschillende soorten benaderingen en verschillende soorten technologieën hebt om nu uit te doen.

Het kan agentgebaseerd zijn, het kan meer workflow zijn, dat soort dingen. Dus, eigenlijk gaven al mijn voorrige banen me veel vaardigheden om klaar te zijn voor deze AI-transitie nu om eerlijk te zijn. Dus, ik stapte over naar low-code, naar non-e, naar pro-code tools. Dus, ja, al deze, eh, oh, ja, al deze, eh, kansen en, eh, en activiteiten in mijn, in mijn banen gaven me, eh, goede vaardigheden om voordeel te behalen in de AI-wereld, om eerlijk te zijn.

Ja, en, en nu ben je een AI-testlead. Wat doet een AI-testlead? Uw. Dat is een, dat is een echt goede vraag, want veel mensen vragen me dat. Dus mijn baan is gewoon om functionele specificaties te koppelen aan de technische, aan de technische stack.

Dus ik neem de leiding wanneer de business-analyse is afgerond. We hebben use cases gedefinieerd in de AI, eh, voor de AI-zaken. We hebben scenario's en use cases gedefinieerd. We hebben gedefinieerd, we hebben de volledige business-analyse gedaan, en mijn baan is, oké, ik neem deze behoeften en ik koppel die behoeften aan de technische stack achter de schermen.

En daarna leid ik de volledige implementatie van de tools en de, en de oplossing, eh, wanneer we klaar zijn om te beginnen met ontwikkelen.

Ja, interessant.

Eigenlijk, veel bedrijven kopen trainingen voor hun werknemers, vooral, eh, ja, eh, voor prompt engineering, en waarom zou je zeggen dat dat niet genoeg is?

Bedoel je tegenwoordig alleen prompt engineering? Ja, ja, waarom, waarom, waarom, waarom, zij?

Waarom, is het alleen, weet je, waarom is het voor bedrijven, u, niet, niet genoeg om mensen alleen prompt engineering te leren? Ah, ja, oké, ik begrijp het, ik begrijp het. Oké, ja, ja, u, eigenlijk, om eerlijk te zijn, tegenwoordig heb je, zoals ik al zei, veel verschillende tools en technologieën, dus, en eigenlijk, op een gegeven moment, kan AI begrijpen wat je moet doen en je misschien, u, een beetje begeleiden.

Maar voor mij, u, de rol van bijvoorbeeld architect of software ontwerper, u, moet je een mens achter de schermen hebben omdat je de klant moet begrijpen.

Eigenlijk kan AI de context van de klant soms niet begrijpen. U, je ziet daar het totaalplaatje, maar achter de schermen, u, om alleen te focussen op prompt engineering, is dat op een gegeven moment misschien goed, maar je hebt meer nodig omdat je achter de schermen, u, mensen nodig hebt die, u, architecten of software engineers zijn, en eigenlijk veel mensen met vaardigheden in technologieën, u, informatietechnologieën zoals SharePoint, zoals OneDrive, zoals ik weet niet, of Salesforce, dat soort dingen. Je moet specialisten hebben in u, die technologieën, want AI kan veel dingen begrijpen. Het kan u, het kan je begeleiden. Het kan geweldige technische of functionele documenten genereren, maar je moet mensen achter de schermen hebben die controleren, oké, is dit goed. Voldoet het, u, aan de behoeften van de klant en dat soort dingen, je ziet, om alles te valideren en focussen op alleen prompt engineering.

Voor mij nu is, ja, het zou, het zou een optie kunnen zijn als je, als je geen u, tijd hebt om, om, te trainen of te investeren, u, in, u, in, u, in het opdoen van wat vaardigheden. Maar voor mij, je, je moet, u, goede vaardigheden hebben in de basistechnologieën waar je je oplossingen op wilt bouwen, om eerlijk te zijn. Ja, ja, en jij bent een expert in co-pilot extensibiliteit.

Waar stopt de standaard Microsoft 365 co-pilot en waar begint co-pilot extensibiliteit? Ah ja, dat is een goede vraag, want om eerlijk te zijn, twee jaar geleden toen, toen co-pilot UL werd uitgebracht en UL misschien de eerste versie, UL was de chat eigenlijk, om eerlijk te zijn, echt heel erg minimalistisch.

Eigenlijk kun je, oké, het was als een chat GPT, maar Microsoft heeft Microsoft 365 co-pilot enorm laten evolueren. Eigenlijk heb je nu, je hebt verschillende soorten functies, dus de uitbreidbaarheid is nu minder dan voorheen, want vroeger ontwikkelde je plugins en dat soort dingen, maar tegenwoordig, eerlijk gezegd, is uitbreidbaarheid wanneer je iets wilt bouwen en de orchestrator wilt aanpassen, of als je iets meer wilt personaliseren, bijvoorbeeld de gebruikersinterface, als je je agent niet alleen in Microsoft 365 chat wilt integreren, maar bijvoorbeeld ook op je website, dus uitbreidbaarheid begint wanneer je eigenlijk meer achter de schermen wilt aanpassen, wanneer je net iets meer wilt personaliseren.

Het kan de orchestrator zijn als je die wilt aanpassen, als je je interface wilt aanpassen, of als je verschillende aspecten wilt aanpassen waar co-pilot chat eigenlijk niet bij kan of niet kan antwoorden op de. En, en, ik denk dat veel mensen praten over agents. Um, zijn.

Waarom, waarom, waarom denken we nu zoveel in, ja, in co-pilot agents, en waarom bouwen we niet, ik weet het niet, één grote co-pilot voor alles?

Ja, het is echt interessant, want, nu, eerlijk gezegd, is Microsoft, zoals ik al eerder zei, enorm geëvolueerd.

En misschien als we zes maanden terug zouden gaan, was een agent inderdaad een onderwerp. Nu heeft Microsoft co-pilot co-work geïntroduceerd en eerlijk gezegd kan co-pilot co-work tegenwoordig veel agents vervangen.

En als we over agents nadenken, is het gewoon om de zaken te scheiden, want we zitten nu meer in een multi-agent model waarbij elke agent zijn eigen scope en verantwoordelijkheden heeft. En we maken geen grote co-pilot, eigenlijk gewoon vanwege de prestaties. Ten eerste omdat, eh, wanneer je een grote set instructies en tools hebt, het qua prestaties een puinhoop wordt.

En de architectuur is nu meer multi-agent, dat kan in co-pilot studio zijn, of in een op maat ontwikkelde agent via code of custom development. Maar tegenwoordig is het beter om een multi-agent benadering te hebben, waarbij elke agent zijn eigen bereik en verantwoordelijkheid heeft wat betreft prestaties en om een duidelijke architectuur te hebben wat betreft agents. Ja, Schopenhauer. En als we hiernaar kijken, oké, ik denk aan een basis AI-agent architectuur, dan hebben we, zeg ik.

Wat wachtwoorden? We, we wachtwoorden. Oké. Maar we moeten denken aan redeneren, tools, kennis en instructies.

Hoe past dit in een AI-agent architectuur?

Het eerste waar je over na moet denken, een van de eerste vragen die je moet beantwoorden is, oké, wat is het doel? Het eerste objectief van deze agent.

Eigenlijk hangt de agent architectuur echt af van of je een low-code aanpak hanteert of een maatwerkontwikkeling, want de aanpak is totaal verschillend, omdat je bij maatwerk alles zelf beheert.

Dus je beheert de beveiliging, je beheert de hosting, je beheert veel verschillende dingen. Bij de low-code aanpak is het echt anders, want je denkt na over oké, je geeft de instructie en selecteert wat tools.

Dus in feite is de architectuur bij een low-code aanpak niet zo simpel als ik nu zeg, maar het kan heel snel gaan omdat je kunt definiëren, oké, je hebt de instructie, je kunt je tools selecteren, je kunt andere agents selecteren als je wilt koppelen.

Maar het is erg simpel wanneer je te maken hebt met maatwerk of wanneer je je eigen agent ontwikkelt. Het kan bijvoorbeeld gaan om cementen kernel, agent framework, dat soort dingen. De architectuur kan echt veel complexer zijn omdat je te maken krijgt met zeer geavanceerde concepten zoals ik al zei, beveiliging. MHM Wat betreft authenticatie, als je bijvoorbeeld meerdere tools hebt en je wilt wat NCP integreren, of als je wilt verbinden met interne tools die beschermd zijn door reverse proxies, dat soort zaken. Dus in principe moet je meer nadenken over de architectuur wanneer je werkt met aangepaste agents, bijvoorbeeld in Copilot Studio.

Wat architectuur betreft is het erg snel om de architectuur te definiëren in een maatwerktraject. Je moet omgaan met geavanceerde concepten en voor veel mensen kan dit lastig zijn omdat het echt fundamentele aspecten zijn. En UL In mijn werk, om eerlijk te zijn, krijg ik te maken met UL veel verschillende behoeften. Het kan custom development zijn, Copilot Studio of een simpele agent-in-agent-builder voor iets heel eenvoudigs. Dus, in feite, is het definiëren van een architectuur echt gebaseerd op de aanpak die je wilt kiezen. Kortom, je hebt een algemene UL architectuur die je kunt maken, maar daarna hangt het echt af van de aanpak, low-code of pro-code, begrijp je. Ja, ja, um, maar kunnen we.

UM, kun, kun, kun, kun jij de anatomie van een typische enterprise UL AI-agent beschrijven. Ja, ja, dat kan ik.

UL, in feite, als je het zo simpel mogelijk wilt houden, UL, wanneer je, wanneer je een behoefte hebt, bijvoorbeeld een IT-support-agent, UL, dan heb je in principe een set aan zaken.

Maar tegenwoordig, zoals ik al zei, heb je deze multi-agent-aanpak en ik zet de eerste agent aan het front, UL, als een soort front-end.

Dus dit is een front-agent en deze front-agent zal, UL, alle verzoeken doorsturen naar, bijvoorbeeld, verschillende agents. Dus bijvoorbeeld, als de gebruiker een vraag heeft over, ik weet het niet, Salesforce, dan stuurt hij het verzoek door naar de Salesforce IT-support-agent.

Zie je, voor sommige klanten hebben we dit soort architectuur gemaakt omdat elke agent zijn eigen scope beheert. Het kan gaan om producten zoals Salesforce. Het kan voor M365 zijn, dat soort dingen. En achter de schermen heeft elke agent een set, instructies en een set-tools.

En tegenwoordig is het beter om MCP-survers te gebruiken, want een MCP-server is nu een universele plug om UL meerdere services te integreren met AI. Dus ik heb een set MCP-survers en ik heb ook, UL, wat interne kennisbronnen. Het kan zijn zoals JIRA of een Service Now Knowledge Base, dat soort dingen. Dus je hebt een set instructies per agent.

UL en die instructies definiëren de scope van de agent en UL, wat de rol van elke agent is. En daarna, UL, heb je een set MCP-survers en misschien, UL, kennisbronnen zoals PDF-bestanden. Dus het kunnen, UL, meerdere soorten databronnen zijn.

En na, sorry, wanneer een gebruiker bijvoorbeeld een verzoek indient bij de hoofdagent, zal deze bepalen, oké, ik moet deze taak delegeren aan de betreffende agent.

Laten we eens kijken naar de mogelijkheden of.

Naar Copilot Studio, waar past dit in de algemene architectuur?

Copilot Studio is eerlijk gezegd een low-code tool van Microsoft. Ten eerste, en qua architectuur, is Copilot Studio echt.

Bedoeld voor makers, in principe voor mensen die in de eerste plaats geen ontwikkelaars zijn.

En wat betreft de architectuur, als we bijvoorbeeld het voorbeeld van IT Support nemen dat ik eerder noemde, dan past Copilot Studio daar prima bij. Architectonisch gezien doet Copilot Studio het werk, omdat je het kunt definiëren, je kunt een server instellen en je kunt eenvoudig externe of interne kennisbronnen integreren als je dat wilt. Zoals ik eerder zei, als je bijvoorbeeld een use case hebt waarbij je de orchestrator een beetje wilt aanpassen, dan kan dat niet, want achter de schermen van Copilot Studio kun je de orchestrator niet aanpassen, je activeert de AI-orchestrator en dat is het.

Je kunt bijvoorbeeld de prioriteit van de taak die je wilt uitvoeren niet aanpassen, want achter de schermen bepaalt Copilot Studio je plan en voert het daarna uit. Maar als je wat meer aanpassingsmogelijkheden wilt, moet je gebruik maken van custom development met bijvoorbeeld Semantic Kernel of Longchain, een framework dat onlangs door Microsoft is uitgebracht.

In die fase kun je eenvoudig de orchestratie aanpassen, workflows definiëren en aanpassen wat je maar wilt.

Dat is Copilot Studio als architectuur, het is echt ontworpen voor bouwers en makers omdat het heel eenvoudig is om een werkende agent te krijgen. Het enige probleem met Copilot Studio, en daar moet je rekening mee houden, is dat wanneer je je pad kiest en je architectuur definieert, je moet letten op de licenties, want dat is tegenwoordig een groot onderdeel van elke oplossing.

Tegenwoordig is Copilot Studio een beetje geëvolueerd naar een PSU-BO-model en moet je goed letten op de kostenraming, want afhankelijk van wat je wilt bereiken, is het soms beter om maatwerk te ontwikkelen omdat je het dan kunt hosten waar je wilt, de kosten zelf beheert en ze makkelijker kunt inschatten dan nu.

Want met de Copilot Credit benadering is het soms lastig om te voorspellen wat de kosten zullen zijn voor een maand, twee maanden en dat soort zaken.

En wat zijn de beperkingen van Copilot Studio?

Studio, wanneer ik moet kiezen, dan denk ik aan de, ja, Microsoft Foundry Azure, Foundry, ik weet niet wat de echte naam is en wanneer ik moet zeggen, oké, ik moet volledig maatwerk ontwikkelen. De eerste vraag om te beantwoorden is, oké, moet ik de orchestratie aanpassen?

Dat is voor mij de eerste vraag, want deze vraag vertelt je, oké, als je de orchestratie niet wilt aanpassen of diep in de materie wilt duiken over hoe de orchestratie of het plan wordt gegenereerd, kun je een low-code aanpak gebruiken met Copilot Studio, bijvoorbeeld een builder. Ook kun je dit soort tools soms gebruiken bij eenvoudige use cases.

Maar als je de orchestratie wilt aanpassen, moet je kiezen voor specifieke ontwikkeling.

In dat geval moet je Foundry gebruiken voor het model of je eigen platform, want het voordeel van maatwerk is.

Dat je modellen kunt integreren die niet in Microsoft Foundry worden gehost. Als je wilt, kun je Foundry modellen gebruiken, maar als je ook een AWS of Google platform hebt en je hebt bijvoorbeeld Gemini of Elders modellen ingezet, dan heb je bij een maatwerkaanpak de mogelijkheid om die modellen direct in je agent te integreren.

Dit is ook een voordeel en daarna kun je de orchestratie en hoe het plan wordt gegenereerd aanpassen, alle zaken komen dan in de agent Foundry terecht.

Het probleem met Foundry is tegenwoordig dat het in het begin slechts een platform was voor het hosten van modellen. Als je een paar jaar terugkijkt, was het gewoon een simpele model katalogus waar je op kon deployen.

Tegenwoordig heeft Microsoft dit product zo ontwikkeld dat je, oké, je kunt agenten maken met een Copilot Studio-achtige gebruikersinterface, eigenlijk zonder enige code.

Je kunt governance beheren, je kunt een heleboel dingen beheren. Het is echt een agentisch platform geworden, zoals Copilot Studio voor low-code en dat soort zaken. En tegenwoordig is Foundry erg lastig te plaatsen in het ecosysteem, omdat Foundry snel evolueert.

En in feite heeft Microsoft een aantal functies geïntroduceerd die eigenlijk, ik weet het niet, niet anders zijn, maar er zijn overeenkomsten met Copilot Studio wat betreft MCP-integratie en dat soort zaken.

Maar de voornaamste beperking van Copilot Studio gaat over de modellen. Dus je hebt, oké, je hebt de mogelijkheid om code te integreren of dingen te visualiseren. Maar als je bijvoorbeeld je eigen model wilt integreren omdat je een specifieke versie van je model hebt, dan kan dat niet en moet je eigenlijk maatwerk gebruiken om bijvoorbeeld je eigen LLM-platform te integreren als je dat hebt. Ik heb een klant die zijn eigen AWS-platform heeft, in dat geval kun je dit model integreren met prijzen die extern worden beheerd.

Oké, oké. En ik denk dat als we een agent bouwen, één onderwerp ook al ontegenwoordig is.

Ja, Schopenhauer.

De meeste mensen praten over MCP, het modelcontextprotocol.

Waarom is dit een van de grootste onderwerpen geworden in agentische ontwikkeling en voor iemand die er nog niet mee gewerkt heeft, wat is een modelcontextprotocol?

Ja, het is een groot woord. Eigenlijk praten veel mensen erover omdat het een groot probleem oplost.

Het gaat erom hoe je de integratie van tools, vaardigheden, misschien externe tooling naar AI toe kunt verenigen en het lost dit probleem op omdat het in het verleden zonder MCP een puinhoop was omdat veel services op verschillende manieren met elkaar communiceerden.

Je hebt verschillende technologische protocollen, verschillende architecturale benaderingen en in feite verenigt MCP hoe je services integreert met je. Het kan een AI-agent of AI-oplossing zijn als ik generieker ben, maar MCP is nu echt de manier om externe of interne tooling te integreren, of beide.

Maar MCP is nu een groot onderdeel van AI-architectuur omdat je die eenheid hebt op technologisch vlak. En tegenwoordig is het een belangrijk punt. Dit is niet de evolutie, maar in het verleden integreerde je je agent met een API. Je moet beheren, oké, hoe te authenticeren of dat te beheren of de tool aan te roepen. Nu kan de AI, oké, ik heb deze tool beschikbaar, ik kan selecteren wat ik nodig heb om het doel te bereiken.

En wat is, wat is er nu echt veranderd van, van MCP naar een API-verbinding?

Eigenlijk in het verleden, wat betreft integratie, zijn APIs eigenlijk niet intelligent. Als ik dat zo mag zeggen, APIs zijn gewoon, oké, je roept, je roept, je roept een tool aan en die geeft je data. Het verschil met MCP is, MCP is intelligenter qua architectuur, want achter de schermen heb je niet alleen tools die je data of informatie geven, maar je hebt ook vaardigheden in instructies, en verschillende soorten dingen die MCP echt intelligent maken.

En eigenlijk kan MCP de AI geven, oké, wil je dat bereiken?

Ik kan je de exacte tools geven die bij je verzoek passen en je kunt niet slechts één tool aanroepen, maar je moet deze tools aanroepen om te bereiken wat je wilt.

Dit is de rol van MCP. Het geeft de AI, oké, ik heb deze tools en daarna, eh, kun je deze of deze of meerdere tools aanroepen om je doelen te bereiken. Het geeft je, het geeft je, het geeft aan de AI de context, de echte context van, eh, alles en een API is gewoon, oké, je hebt tools, je hebt een beschrijving en dat is eigenlijk alles. Dus, dus is het, het is het model context protocol, ik, ik denk vergelijkbaar met, met, met metadata, of, of hoe werkt het?

Eh, nee. MCP achter de schermen, eh, is gewoon, eh, het is een protocol. B, eigenlijk is het, het is een technologisch protocol en achter de schermen heb je, heb je ja, je hebt metadata, je hebt beschrijvingen, eh, je hebt AI vaardigheden die meer beschrijven, eh, het is echt gericht op AI. Eigenlijk heb je vaardigheden, heb je instructies en in feite kan de AI beter begrijpen, oké, deze tools, eh, doen dat, deze tool doet dat, oké, ik kan deze vaardigheden aanroepen, ik kan, eh, deze informatie opvragen bij de MCP server om mijn taak te volbrengen. Maar je hebt, ja, je hebt, een stukje metadata, want je moet definiëren, oké, uw, de naam van de tool, wat het achter de schermen doet. Kijk, kunnen we, kunnen we zeggen dat, dat, dat de toekomst MCP is. Dus, moeten we beginnen na te denken over, ik weet het niet, bedrijven hebben honderden rest APIs binnen de organisatie, moeten ze beginnen met het bouwen van MCP servers eromheen.

Ja, ja, eigenlijk, eigenlijk, uw, werkt een MCP server uw met APIs achter de schermen. Uw, dit is in feite geen vervanging. Uw, als je, als ik dit samenvat, want de MCP server is gewoon oké. Uw, het geeft de context en achter de schermen kan de MCP APIs aanroepen. Achter de schermen, maar de MCP server is een frontend, de, de front, uw, de front, uw, de front tool die je, die je moet aanroepen, want achter de schermen ga je je verzoek, uw, versturen op basis van oké. Achter de schermen kan het een API zijn, een database, of meerdere tools. Maar als je, als je je eigen MCP server wilt hebben, bijvoorbeeld, als je intern in je bedrijf, uw, APIs hebt en verschillende soorten diensten, het kan zijn, ik weet het niet, een financiële dienst of een ouder dienst. Als je je eigen MCP wilt bouwen, moet je achter de schermen, uw, met al deze APIs omgaan en de MCP server moet al deze APIs blootstellen.

Wat zijn de, wat zijn de, de diensten, wat zijn de beschikbare tools, wat zijn de vaardigheden en dat soort zaken.

H.M. Daarna moet je achter de schermen omgaan met authenticatie, omdat de APIs niet allemaal op dezelfde manier werken, want je kunt authenticatie hebben via een sleutel, via, via dit soort dingen. Dus je moet daarmee omgaan, maar de MCP zal je de beschikbare tools blootstellen en achter de schermen kunnen al deze tools meerdere APIs aanroepen. 1 API, het kan zijn, uw, je hebt verschillende soorten architecturen achter de schermen. Oké. En U M, hoe kiest de MCP?

De juiste, de juiste tool wanneer ik, ik weet het niet, 100, 500 AI agents heb.

Uw, dat zal gebaseerd zijn op, uw, eerste zaken. Eigenlijk, wanneer, wanneer je een verzoek hebt in een agent, uw, ontdek je alle beschikbare tools. De MCP-server zal, je zult, uw, je zult controleren, oké, ik heb al deze tools beschikbaar. En eigenlijk, zal de orchestrator van de agent begrijpen, oké, ik heb dit, ik heb een LLM beschikbaar.

Daarna zul je het plan maken. Als ik het een beetje samenvat, maak je een plan met wat acties die uitgevoerd moeten worden, en daarna, in deze actie, in de actie die je wilt uitvoeren, kun je 1, 2, 3 of meer tools aanroepen om de taak te volbrengen die de gebruiker heeft verzocht. Dus eigenlijk zal de orchestrator van de agent MCP-tools begrijpen en de beste selecteren voor het verzoek. Begrijp je?

En dit is echt de rol van de orchestrator, het selecteren van tools en dat soort zaken met de hulp van de LLM, natuurlijk, want de LLM is als onderdeel van het brein en de orchestrator zal, oké, communiceren met de LLM en ook de tools om de beste keuze en het beste plan te maken om de taak te volbrengen. Ja, ik, ik denk dat veel bedrijven een tijdje geleden zijn begonnen met de PowerShell en nu gebruiken ze de Microsoft Graph API.

Kwamen er Graph en MCP'en of of hoedoende? Ja, ik denk dat eigenlijk, eigenlijk Graph API'en, om eerlijk te zijn, nee, er is geen MCP, MCP voor Graph. Als je dit benoemt, weet je, je hebt nu in de Microsoft 365 wereld, heeft Microsoft veel MCP-servers geïntroduceerd en die MCP-servers zijn achter de schermen gebaseerd op Microsoft Graph.

Dus bijvoorbeeld als je wilt, ik weet niet, de Teams MCP-server wilt gebruiken, wordt achter de schermen de Graph API aangeroepen wanneer je de MCP-server gebruikt. Dus Graph API in de Microsoft 365 wereld is centraal, want achter de schermen zal de MCP communiceren met Graph achter de schermen om het verzoeken goed te laten werken. Maar ja, tegenwoordig is Graph ook centraal in Copilot in het algemeen, omdat de semantische index van Copilot gebaseerd is op ruwe data, maar eigenlijk, weet je, verbruik je Graph via MCP-servers.

Tegenwoordig is het de, is het zo.

Microsoft 365 bevat ongelooflijke waarden, organisatorische contexten, documenten, vergaderingen, e-mails, mensen, teams, gesprekken en, zeg ik, gedeelde inhoud. Hoe stellen we die context bloot zonder ja? Een beveiligingsnachtmerrie te creëren?

Bedoel je in termen van governance en dat soort dingen?

Ja, het is altijd een probleem omdat veel mensen een agent te bouwen zonder achter de schermen voor de juiste governance te zorgen. Dus ik wil een agent bouwen, oké, laten we beginnen. We bouwen en implementeren en daarna, ah maar u, oké, deze agent zal met veel data werken. Hoe beheer ik dat? De eerste vraag is, oké, hoe zet ik het beheer van de agent op? Uw, voorheen kon het, zoals je zei, een puinhoop zijn. Omdat, uw, veel mensen willen, oké, ik wil agent, agent, agent bouwen, of ik wil iets bouwen, uw, ik wil een AI-oplossing bouwen. Maar achter de schermen, uw, een van de dingen, als je in een Microsoft 365 context bent, bijvoorbeeld, is een van de eerste dingen die je moet doen, oké, je data begrijpen. Want zonder je data te begrijpen, uw, ben je verloren. Je moet je data begrijpen, want het is belangrijk om te weten, oké, uw, werk ik met vertrouwelijke gegevens of niet. Werk ik met uw zeer vertrouwelijke gegevens?

Oké, uw, je moet je data begrijpen. Daarna, als je in een Microsoft-omgeving zit, moet je bijvoorbeeld DLP-functies, vertrouwelijkheidslabels en dat soort dingen implementeren, want zonder dit, uw, zou het een probleem kunnen zijn. En daarna moet je je data ook een beetje opschonen, want uw, AI-met, met slechte data, zal je agent niet werken zoals je wilt, want uw, als je een puinhoop hebt in je, ik weet niet, SharePoint, uw, Teamkanaal, dat soort dingen. Als het een puinhoop is, uw, zal het in feite moeilijk zijn om correct te werken, uw, in de, in de agentbenadering. Maar ja, je moet je data begrijpen, je moet wat uw, basisbeveiliging implementeren, zoals uw, authenticatie, zoals ik zei, Purview-functies uw, en Purview is een centrale oplossing geworden om, om al deze uw, al die beveiligings- en governance-middelen op een plek te krijgen. En nadat je je data hebt opgeschoond, wanneer je een aantal basisbeveiligingen hebt ingevoerd, moet je ook begrijpen hoe het zit met licenties, want voordat je begint met het bouwen van een agent, moet je weten, oké, wie zijn de ontwikkelaars?

Zijn ze daarvoor opgeleid? Hebben we de juiste licenties om te starten? Hebben we abonnementen nodig? Dat soort zaken.

Een groot probleem is de tooling, hoe integreer ik al mijn tools op de juiste manier in mijn ontwikkeling en mijn agent, moet ik bepaalde zaken beperken. Eerlijk gezegd is dat een grote vraag, je hebt verschillende activiteiten om rekening mee te houden, maar voor mij is het allerbelangrijkste dat je je data begrijpt, want als een bedrijf de data niet begrijpt, zal het in het begin al een probleem zijn.

Oké. En Ul? Wanneer, wanneer, wij, hoe? Hebben we het uw oké gevraagd? Ul? Het beveiligingsonderwerp, Ul? Ik denk dat er daar 2-2-2. Oké. Ja, 2-2 soorten mensen zijn.

De een zegt oké, ze hebben gebruikersrechten nodig en de ander zegt dat ze applicatierechten nodig hebben.

Hoe zou een agent over het algemeen moeten werken?

Over het algemeen en mijn beste aanbeveling is eigenlijk, wanneer je met agentoplossingen werkt, doe het altijd met gebruikersrechten, gedelegeerde rechten, want qua beveiliging is dat eerlijk gezegd beter omdat de gebruiker alleen werkt met data en tools waar hij toegang toe heeft.

Dat, dat is het belangrijkste principe. Als je daarna applicatierechten nodig hebt voor een specifieke API of context, dan kan dat.

Maar gebruik niet direct applicatierechten, doe het liever in de context van een wrapper. Dus je maakt, ik weet het niet, bijvoorbeeld een MCP-server, en je integreert die MCP met applicatierechten op de achtergrond.

De MCP roept dan bijvoorbeeld jouw API aan op de achtergrond met applicatierechten en geeft je vervolgens de informatie die je nodig hebt, maar de gebruiker werkt niet direct met de applicatierechten. Wij roepen de MCP-server aan met gebruikersrechten en de MCP-server roept op de achtergrond applicaties of services aan met specifieke applicatierechten. Zie je het verschil?

Uw oké. Uw interessant.

Ik denk dat als we nadenken over architectuur, we ook wat dieper moeten kijken.

Ik denk dat er drie grote onderwerpen zijn binnen de architectuur. We hebben Retrieval Augmented Generation, we hebben het kennisonderwerp en we hebben wat ik noem Enterprise-se arch via de achterdeur.

EHM Waar laten we beginnen met met RAG? Waar past RAG in de architectuur?

A. RAG Om eerlijk te zijn, is RAG eigenlijk de meest om eerlijk te zijn qua prestaties, omdat AI verschillende soorten data moet begrijpen en in feite is RAG hierom een vraag te beantwoorden. Want in het verleden, toen we geen RAG hadden, moest je in feite omgaan met andere benaderingen.

Niet echt ouderwets, maar het was ingewikkeld.

Maar RAG is essentieel omdat RAG verschillende soorten data begrijpt en je in feite de informatie ophaalt die de AI nodig heeft uit documenten, het kunnen meerdere verschillende soorten data zijn.

Dus ja, RAG is tegenwoordig centraal in AI-architectuur. Ja, maar het klopt dat voor veel gebruikers, wanneer je praat over wat er achter de schermen bij RAG gebeurt, ze niet weten wat het is omdat Microsoft of veel andere softwarebedrijven hier tegenwoordig niet over praten, omdat er achter de schermen RAG zit.

Maar bijvoorbeeld in Copilot Studio begrijpt de gebruiker niet dat er achter de schermen RAG zit, zie je. En tegenwoordig, als je dieper wilt duiken, oké, dan heb je dit soort concepten, maar voor veel gebruikers is RAG totaal onbekend omdat ze gewoon de tool gebruiken en die concepten achter de schermen zitten.

En dan hebben we het volgende onderwerp, het is kennis, hoe krijgen we dit, waar halen de AI-systemen hun kennis vandaan?

Is het een verzameling of hoe werkt dit?

EHM eigenlijk, om eerlijk te zijn, de kennis is.

Kan gehost worden in heel veel verschillende systemen.

Het kan een plat tekstbestand zijn, een markdown bestand, een kennisbank, het kan van alles zijn. Maar eigenlijk, als je een MCP-server hebt, kun je die kennis benaderen. Of als je bijvoorbeeld, ik weet het niet, connectoren hebt naar SharePoint, je hebt tegenwoordig voor veel diensten connectoren, dus toegang krijgen tot die kennis is makkelijker dan vroeger, laten we eerlijk zijn. Want in het verleden moest je je eigen plugin bouwen en alles zelf instellen. Tegenwoordig heb je een directe verbinding met elk systeem en kun je je kennis integreren zonder dat je grote ontwikkelteams nodig hebt.

Ik denk, ik denk vaak, heb ik, ik weet het niet, ik verzamel dit voor mijn, ik zeg tegen mijn, ik weet het niet, iemand.

En hoe begrijpt AI welke documenten niet klaar zijn, of verouderd zijn, of ik weet het niet, dubbel zijn? Hoe, hoe kan, hoe begrijpt een AI-systeem dit? Wat moeten we gebruiken en waarvoor?

Eigenlijk gebruik je RAG omdat je achter de schermen moet begrijpen wat je data is.

Maar eerlijk gezegd, als ik het een beetje samenvat, begin je bij de prompt, oké.

De gebruiker wil, oké, je wilt bijvoorbeeld zoeken in, ik weet het niet, een kennisbank en bijvoorbeeld OneDrive. Achter de schermen, wanneer de orchestrator met behulp van een LM de prompt en de intentie van de gebruiker begrijpt, heb je in feite de index.

Want in Copilot heb je bijvoorbeeld de semantische index en deze semantische index geeft je eigenlijk inzicht in alle kennis en de AI kan die semantische index direct bevragen om bijvoorbeeld RAG uit te voeren, zodat je direct de juiste documenten kunt selecteren op basis van de behoefte. Maar in Copilot heb je deze semantische index en de AI kan deze index achter de schermen direct in natuurlijke taal bevragen. Dus ik vraag, oké, ik wil begrijpen, ik weet het niet, hoe ik mijn bedrijfs-VPN moet instellen.

En achter de schermen voer je RAG uit op de semantische index en haal je in feite het document op dat bijvoorbeeld de volledige configuratie van de bedrijfs-VPN bevat. In Microsoft 365 Copilot Chat is dat achter de schermen bijvoorbeeld de Graph API, want zoals ik al zei, is de semantische index gebouwd op de Graph API.

Het is achter de schermen een Graph-functie, maar bij maatwerkontwikkeling heb je bijvoorbeeld Foundry-AQ achter de schermen.

Het was een Azure Surface met een andere naam. Maar nu kun je je eigen RAG-systeem hebben als je dat wilt. En eigenlijk kun je UL, wanneer je een aangepaste agent hebt, dit direct vragen aan de Foundry-AQ-instantie. Oké, UL, ik wil UL, ik wil de configuratie van UL, mijn VPN-bedrijf en de AI kan UL ophalen wat UL je nodig hebt aan documenten.

Dat kunnen PDF's zijn, Word, Excel, dat soort dingen.

En, en, dat is hoe de de zoekfunctie werkt, toch?

Of UL achter de schermen, bedoel je? Ja, A, achter de schermen, ja, je hebt de de zoekfunctie.

UL, maar eigenlijk heb je tegenwoordig UL achter de schermen en achter de schermen van UL van Copilot UL Copilot Chat heb je drie UL drie mogelijkheden. Je hebt de standaard zoekfunctie, wat eigenlijk een zoekopdracht is waarbij je okéën voert, simpelweg UL wat trefwoorden in en UL je zoekt in UL je documenten en dat soort dingen.

Dit is een eenvoudige zoekopdracht. We kennen allemaal trefwoord zoeken zoals Google. Daarna UL heb je twee verschillende UL-mogelijkheden.

Je hebt eerst de RAG achter de schermen. Je hebt de mogelijkheid van RAG in InBreath en je hebt ook UL de Copilot Semantische Index zoekopdracht die een beetje anders is omdat RAG echt geavanceerder is dan de Copilot Semantische Index zoekopdracht. Maar je hebt al deze drie mogelijkheden achter de schermen om ervoor te zorgen dat jou UL het ben je niet zelf, maar achter de schermen kan de AI deze drie UL verschillende mogelijkheden aanroepen om de gegevens op te halen uit OneDrive, Teams en 365 in het algemeen daarna. Hij kan de Semantische Index van Copilot bevat ook de Copilot Connectoren. Dus bijvoorbeeld als je een Salesforce hebt verbonden met de Copilot Connector, kan het ook zoeken in al je gegevens in Salesforce in ServiceNow in meerdere tools. Omdat het alles UL met de Copilot Connector heb je alle gegevens geïntegreerd in de Graph, UL, Index, Semantische Index, kun je direct je externe systemen bevragen.

MHM Oké, en UM ik denk het.

Wanneer we agents bouwen hebben we het governance gedeeld en een van de onderdelen is voor mij ook zeg maar agent lifecycle management. Ha, hoe ziet dit er eigenlijk uit?

Hoe ziet het er eigenlijk uit? UL eerlijk gezegd, in het Microsoft ecosysteem is het vrij eenvoudig als ik dat zo mag zeggen. Omdat wanneer je, wanneer je te maken hebt met low-code, bijvoorbeeld Copilot Studio, heb je te maken met Power Platform. Concept al en UL, er is niets veranderd. Dus, je hebt oplossingen, je hebt An op zijn plek, je hebt pipelines. Dus, als je met Copilot Studio werkt, is het eerlijk gezegd zoals voorheen, omdat je alle zaken hebt waarin je hebt geïnvesteerd op het gebied van Power Platform Governance. Levenscyclus en al. Het is precies hetzelfde. Uw, dit is een goede zaak, want veel mensen vragen me, oh, Copilot Studio, hoe beheer je dat? Is het anders? Aanhalingsteken, nee, het is heel simpel, zoals bij Power Apps of Power Automate applicatie Levenscyclusbeheer. Dus, in dit geval is het agent Levenscyclusbeheer, maar achter de schermen is het hetzelfde concept als bij het Power Platform.

En wanneer je te maken hebt met UL, bijvoorbeeld, maatwerk, is het eigenlijk hetzelfde als wanneer je UL applicaties bouwt, .net applicaties, dat soort zaken, omdat je alles als code beheert.

Dus, je hebt frameworks, je hebt beveiligingsaspecten, dat soort dingen. Dus alles om eerlijk te zijn, UL, qua applicatie en agent Levenscyclusbeheer, is echt hetzelfde concept als voorheen. En dit is voor mij een goed punt, omdat je niet veel hoeft te investeren, UL, in termen van, UL, Levenscyclusprocessen en dat soort zaken. Maar het enige is dat je wat veranderingen hebt, UL, maar UL, een van de grote veranderingen is, oké, je moet rekening houden met LLM, dat soort dingen, deployment, dat soort zaken. Maar achter de schermen lijkt het op de DevOps-aanpak uit het verleden, met pipelines, dat soort dingen. Dus, naar mijn mening is er niets veranderd, omdat we agents beheren.

UL, het kan maatwerk of copilot zijn, je gebruikt tegenwoordig eerlijk gezegd dezelfde aanpak als voorheen. En, en, dit dit betekent of of wanneer wanneer een bedrijf tussen ze nog geen AI in het bedrijf gebruikte, maar ze hebben de perfecte setup voor Purview, voor Defender en al, al, al de tools daarnaast.

Is er dan enige verandering nodig of betekent dit AI-gereedheid? A, het is het is en het is een grote vraag, omdat AI-gereedheid, UL, voor, voor, voor Microsoft, UL, is oké. UL, UL, ben je scherp op permissies, beheer je dat soort dingen? Maar, UL, oké, AI-gereedheid is voor mij niet alleen een technische aanpak, want oké, technisch gezien weten we wat we moeten doen. Oké, we moeten permissies beheren over een hoop services, weet je? Voor mij moet AI-gereedheid ook, UL, de data omvatten, de data, begrijp je.

Want, UL, als je je data niet begrijpt, zoals ik al zei, UL, dan kun je, UL, kun je het technische gedeelte niet beheren, want, UL, als je niet weet wat wel of niet vertrouwelijk is, is, bijvoorbeeld, UL, is het lastig om enige, enige beveiliging, enige beveiligingszaken in te stellen.

Maar als we, als we Microsoft volgen, is AI-gereedheid oké, je moet machtigingen beheren, je wilt vertrouwelijkheidslabels instellen, UL, je moet voldoen aan de AVG, UL, dat soort dingen.

Maar je hebt ook een meer hoogwaardig, UL, hoogwaardig, UL, aspect, en voor mij is AI-gereedheid niet alleen technisch, je hebt tegenwoordig ook een functioneel of hoogwaardig aspect om rekening mee te houden, eerlijk gezegd.

UM, ja, dat is echt interessant, um, ik denk dat veel bedrijven, dit was begonnen met de AI, maar nu met met agents zeggen veel bedrijven, oh, het heeft al mijn ik weet het niet, e-mails verwijderd of doet iets kwaadaardigs, kwaadaardigs.

Um, hoe dacht je wat wat zullen bedrijven, zeggen ze, ze zijn bang voor AI? Het is, het is een goede vraag, want ik woon in Zwitserland en in feite hebben we, hebben we veel private banken en we hebben veel, om eerlijk te zijn, echt, UL, gevoelige klanten, om eerlijk te zijn, en UL, en in feite, is het, het meest kritieke onderdeel, oké, waar worden de gegevens verwerkt.

In principe, en UL, ja, ook, oké, doorzoekt AI mijn e-mails. Dit soort dingen. Dus achter de schermen, zij, zij vragen dit altijd, maar, weet je, het, het meest kritieke deel voor hen is, oké, ik moet begrijpen, oké, waar de gegevens worden verwerkt, en UL, en ook, oké, UL, ik ben de, de, de, eigenaar van de AI. Dus ik, ik geef de instructie aan de AI, en de AI achter de schermen zal het werk doen, en ze zijn bang voor, bijvoorbeeld, het autonome, UL, aspect, want tegenwoordig, oké, kun je, oké, dat doen, en achter de schermen zal de AI naar iets zoeken, UL, een query, UL, iets achter de schermen, en ze zijn bang van, oké, UL, als ik de, vraag om iets te doen, wat wordt er dan achter de schermen uitgevoerd. En UL, ja, er zijn veel van dit soort vragen, oké, hoe, hoe krijg ik de volledige controle over het proces achter de schermen, of het nu een AI-agent of een AI-service is?

Ja, dat is een soort vraag, maar het is echt een kwestie van adoptie, ook training, om wat training op te zetten over hoe je AI begrijpt en wat er precies achter de schermen gebeurt. En transparantie is ook een belangrijk punt, want transparantie moet in elke AI-oplossing worden doorgevoerd, want transparantie is voor mij een groot onderwerp, omdat je alles moet inrichten, aangezien je AI-oplossing transparant moet zijn.

Je moet begrijpen wat er achter de schermen gebeurt, welke data wordt opgevraagd, je moet alles kunnen traceren en loggen. Alles moet dus transparant zijn wanneer je tegenwoordig een oplossing hebt, want je moet precies begrijpen wat er op de achtergrond wordt uitgevoerd, welke data wordt verwerkt en wat de logica achter de schermen is. Oké, hoe heb je dit plan gegenereerd, op basis van welke feiten en dat soort zaken? Geweldig, oh, ik zie dat we een beetje door onze tijd heen raken, dus ja, sorry. Weet je, dit was echt geweldig, maar ik heb in elke podcast een vragenvuurronde, dus Uw. Uw dus Uw, ik geef een korte zin en jij geeft een kort antwoord. Uw dus, ben je er klaar voor? Ja, Copilot Studio of Custom Code? Co-Pilot Studio, uw Microsoft Foundry of Co-Pilot Studio? Co-Pilot Studio, uw type script of C-Sharp?

GitHub of Azure DevOps? GitHub. Uw RAG of Fine Tuning?

All right. Wat is de meest ondergewaardeerde Microsoft 365 API?

De RAG API. Een technologie die elke Microsoft-ontwikkelaar in 2026 moet leren. GitHub Co-Pilot.

Stel dat Satya Nadelja naar je toe komt en zegt, je krijgt al het geld en de middelen die je wilt om ons AI-platform te verbeteren. Uw, je kunt één functie ontwikkelen. Wat zou dat zijn? Alle governance zaken die we nodig hebben.

NUM. Wie moet ik als volgende uitnodigen voor de podcast en welke vraag moet ik stellen?

Oh, goede vraag. Ik heb veel vrienden, maar Uw ja, misschien kun je het aan mijn co-spreker vragen met wie ik op veel conferenties sta. Je kunt het bijvoorbeeld aan Chloe Moro vragen. Uw, zij was voorheen functioneel consultant voordat ze zich op de technische kant ging richten.

En Uw, ze heeft een heel goed verhaal over functionele, minder technische zaken in de Dynamics wereld.

Dus misschien kun je haar uitnodigen en vragen, vertel me eens, hoe ga je tegenwoordig om met de balans tussen functioneel en technisch werk, want daar liggen toch behoorlijk grote uitdagingen. Ja, en mijn, mijn, mijn afsluitende vraag is, wat zouden mensen, als ze één, één lee uit deze sessie kunnen meenemen, wat zouden ze moeten meenemen?

Uw uit deze sessie? Je bedoelt.

Uw eigenlijk, AI evolueert snel. En als je tegenwoordig bij wilt blijven, Uw, moet je alles volgen, want eerlijk gezegd zit AI tegenwoordig echt door, Uw, de hele Microsoft-stek heen.

En tegenwoordig is een van de dingen die je moet begrijpen dat de evolutie snel gaat en je moet echt, echt, Uw, constant bijblijven, want, Uw, je mist op een gegeven moment iets als je niet, Uw, als je niet leert, als je de evolutie op dit gebied niet begrijpt. Ja, dus, dus ja, Uw, bedankt voor je komst. Ik denk dat de belangrijke lee uit dit gesprek is dat de uitbreidbaarheid van Microsoft 365 Copilot niet simpelweg gaat over het schrijven van steeds geavanceerdere prompts.

Uw, ik denk dat we bewegen naar een architectuur waarin Copilot en agents verbinding kunnen maken met organisatiekennis, Microsoft Graph, bedrijfsapplicaties, APIs en ga zo maar door. Uhm, ja, ik denk dat Copilot Studio, Microsoft Foundry, maatwerkontwikkeling en technologieën zoals MCP-ontwikkelaars een, ja, een geweldige, krachtige gereedschapskist bieden.

Uw, en ja, maar hoe capabeler de agents worden, hoe belangrijker ook de fundamenten worden, identiteit, rechten, beveiliging, governance, testen, observability, applicatie, levenscyclusbeheer enzovoort. Dus ja, ik denk dat je een heel, heel goed overzicht hebt gegeven van al deze onderwerpen. Dus bedankt voor je komst en voor de luisteraars. Alle informatie kun je vinden in de show notes op de M365FM podcastpagina en Uw, ja, waar je verbinding kunt maken en het werk van EES kunt zien en ja, bedankt dat je er was. Bedankt dat ik er mocht zijn. Het was een erg leuke tijd met jou.