Hoe we orde scheppen in de jungle van AI-tools
Hoe we bij Sevendays orde scheppen in de chaos van het AI-landschap
Bij Sevendays werken we dagelijks met AI-technologie voor onze klanten. Of het nu gaat om het bouwen van chatbots, het automatiseren van workflows, of het opzetten van RAG-systemen — we zien continu nieuwe tools en frameworks voorbijkomen. De lijst lijkt eindeloos, en iedere week komen er nieuwe bij.
Het probleem? Ieder nieuw project riep dezelfde vragen op: welke tool past waar? Kunnen we dit hergebruiken? Is dit nu een alternatief voor wat we al hebben, of vult het een andere rol in? En als een klant vraagt om "een AI-agent" — waar hebben we het dan eigenlijk over?
Daarom ontwikkelden we het AI Agent Component Map: een visueel framework dat de wildgroei aan AI-gerelateerde tools structureert. Niet door alles op een hoop te gooien, maar door helder te maken welke rol een tool speelt en in welke fase van een agent deze wordt ingezet.
De kern: scheiding van verantwoordelijkheden
Ons schema verdeelt een AI-agent architectuur in vier hoofdgebieden:
Interface Layer
De toegangspoort, hoe komen verzoeken binnen en hoe gaan antwoorden naar buiten? Dit kan een chat-interface zijn, maar net zo goed een API, een Slack-bot, webhooks, of een voice assistant. De keuze hier bepaalt wie of wat met je agent kan praten.
Infrastructure
Het fundament, welke resources en capabilities heeft je agent tot zijn beschikking? Hier zitten je modellen (niet alleen LLM's, maar ook embedding models, rerankers en classifiers), je kennisbronnen (vector databases, document storage, SQL databases), je tool-integraties, en de platform services die alles draaiende houden.
Control Plane
De beslisser, hier wordt bepaald wat er moet gebeuren. Welke stappen zijn nodig om deze vraag te beantwoorden? Welk model gebruiken we? Welke tool roepen we aan? Mag deze gebruiker deze actie uitvoeren? Is de output goed genoeg? Dit zijn vaak ook LLM-calls, maar dan gericht op planning, routing en evaluatie — niet op het produceren van het eindresultaat.
Execution Plane
De uitvoerder, hier wordt het werk gedaan dat het Control Plane heeft bepaald. De query naar de vector database, de API-call naar een extern systeem, de LLM-call die daadwerkelijk het antwoord genereert of de samenvatting schrijft.
Waarom deze scheiding ertoe doet
De kracht van dit framework zit in het onderscheid tussen beslissen en uitvoeren. Beide kunnen LLM's gebruiken, maar met een andere verantwoordelijkheid.
Een planner-LLM die bepaalt welke stappen nodig zijn om een vraag te beantwoorden? Dat is Control Plane. De LLM die vervolgens daadwerkelijk het antwoord formuleert? Dat is Execution Plane. Een LLM-as-Judge die achteraf de kwaliteit van een response beoordeelt? Weer Control Plane.
Neem een ander voorbeeld: je agent moet data ophalen uit je CRM. In het Control Plane zit de logica die bepaalt of de gebruiker toegang heeft tot die data, welke tool wordt aangeroepen, en wat er moet gebeuren als de call faalt. In het Execution Plane gebeurt de daadwerkelijke API-call, de credential injection, en de error handling.
Neem een tool als Windmill: als workflow orchestration zit het in je Infrastructure. Maar de flow control die bepaalt wanneer een stap opnieuw moet worden geprobeerd of wanneer er moet worden geëscaleerd? Dat is Control Plane logica. En de daadwerkelijke uitvoering van je scripts en API-calls? Dat is Execution Plane. Eén tool, drie lagen.
Door beslissen en uitvoeren te scheiden kun je policies aanpassen zonder je executie-logica te wijzigen en andersom.
De lagen in detail
Infrastructure: meer dan alleen een LLM
Als mensen aan AI denken, denken ze vaak alleen aan het taalmodel. Maar de Infrastructure-laag laat zien hoeveel meer er bij komt kijken.
Models zijn niet alleen LLM's. Je hebt embedding models nodig om tekst naar vectors te converteren voor semantisch zoeken. Rerankers om zoekresultaten te herschikken voor betere relevantie. Classifiers om input te categoriseren op intent of sentiment voordat je het naar je LLM stuurt.
Knowledge Sources bepalen waar je agent zijn kennis vandaan haalt. Vector databases voor semantisch zoeken, traditionele SQL databases voor gestructureerde data, graph databases voor relaties tussen entiteiten, en externe API's voor real-time informatie. De keuze hier heeft directe impact op wat je agent wel en niet kan weten.
Tool Ecosystem definieert wat je agent kan doen. Via MCP (Model Context Protocol) of andere integraties krijgt je agent de mogelijkheid om te interacteren met externe systemen, van je CRM tot je calendar tot je database.
Platform Services zijn de stille krachten die alles draaiende houden: caching voor snelle responses, message queues voor asynchrone verwerking, state stores voor conversatiegeheugen, en workflow orchestration voor complexe multi-step processen.
Control Plane: nadenken over wat te doen
Het Control Plane bepaalt de strategie, nog voor er iets wordt uitgevoerd.
Orchestration & Planning bepaalt hoe complexe taken worden opgebroken. Hoe breek je een vraag op in substappen? Wanneer ga je door, wanneer stop je, wanneer plan je opnieuw? Hoe voorkom je dat je agent in een oneindige loop belandt?
Routing & Selection maakt dynamische keuzes. Niet elke vraag hoeft naar je duurste model. Niet elke kennisbehoefte hoeft via je vector database. Slimme routing kan kosten besparen én performance verbeteren.
Safety & Security is waar je je guardrails definieert. Input validatie om prompt injection te voorkomen. Output filtering om PII te detecteren of hallucinations te flaggen. Toegangscontrole om te bepalen wie welke tools mag gebruiken.
Governance & Policy gaat over compliance en auditability. Waar mag data worden opgeslagen? Wat moet worden gelogd? Wanneer is menselijke goedkeuring vereist?
Execution Plane: het werk doen
Het Execution Plane voert uit wat het Control Plane heeft besloten.
Knowledge Execution voert de daadwerkelijke queries uit naar je kennisbronnen. Vector searches, live API calls, embedding generation, context assembly.
Model Inference is waar je LLM het eigenlijke werk doet — het antwoord genereren, de samenvatting schrijven, de code produceren.
Tool Execution handelt de interactie met externe systemen af. De tool gateway routeert requests, credentials worden geïnjecteerd, responses worden verwerkt, errors worden afgehandeld.
Validation Execution past de policies uit het Control Plane toe. Schema validatie, business rules, PII redaction.
Memory Operations beheert de conversatiecontext. Lezen en schrijven naar geheugen, state persistence, history retrieval, context window management.
Hoe je het schema gebruikt
Het AI Agent Component Map is geen checklist die je volledig moet afvinken. Het is een denkkader dat je helpt om:
Gerichte keuzes te maken
Een eenvoudige Q&A chatbot op basis van je FAQ heeft een heel andere architectuur nodig dan een autonome agent die namens je klant afspraken plant en facturen verstuurt. Het schema laat zien welke componenten je wél nodig hebt, zodat je niet blind alles implementeert of belangrijke aspecten over het hoofd ziet.
Tools te plaatsen
Wanneer je een nieuwe tool tegenkomt, kun je direct zien waar deze past. Is het Infrastructure (een nieuwe vector database)? Control Plane (een policy engine)? Execution Plane (een tool gateway)? Of speelt het een rol in meerdere lagen?
Gaps te identificeren
Door het schema langs je huidige architectuur te leggen, zie je waar je mogelijk tekortschiet. Heb je wel nagedacht over output guardrails? Wat gebeurt er als een tool call faalt? Hoe beheer je conversatiegeheugen?
Te communiceren
Het schema maakt het makkelijker om met stakeholders te bespreken wat je bouwt. In plaats van abstracte concepten kun je visueel laten zien welke lagen je implementeert en waarom.
Conclusie
De AI-tooling markt groeit explosief. Elke week verschijnen er nieuwe frameworks, nieuwe modellen, nieuwe platforms. Zonder een helder framework verdwaal je in de mogelijkheden.
Het AI Agent Component Map geeft ons bij Sevendays die structuur: een visuele kaart die duidelijk maakt welke rol een tool speelt en in welke fase deze wordt ingezet. Niet als rigide blauwdruk, maar als kompas om gefundeerde keuzes te maken.
Want uiteindelijk gaat het niet om hoeveel tools je gebruikt, maar of je de juiste tools op de juiste plek hebt.
