Een taalmodel alleen maakt nog geen AI-collega. Het verschil zit in alles eromheen: waar de AI werkt, namens wie hij handelt, wat hij weet en onthoudt, en wanneer hij uit zichzelf aan de slag gaat. Dat geheel heet een harness.
De meeste organisaties beginnen met losse licenties: iedere medewerker een eigen chatassistent. Dat levert winst op voor het individu, maar de organisatie leert er weinig van. Kennis blijft hangen in losse gesprekken, iedereen legt opnieuw uit hoe het bedrijf werkt, en de AI kan niets doen in de systemen waar het werk echt gebeurt.
Deze blog behandelt beide kanten: waarom je een harness en kennisbank nodig hebt, en hoe je ze bouwt. Het begin is voor iedereen die over AI in de organisatie beslist. Vanaf de kennisbank wordt het technischer, voor wie de agent bouwt of beheert. Waar we code of configuratie laten zien, is dat illustratief: de vorm verschilt per platform, de principes niet.
Wat is een AI-harness?
Een AI-agent bestaat uit twee delen: het model en de harness. Het model is het taalmodel dat redeneert en tekst schrijft. De harness is alles eromheen: instructies, koppelingen met systemen, geheugen, rechten en de afspraken over wat de agent zelfstandig mag doen.
Het Engelse woord betekent tuig, het geheel waarmee je een paard voor een kar spant. Het model levert de kracht, de harness bepaalt de richting.
Een harness voor een organisatie gaat verder dan een persoonlijke assistent. Meerdere mensen werken met dezelfde agent, met dezelfde kennis en onder dezelfde afspraken. Wie zo'n agent bouwt, komt steeds dezelfde vragen tegen: wat weet hij, wat ziet het model op elk moment, namens wie handelt hij, waar draait zijn code, waar werkt hij en wanneer gaat hij zelf aan de slag. De rest van deze blog loopt die vragen een voor een langs.
Kanalen en triggers starten de agent. De harness bepaalt namens wie hij handelt en wat het model te zien krijgt. Kennisbank, bronsystemen en sandbox staan los van het model, zodat je dat kunt vervangen zonder de rest aan te passen.
En er is een reden om juist in de harness te investeren. Modellen worden snel beter en je wisselt ze vaker dan je verwacht. De harness en de kennisbank blijven. Daar zit de waarde die je organisatie opbouwt.
De kennisbank in drie lagen
Een AI-kennisbank is meer dan een map met documenten waarin de agent zoekt. Het zijn drie soorten kennis, elk met een eigen opslag en een eigen moment waarop de agent ze leest: werkinstructies, naslagkennis en geheugen.
Laag 1: werkinstructies als vaardigheden
Hoe jullie een offerte opstellen, een aanvraag beoordelen of een maandrapportage maken, leg je vast als vaardigheid. Elke vaardigheid is een map met een instructiebestand, aangevuld met sjablonen, voorbeelden of scripts.
vaardigheden/
├── aanvraag-kwalificeren/
│ ├── SKILL.md
│ └── criteria.md
├── offerte-opstellen/
│ ├── SKILL.md
│ ├── sjabloon-offerte.docx
│ └── voorbeelden/
└── maandrapportage/
├── SKILL.md
└── scripts/grafieken.py
Bovenaan elk instructiebestand staan een naam en een korte omschrijving. Alleen die twee velden laadt de harness bij elke aanroep in. De rest van het bestand leest de agent pas als hij besluit dat de vaardigheid van toepassing is.
---
name: aanvraag-kwalificeren
description: Beoordeelt een binnenkomende aanvraag of tender en geeft een go, twijfel of no-go met onderbouwing. Gebruik bij elke nieuwe aanvraag, ook als alleen een link of bedrijfsnaam wordt gedeeld.
---
De omschrijving is daarmee het belangrijkste stuk tekst van de vaardigheid. Is hij te vaag, dan laadt de agent hem niet. Is hij te breed, dan laadt hij hem bij taken waar hij niet bij hoort. Schrijf erin wanneer de vaardigheid geldt, met de woorden die gebruikers zelf gebruiken.
Laag 2: naslagkennis
Handboeken, beleid, eerdere offertes en klantdossiers kun je op twee manieren ontsluiten.
Live zoeken in de bron. De agent zoekt via een koppeling rechtstreeks in SharePoint, het projectbeheersysteem of het CRM. Het Model Context Protocol (MCP) is hiervoor inmiddels de gangbare standaard. Het voordeel: de bron blijft leidend, er ontstaat geen kopie die veroudert, en de rechten van het bronsysteem blijven gelden.
Een eigen zoekindex. Voor grote, stabiele collecties bouw je een index: documenten opknippen in stukken van een paar honderd woorden, voorzien van embeddings voor betekenis en van gewone trefwoorden. Zoek met beide tegelijk (hybride zoeken) en laat een tweede model de beste resultaten herordenen. Trefwoorden vangen productcodes en namen, embeddings vangen synoniemen.
Begin met live zoeken. Bouw pas een index als de bron te traag is, te veel ruis geeft of niet goed doorzoekbaar is. In beide gevallen geldt: ruim eerst op. Haal dubbele en verouderde versies weg en geef elk document een eigenaar, een datum en een geldigheid.
Laag 3: geheugen
Geheugen is wat de agent leert tijdens het werk, en het kent twee niveaus. Het organisatiegeheugen geldt voor iedereen: termen, vaste afspraken, klantcontext. Het persoonlijke geheugen geldt voor één gebruiker: jij wilt samenvattingen in opsommingen, je collega in lopende tekst. Sla beide op als gewone markdownbestanden in opslag die je zelf beheert.
geheugen/
├── organisatie.md # termen, vaste afspraken, klantcontext
└── gebruikers/
├── anna.md # voorkeuren van één gebruiker
└── bram.md
De harness leest beide bestanden aan het begin van elke sessie in en zet ze in de systeeminstructie. Twee regels houden het geheugen gezond. Zet de map onder versiebeheer, zodat elke wijziging zichtbaar en terug te draaien is. En laat de agent wijzigingen aan het organisatiegeheugen indienen als voorstel, dat een beheerder goedkeurt, want wat daar belandt, beïnvloedt iedereen. Persoonlijk geheugen mag de agent zelf bijwerken.
Houd de kennis in eigen beheer
Omdat vaardigheden en geheugen gewone bestanden in je eigen opslag zijn, kun je overstappen op een beter of goedkoper model zonder dat de agent vergeet wat hij heeft geleerd. Het nieuwe model leest dezelfde bestanden en werkt op dezelfde manier verder. Modellen komen en gaan; de kennisbank is het bezit van je organisatie.
Contextbeheer: wat het model op elk moment ziet
Het contextvenster is het werkgeheugen van het model. Hoe voller het raakt, hoe slechter het model redeneert, ook ruim voor de technische limiet. Wie alle handboeken en klantdossiers tegelijk aanbiedt, krijgt een agent die vergeet wat aan het begin stond. Vergelijk het met een student die de avond voor het tentamen alles in één keer probeert te leren: hoe meer hij erin stopt, hoe meer de eerste hoofdstukken wegzakken.
De harness moet daarom actief bepalen wat erin staat. Vier technieken doen het meeste werk.
Grote resultaten uitbesteden aan bestanden. Geeft een tool een groot resultaat terug, zoals een export of een lang transcript, dan schrijft de harness het naar een bestand. Het model krijgt alleen het begin, het eind en het pad te zien, en leest verder met een leestool als het een detail nodig heeft. Een werkbare drempel ligt rond de 20.000 tokens.
Samenvatten, maar herstelbaar. Nadert het gesprek de grens van het venster, zeg rond 85 procent, dan vat een aparte modelaanroep het oudere deel samen. De laatste berichten blijven letterlijk staan. Schrijf het volledige oude gesprek weg naar een bestand, zodat de agent een detail later kan terughalen.
Hulpagenten voor rommelig werk. Onderzoek met tientallen zoekopdrachten geef je aan een hulpagent met een eigen contextvenster, een eigen instructie en een beperkte set tools. Alleen de conclusie komt terug bij de hoofdagent. Hulpagenten kunnen vaak parallel draaien en op een goedkoper model.
Vaardigheden pas laden als ze nodig zijn. Zoals bij de kennisbank beschreven: alleen naam en omschrijving staan standaard in de context. Tien vaardigheden kosten zo nauwelijks meer ruimte dan tien regels tekst.
Deze technieken hoef je meestal niet zelf te schrijven. Open-source harnesses zoals Deep Agents bieden ze als bouwstenen die je met een paar regels aanzet. Schematisch ziet dat er zo uit:
from deepagents import create_deep_agent
agent = create_deep_agent(
model=model, # wisselbaar, van elke leverancier
subagents=[marktonderzoeker], # eigen contextvenster per hulpagent
memory=["/memories/AGENTS.md"], # geheugen als gewoon bestand
backend=backend, # opslag in eigen beheer
store=store,
)
Controleer wel de standaardinstellingen. Een drempel die past bij een onderzoekstaak, past zelden bij een agent die korte vragen van de servicedesk beantwoordt.
Identiteit en rechten per koppeling
Namens wie handelt de agent? Dat is de lastigste vraag bij een harness voor een organisatie. Er zijn twee mogelijkheden, en vaak combineer je ze binnen één agent.
Namens de gebruiker betekent dat de gebruiker eenmalig inlogt via OAuth en de harness per gebruiker een token bewaart. In Microsoft-omgevingen heet dit de on-behalf-of-flow. Een eigen identiteit is een serviceaccount of app-registratie met vaste, beperkte rechten.
Maak de keuze per koppeling en per handeling, en leg hem vast in een rechtenmatrix: per koppeling de identiteit, waar hij beschikbaar is en wat de agent mag schrijven. Een voorbeeld voor een agent die sales en marketing ondersteunt:
- E-mail en agenda: namens de gebruiker, alleen in een privégesprek. De agent maakt concepten; versturen gebeurt pas na akkoord.
- Documenten (SharePoint): namens de gebruiker, overal beschikbaar, alleen lezen.
- Projectbeheer: namens de gebruiker, overal beschikbaar. De agent mag taken aanmaken en bijwerken.
- CRM: serviceaccount met alleen leesrechten, overal beschikbaar.
- Bedrijfspagina LinkedIn: vaste identiteit, alleen in een privégesprek. Publiceren mogen alleen leden van het marketingteam.
Drie keuzes in deze matrix verdienen uitleg.
Mail is alleen beschikbaar in een privégesprek. In een gedeeld kanaal kan een collega anders de agent vragen jouw mailbox te doorzoeken, met jouw rechten.
Het CRM gebruikt een serviceaccount. Dat scheelt iedereen een extra login, maar het betekent ook dat iedereen via de agent ziet wat dat account ziet. Kies dit alleen voor gegevens die voor alle gebruikers van de agent toegankelijk mogen zijn.
Publiceren namens het bedrijf is beperkt tot een vaste lijst gebruikers. De anderen kunnen wel lezen en een concept maken.
Rechten in de zoekindex
Dezelfde valkuil zit in een eigen zoekindex. Indexeer je documenten met een serviceaccount, dan kan elke gebruiker via de agent elk geïndexeerd document lezen, ook als hij in SharePoint geen toegang heeft. Sla daarom bij elk stuk tekst de toegangsrechten op als metadata en filter bij elke zoekvraag op de rechten van de vrager. Of zoek live namens de gebruiker: dan bewaakt het bronsysteem de rechten.
Log tot slot elke actie met de identiteit waarmee hij is uitgevoerd en de gebruiker die erom vroeg. Dan kun je achteraf altijd reconstrueren wie wat heeft gedaan, wat je nodig hebt voor je informatiebeveiliging en verantwoording.
Code-uitvoering: een sandbox per sessie
Een agent die code kan schrijven en draaien, kan veel meer: spreadsheets doorrekenen, documenten opmaken, gegevens omzetten. Die code draait nooit op de machine waarop de harness zelf draait. De harness staat erbuiten en stuurt opdrachten naar een afgeschermde container.
Vier afspraken maken die container veilig.
Eén sandbox per sessie. Elke gesprekssessie krijgt een eigen container, die na afloop wordt opgeruimd. Bestanden die moeten blijven, schrijft de agent expliciet naar opslag buiten de sandbox.
Een basisimage per type werk. Een rapportage-agent heeft andere bibliotheken nodig dan een agent die code reviewt. Leg per team of kanaal vast welk image start.
Uitgaand verkeer alleen naar toegestane adressen. De sandbox mag alleen de pakketbronnen en interne API's bereiken die het werk vereist. Al het andere verkeer wordt geblokkeerd.
Sleutels via een proxy. In de sandbox staan geen echte wachtwoorden of API-sleutels. Code gebruikt een plaatshouder, en een proxy aan de rand van de sandbox vervangt die door de echte sleutel op het moment dat het verzoek naar buiten gaat. Zo kan de agent met je systemen werken, maar kan hij een sleutel nooit uitlezen, wegschrijven of per ongeluk in een antwoord zetten.
Werkplek en triggers: waar en wanneer de agent werkt
Een agent start op twee manieren: iemand roept hem aan, of er gebeurt iets waar hij op wacht.
Werken waar mensen al werken
De agent werkt in Teams, Slack of de mailbox. Een nieuw venster dat mensen apart moeten openen, is na drie weken vergeten. Technisch is de agent een bot-app die je kunt taggen in een kanaal of een privébericht kunt sturen. Koppel elke draad aan één sessie: het draad-ID is de sleutel voor de gespreksgeschiedenis, de sandbox en de samenvattingen.
Werken in gedeelde kanalen heeft een bijkomend voordeel: collega's zien hoe anderen de agent gebruiken en leren daarvan. Wordt de agent in een lopend gesprek getagd, laat hem dan een eigen draad starten, zodat het gesprek tussen mensen leesbaar blijft.
Voor werk in bulk is een chatkanaal ongeschikt. Moet iemand veertig conceptmails beoordelen, bouw dan een eenvoudig reviewscherm dat dezelfde wachtrij leest als de agent.
Geplande en gebeurtenisgestuurde taken
Een groot deel van het nuttige werk start niet omdat iemand erom vraagt. Een vast schema (cron) start de maandagrapportage; een webhook start de beoordeling van een nieuwe aanvraag. Sommige taken richt de bouwer in. Andere maakt de agent zelf aan op verzoek van een gebruiker, bijvoorbeeld met 'stuur me elke ochtend een overzicht van mijn dag'.
Taken zonder toeschouwer hebben een vaste regel nodig: omkeerbaar werk mag de agent zelf afronden, onomkeerbaar werk bereidt hij voor en zet hij klaar voor akkoord. Leg dat per taak vast, bijvoorbeeld zo:
# illustratief, geen standaardformaat
taak: maandagoverzicht-aanvragen
trigger: "0 7 * * 1" # elke maandag om 07:00
eigenaar: sales
mag_zelf: [lezen, samenvatten, concept_opslaan]
vraagt_akkoord: [mail_versturen, status_wijzigen, verwijderen]
uitvoer: privébericht aan de eigenaar
Maak taken ook bestand tegen dubbel draaien. Een webhook die twee keer binnenkomt, mag niet tot twee mails of twee taken leiden. Geef elke uitvoering een uniek kenmerk en controleer of het werk al gedaan is voordat de agent begint.
Testen, tracing en beheer
Een agent verandert voortdurend: vaardigheden worden aangepast, het geheugen groeit, het model wordt vervangen. Zonder meetlat merk je pas dat hij slechter werkt als een gebruiker klaagt.
Tracing. Leg van elke uitvoering vast welke modelaanroepen, toolaanroepen en vaardigheden erin zaten, met tokens, kosten en doorlooptijd. Als een antwoord niet klopt, zie je dan of de agent de verkeerde vaardigheid laadde, een bron miste of een tool verkeerd aanriep.
Een vaste testset. Verzamel twintig tot vijftig echte vragen per proces, met de uitkomst die je verwacht. Controleer harde eisen automatisch, zoals of de juiste velden zijn ingevuld of de juiste tool is aangeroepen. Laat een tweede model de inhoud beoordelen aan de hand van een rubric. Draai de set bij elke wijziging aan een vaardigheid, aan het geheugen of aan het model.
Wisselen van model als vast ritueel. Omdat kennisbank en geheugen bestanden in eigen beheer zijn, kun je een nieuw model proberen door alleen de modelinstelling te wijzigen en de testset te draaien. Scoort het beter of goedkoper, dan stap je over.
Documentatie en verantwoording. Leg per agent vast wat hij doet, welke gegevens hij gebruikt, welke koppelingen en rechten hij heeft en wie eigenaar is. De rechtenmatrix is daar een goed begin van. Voor organisaties die onder de AI Act vallen, is deze vastlegging bovendien het vertrekpunt voor de beoordeling van rol en risico.
Wat nog lastig is
Een bedrijfsharness is geen kant-en-klaar product dat je aanzet. Drie onderdelen vragen nog veel aandacht.
Geheugen is het minst uitgewerkte deel. Een agent die zelf bepaalt wat hij onthoudt, onthoudt soms de verkeerde dingen, of iets dat over een halfjaar niet meer klopt. Iemand in de organisatie moet het organisatiegeheugen geregeld nalopen.
Identiteit en rechten kosten tijd. Per systeem bepalen wie wat mag, namens wie en in welk kanaal, is werk dat je niet wilt overslaan. Een fout hier betekent een mail namens de verkeerde persoon, of klantgegevens in een kanaal waar ze niet horen.
Taken zonder toeschouwer vragen vertrouwen. Een agent die 's nachts zelf aan de slag gaat, moet weten waar hij stopt. Handelingen die je niet kunt terugdraaien, zoals versturen, verwijderen of betalen, horen achter een akkoord van een mens. De agent bereidt voor, de mens drukt op de knop.
Hoe je begint
Bouw dit niet in één keer voor de hele organisatie. Begin klein, en laat de harness meegroeien met het gebruik.
- Kies één team met een terugkerend, goed afgebakend proces. Denk aan het beoordelen van aanvragen, het voorbereiden van klantgesprekken of het maken van een maandrapportage.
- Schrijf de werkwijze van dat team uit als vaardigheden: korte, losse instructies per taak.
- Koppel twee of drie bronsystemen, eerst met alleen leesrechten.
- Zet de agent in het kanaal waar het team al werkt.
- Stel de rechtenmatrix op en voeg schrijfrechten toe, per koppeling namens de gebruiker of met een eigen identiteit.
- Begin met een organisatiegeheugen van een paar pagina's en laat het groeien. Wijs iemand aan die het bijhoudt.
- Voeg pas geplande taken toe als het team de agent vertrouwt bij het werk dat het zelf start.
Het tweede team gaat sneller dan het eerste. De koppelingen, de rechtenmatrix en een deel van de kennis liggen er dan al.
Tot slot
De vraag is niet langer welk taalmodel het slimst is. Dat antwoord is over een halfjaar alweer anders. De vraag is hoe goed je organisatie alles eromheen inricht: waar de agent werkt, namens wie, met welke kennis en onder welke afspraken. Daar zit de waarde die blijft.
Lees meer over hoe wij AI-agents en kennissystemen bouwen. Wil je sparren over de opzet voor jouw organisatie, of meekijken naar een eerste proef? Neem contact op of mail naar info@gaide.nl.