Je klikt in Claude of ChatGPT op een standaard connector voor je CRM, je facturatiesysteem of je supportdesk. Binnen een minuut beantwoordt de AI vragen en onderneemt het actie in een tool waar het net toegang toe kreeg. Voor iedereen die het voor het eerst ziet, voelt dat als magie. Geen integratieproject van drie maanden, geen dik contract met een systeemintegrator. Gewoon aanklikken, en het werkt.
Onder de motorkap draait die connector op MCP (Model Context Protocol). MCP is de technische standaard die het mogelijk maakt: het regelt hoe een AI-model met een tool praat, welke acties beschikbaar zijn en hoe data heen en weer stroomt. De connector die je aanklikt, is in feite een kant-en-klare MCP-verbinding naar één specifieke SaaS-oplossing.
Die magie is deels echt. Maar het is de moeite waard om te begrijpen wat die connector precies meebrengt, want daar zit ook meteen de grens van wat hij kan oplossen.
Een standaard connector geeft een AI-model twee dingen: kennis van hoe het slot werkt, en een plattegrond van een deel van het huis waar dat slot op zit. Het model weet hoe het een API-call moet doen, welke velden een tool verwacht, en hoe de resultaten eruitzien. Dat is knap werk en het bespaart enorm veel handmatige integratie.
Wat die connector niet meeneemt, is de businesslogica die buiten die ene SaaS-oplossing leeft. De connector voor je CRM heeft de kennis hoe een "deal" wordt opgeslagen. Hij geeft niet de kennis door dat sales een deal pas "closed won" noemt zodra finance de betaling heeft bevestigd, terwijl operations dat label al eerder plakt zodra het contract getekend is. Die kennis zit niet in de tool. Die zit, als het goed is, in de hoofden van je mensen en in losse afspraken tussen afdelingen.
Als die businesslogica nergens gedocumenteerd of gestructureerd staat, doet het AI-model wat het model altijd doet als informatie ontbreekt: het maakt de beste inschatting op basis van patronen. Dat gaat tegenwoordig verrassend goed. Grote taalmodellen zijn opmerkelijk sterk geworden in het raden van context.
Maar "heel goed raden" is in een bedrijfscontext niet hetzelfde als correct. Een agent die zelfstandig een rapportage samenstelt of een klant een antwoord stuurt op basis van de verkeerde definitie van "actieve klant" of "openstaand bedrag", raadt met veel vertrouwen het verkeerde antwoord. Niemand controleert het, want het klinkt overtuigend.
En dat probleem stapelt zich op zodra je meerdere standaard connectors tegelijk gebruikt. Elke connector brengt zijn eigen losse plattegrond mee, maar niemand vertelt het model hoe die plattegronden met elkaar samenhangen. Hoe een klant in je CRM zich verhoudt tot een klant in je facturatiesysteem, welk veld leidend is als beide systemen elkaar tegenspreken, welke definitie van "omzet" telt. Elke extra connector is een extra plek waar het model opnieuw moet gokken, met een groeiende kans dat die gokken elkaar tegenspreken.
De structurelere oplossing ligt niet in nog een connector, maar in het samenbrengen van je data op één plek en het bouwen van een echte semantische laag daarbovenop.
Het verschil zit in scope. Een standaard connector beschrijft één systeem. Een semantische laag beschrijft je hele datalandschap: hoe brontabellen uit verschillende systemen met elkaar samenhangen, welke join de juiste is als je klantdata uit drie systemen combineert, en vooral, wat je bedrijf verstaat onder een term als "omzet", "actieve klant" of "openstaand bedrag". Niet als losse afspraak per team, maar als één vastgelegde definitie waar iedereen, mens of agent, op terugvalt.
In een eerdere blog beschreven we hoe semantic sprawl er in de praktijk uitziet: finance rapporteert 4,2 miljoen euro omzet, sales meldt 4,5 miljoen, operations zegt 4,1 miljoen. Drie cijfers, drie definities, een hoofdpijn voor de directie. Dat is precies het type inconsistentie dat een AI-agent niet zelf oplost door harder te raden. Het moet worden opgelost in de laag onder de agent, niet erin.
Met een semantische laag op je datawarehouse geef je een agent iets fundamenteel anders dan een plattegrond van één tool. Je geeft het de regels van je hele bedrijf: hoe data samenkomt, en hoe die data geïnterpreteerd moet worden.
Dit is geen pleidooi om connectors te laten liggen. Een standaard connector, gebouwd op MCP, is uitstekend in het op pad sturen van een agent: een actie uitvoeren, een record aanmaken, een status updaten in een specifiek systeem. Voor taken is het precies het juiste gereedschap.
Het punt is dat een connector en een semantische laag verschillende problemen oplossen. De connector regelt de uitvoering. De semantische laag regelt de waarheid waarop die uitvoering gebaseerd is. Je hebt allebei nodig, maar als je moet kiezen waar je eerst in investeert, is het antwoord de laag die bepaalt of je agent het juiste cijfer gebruikt, niet de laag die bepaalt hoe snel hij een taak uitvoert.
Voordat je meer standaard connectors toevoegt aan je AI-workflows, is het de moeite waard om te checken of je definities al vastliggen. Breng in kaart welke kernbegrippen in je organisatie meerdere definities hebben. Investeer in een centrale, semantische laag boven je datawarehouse voordat je agents op meerdere systemen tegelijk loslaat. En behandel die laag als een gedeelde verantwoordelijkheid tussen je datateam en de teams die de agents gaan gebruiken, niet als een eenmalig technisch project.
Wil je weten hoe volwassen jouw semantische laag is, en waar de grootste risico's zitten voordat je agents op je data loslaat? We denken graag met je mee.