Dat heeft zelden te maken met tooling. De echte uitdaging zit in aanpak. Te groot beginnen. Te abstract blijven. Of proberen alles in één keer goed te doen. In de praktijk werkt dat niet. Wat wél werkt, is een duidelijke structuur die helpt om van een idee naar een agent te gaan die daadwerkelijk draait, getest is en gebruikt wordt.
In het boek AI-agents bouwen op Power Platform beschrijven we daarom een praktisch stappenplan. Geen theoretisch framework en geen lineair projectplan, maar een set stappen die helpt om snel te bouwen, vroeg te testen en onderweg te leren.
Hieronder lees je dat stappenplan.
Stappenplan: Van idee naar agent
Je hebt een probleem geïdentificeerd. Je weet waarom je een agent wilt bouwen. Je hebt je architectuur op orde. Nu wordt het concreet: hoe bouw je dat agent daadwerkelijk? Niet als theoretisch concept, maar als werkende oplossing die morgen al draait.
De waarheid is: er is geen universeel recept. Elke usecase is anders, elke organisatie heeft eigen systemen en elke gebruikersgroep heeft eigen verwachtingen. Maar er is wel een structuur die werkt. Zeven stappen die je van idee naar productie brengen. En het mooie? Bij stap drie heb je al iets dat je kunt laten zien.
Stap 1: Kies een specifieke use case
Hoe specifieker het probleem dat je oplost met je agent, hoe beter. Begin dus niet met “een HR-assistent” of iets dergelijks, begin met “een agent die verlofaanvragen afhandelt”. Specifiek, meetbaar, met duidelijke in- en output. Een medewerker wil verlof aanvragen. De agent checkt het tegoed, vraagt de juiste gegevens op, stuurt een goedkeuringsverzoek naar de manager en bevestigt zodra het geregeld is.
Waarom zo specifiek? Omdat je wilt leren. Je wilt zien of je agent werkt, of gebruikers het snappen en of het waarde toevoegt. Dat lukt het beste met een simpel scenario dat je in een week live kunt zetten. En ja, straks bouw je meer agents. Voor ziekmeldingen, voor onboarding, voor salarisadministratie. Maar niet allemaal tegelijk. Eén scenario, bewijzen dat het werkt, dan pas verder.
Stap 2: Ontwerp de conversatieflow
Hier komt het verschil tussen developer en designer naar voren. Als developer denk ik in data en logica: welke velden heb ik nodig, welke validaties moet ik doen, welke API’s moet ik aanroepen? Maar een agent begint niet met code, het begint met taal.
Hoe start het gesprek? “Ik wil verlof aanvragen” is een goede conversation starter. Maar wat komt daarna? Vraag je meteen om data? Of geef je eerst context? “Prima, ik help je daarmee. Hoeveel dagen wil je opnemen en wanneer?” Klinkt natuurlijker dan een formulier met verplichte velden.
En dan de edge cases. Wat als iemand zegt: “Ik wil vrij”? Of “Volgende week maandag tot woensdag”? Of gewoon “Vakantie”? Je prompt moet robuust genoeg zijn om variaties te herkennen, maar ook slim genoeg om door te vragen als iets onduidelijk is.
Dit is waar je als developer moet leren denken als een schrijver. Niet: “Welke parameter moet ik meegeven?”, maar: “Hoe zou ik dit tegen een collega zeggen?” Het helpt om dit op papier te zetten voordat je CopilotStudio opent. Teken de flow uit, bedenk varianten, test het in je hoofd. Het scheelt je later uren debuggen.
Meestal zet je hiervoor een combinatie in van generatieve AI en ‘ouderwetse’ chatbot-techniek die op basis van de invoer de bedoeling van de gebruiker herkent en dan een standaardflow (‘topic’ in Power Platform) in gang zet.
Herkent je agent de topic niet, dan kan hij geen actie ondernemen maar wel informatie verstrekken op basis van de beschikbare kennis.
In de afbeelding zie je hoe Copilot Studio een vraag van een gebruiker afhandelt. Als er een vraag binnenkomt, kijkt de agent of hij er topic voor heeft. Zo ja (‘Intent recognized’), dan handelt hij de vraag af met een standaardgesprek of met het uitvoeren van een actie in achterliggende systemen of het aanroepen van een andere agent.
Begrijpt de agent niet wat de gebruiker wil, dan probeert hij het met generatieve AI op te lossen. Tijdens die conversatie kan de agent altijd weer teruggaan naar topics die wel bekend zijn. Bijvoorbeeld als de gebruiker het gesprek beëindigt: dan weten veel agents dat ze feedback moeten vragen met de bekende ‘5 smileys’.
Stap 3: Voeg kennis en data toe
Een agent zonder data is een dom script. Kennis en context maken het slim. Bij verlofaanvragen heb je minimaal drie dingen nodig:
- hoeveel tegoed heeft deze medewerker?
- wie is de manager?
- en welke afdelingsregels gelden?
Die data zit ergens. Misschien in Dataverse, misschien in een HR-systeem, misschien in SharePoint. Het maakt niet uit waar, als je het maar kunt ophalen. In Power Platform gebruik je connectoren om data te ontsluiten.
Hier komt ook Retrieval Augmented Generation (RAG) in beeld. Stel: je wilt dat het agent verlofregels uitlegt. Die regels staan in een beleidsdocument op SharePoint. Je kunt dat document handmatig in je prompt stoppen, maar dat schaalt niet. RAG haalt automatisch relevante stukken uit documenten op basis van de vraag. “Hoeveel ouderschapsverlof mag ik opnemen?” triggert een zoekopdracht, vindt het juiste hoofdstuk en de agent geeft antwoord op basis van die context.
Stap 4: Koppel acties
Een agent die alleen informatie geeft, is een chatbot. Een agent die acties uitvoert, is veel waardevoller. Bij verlofaanvragen betekent dat: data wegschrijven in Dataverse, een goedkeuringsflow triggeren in Power Automate en notificaties sturen naar Teams.
Hier komen drie soorten acties om de hoek kijken:
- Agent flows: De standaard voor procesorkestratie. Je agent triggert een flow, die flow doet het zware werk: goedkeuringen, notificaties, data updates. Clean, beheersbaar, herbruikbaar.
- Custom connectors: Voor systemen zonder standaardconnector. Legacy HR-systemen, ticketing tools, ERP-pakketten. Je bouwt een connector, definieert de API-calls en je agent kan ermee praten alsof het native integratie is.
- RPA via Power Automate Desktop: Voor systemen zonder API. Ja, dat bestaat nog steeds. Een oud personeelssysteem waar je moet inloggen, door schermen moet klikken en formulieren moet invullen. RPA automatiseert die handelingen. Niet ideaal, maar soms de enige optie.
Kies altijd de simpelste aanpak die werkt. API’s boven RPA, standaardconnectoren boven custom. Less is more.
Stap 5: Ontwerp de interactie
Tekst is prima, maar niet altijd het meest efficiënt. Een Adaptive Card met dropdowns en knoppen is sneller en duidelijker. “Welk type verlof?” met keuzes: Vakantie, Ziekte, Ouderschapsverlof, Onbetaald. Eén klik in plaats van typen en hopen dat het agent het snapt.
Adaptive Cards zijn ook visueel sterker. Je kunt samenvatten wat de gebruiker heeft ingevuld, laten bevestigen en pas dan de actie uitvoeren. “Je vraagt 5 dagen vakantie aan van 10 tot 14 juni. Manager: Jan Jansen. Bevestigen?” Met knoppen Ja en Nee. Geen verwarring, geen interpretatiefouten.
We gaan hier later dieper op in, maar onthoud: goede agents combineren conversatie met interface-elementen. Het een sluit het ander niet uit.
Stap 6: Test grondig
De happy path van agent is makkelijk te testen. Een agent werkt prima als alles klopt: juiste input, volledige data, geen fouten. Maar de wereld is niet perfect. Gebruikers typen onduidelijk, informatie ontbreekt of systemen zijn traag. Daar moet je op ook testen.
We behandelen dit uitgebreid in een later hoofdstuk, maar hier alvast de basis: test op onverwachte input, test op incomplete data, test op systeemfouten. En bouw fallbacks in. Als een agent iets niet snapt, moet hij dat zeggen en een alternatief bieden. “Ik begrijp je vraag niet helemaal. Wil je verlof aanvragen, je tegoed checken of heb je een andere vraag?”
Stap 7: Deployment en monitoring
Live gaan is geen eindpunt, maar het begin. Je wilt weten waar gesprekken vastlopen, welke vragen niet worden herkend en waar gebruikers afhaken. Met die inzichten verbeter je je agent continu.
Itereren gaat snel op Power Platform. Je past aan, test en rolt een nieuwe versie uit. Dat maakt het verschil tussen een agent die werkt en een agent die écht gebruikt wordt.
Bouw geen perfecte agent, bouw een werkende
Deze zeven stappen zijn geen waterval en geen checklist die je één keer afvinkt. Ze vormen een manier van werken. Je bouwt iets, test het, leert ervan en verbetert. Vaak heb je al bij stap drie iets dat je kunt laten zien. Bij stap vijf iets dat gebruikers kunnen testen. En bij stap zeven iets dat daadwerkelijk waarde levert.
Een AI-agent wordt niet beter door eindeloos ontwerpen, maar door gebruik. Door klein te beginnen en bewust te itereren, voorkom je dat je blijft hangen in pilots of prototypes die nooit productie halen.
Wil je dit stappenplan zien in de context van architectuur, governance en concrete Power Platform-keuzes? In de whitepaper AI-agents bouwen op Power Platform werken we elk onderdeel verder uit, inclusief de valkuilen die we in de praktijk het vaakst tegenkomen.
👉 Lees het e-book en bouw AI-agents die niet bij een idee blijven, maar echt gaan werken.
