In de praktijk lopen veel AI-initiatieven vast op precies dit punt. Niet omdat de AI tekortschiet, maar omdat fundamentele architectuurkeuzes te laat zijn gemaakt. Een werkende demo is nog geen werkende oplossing. Juist bij agents moet je vanaf dag één bewust ontwerpen.
In het boekje AI-agents bouwen op Power Platform beschrijven we zeven architectuurprincipes die je daarbij helpen.
1. Begin met een Solution
Dit klinkt als een open deur, maar ik zie het toch te vaak fout gaan: mensen bouwen agents los van hun flows, connectoren en data. Dat werkt niet. Gebruik altijd een Power Platform Solution om alles bij elkaar te houden. Een Solution bundelt je agent, flows, connectoren, tabellen en configuratie in één pakket.
Waarom is dat belangrijk?
- Overdraagbaarheid: Je bouwt in development, test in acceptatie, rolt uit naar productie. Met een Solution exporteer je alles in één keer. Geen losse onderdelen die je handmatig moet nabouwen.
- Versiebeheer: Je wilt weten welke versie van je agent waar draait. Een Solution maakt dat inzichtelijk. Je publiceert een nieuwe versie, test die en als het misgaat rol je terug naar de vorige.
- CI/CD-pipelines: Als je serieus agents wilt bouwen, automatiseer je deployment. Met Solutions kun je via Azure DevOps of GitHub pipelines automatisch uitrollen naar verschillende environments. Dat scheelt tijd en voorkomt fouten.
Als je al met Power Platform werkt, doe je dit waarschijnlijk al. Maar zo niet: dit is stap één.
2. Eén scenario, één agent
Een agent kan prima een chat-interface hebben. Sterker nog, dat is vaak de meest natuurlijke manier om met een agent te communiceren. Maar het verschil met een chatbot zit hem in wat er achter die chat gebeurt. Een chatbot geeft informatie, een agent voert acties uit. Hij roept flows aan, past data aan, stuurt notificaties, maakt tickets aan. Dat is waarom je per scenario een aparte agent bouwt.
Ik zie vaak de neiging om meerdere functies in te bouwen in een soort ‘super-agent’. HR, IT, finance, facilities - allemaal in één gesprek. Dat lijkt efficiënt, maar is het niet. Zo’n mega-agent wordt onbeheersbaar. De prompts worden te complex, de flows te vertakt en de gebruiker raakt verdwaald in een gesprek dat alle kanten op schiet.
Maak in plaats daarvan per scenario een aparte agent. Een HR-agent voor verlof en verzuim. Een IT-agent voor wachtwoorden en toegang. Een finance-agent voor rapporten en declaraties. Klein, overzichtelijk, met een duidelijk doel. Als scenario’s elkaar overlappen, laat je agents samenwerken via orkestratie. Daar komen we later op terug.
3. Gebruik aparte Environments
Ontwikkeling, test en productie horen gescheiden te zijn. Altijd. Je wilt niet dat een test-agent per ongeluk echte data aanpast of emails verstuurt. In Power Platform regel je dat met Environments: aparte omgevingen met eigen data, eigen security en eigen configuratie.
Mijn advies: gebruik minimaal drie environments. Development voor bouwen en experimenteren. Test voor validatie en user acceptance testing. Productie voor live gebruik.
Beperk per environment de toegang op basis van rol. Developers mogen alles in development, maar niet in productie. Eindgebruikers zien alleen productie.
En stel per environment de juiste Data Loss Prevention (DLP) policies in. Die policies bepalen welke connectoren samen mogen werken. Bijvoorbeeld: je wilt wel dat je agent data uit Dataverse haalt, maar niet dat hij die zomaar naar een externe API stuurt. DLP voorkomt dat.
4. Snap de impact van DLP policies
DLP policies zijn geen formaliteit. Ze bepalen letterlijk wat je agent kan en niet kan. Een agent die data uit Dataverse ophaalt en ook Outlook gebruikt, kan geblokkeerd worden als die connectoren niet in dezelfde policy-groep zitten. En een agent die via een Custom Connector met een externe API praat, vereist expliciete toestemming.
Inventariseer dus vooraf welke connectoren je nodig hebt. Overleg met je Power Platform admin. En test je agent in alle environments, want DLP policies kunnen per environment verschillen.
5. Kies je connectoren bewust
Copilot Studio werkt met standaardconnectoren. Die zitten ingebouwd en vragen geen extra licentie. Vaak doen deze connectoren wat je wilt, maar soms heb je meer nodig, bijvoorbeeld connectors voor legacy-systemen of externe API’s. Er zijn ook premium connectoren die geavanceerde functionaliteit bieden. Kies je ervoor om connectoren te bouwen of te kopen, dan kost dat geld en vraagt beheer
Mijn advies: gebruik alleen wat je echt nodig hebt. Less is more. Elke connector is een afhankelijkheid, een potentieel risicopunt en iets dat onderhouden moet worden. Houd het simpel
6. Documenteer alles
Dit klinkt saai, maar het is cruciaal. Zorg dat je bij elke agent weet welke connectoren en acties worden gebruikt, welke data wordt gelezen of geschreven en welke fallback- of escalatiepaden er zijn. Waarom? Omdat je over drie maanden vergeten bent hoe het werkt. En omdat iemand anders het misschien moet overnemen.
Documentatie hoeft niet fancy te zijn. Een README in je Solution met architectuurschets, dependencies en contactpersonen is al genoeg. Dat kan overigens alleen als je source code integration hebt ingeschakeld, dus dat doen wij standaard. Het gaat erom dat iemand die de agent niet gebouwd heeft, toch begrijpt wat hij doet en hoe.
7. Beheer agents als software
Agents zijn software. Behandel ze ook zo:
- Gebruik Application Lifecycle Management (ALM): commit changes naar source control, gebruik pipelines voor deployment, plan updates en rollbackscenario’s. Dit is geen overkill, dit is professioneel werken.
- Security by design: Authenticatie en autorisatie zijn geen extraatje. Wie mag de agent starten? Wat mag de agent doen namens een gebruiker? Gebruik Azure Key Vault voor secrets, beperk toegang via rollen en log alles wat de agent doet.
Deze zeven principes hebben één gezamenlijke boodschap: je kunt best snel bouwen, maar alleen als je fundament klopt. Anders ben je niet aan het versnellen, maar aan het doorschuiven van complexiteit naar later. En later is bij agents altijd duurder, omdat de gevolgen groter zijn.
Wil je dit hele fundament stap voor stap uitgewerkt zien, inclusief de praktische keuzes en voorbeelden op Power Platform? Lees dan het boe AI-agents bouwen op Power Platform. Het is geschreven voor makers die niet willen praten over mogelijkheden, maar willen bouwen aan agents die morgen in productie kunnen draaien.
Download de praktijkgids en bouw agents die wél live mogen
