Hoe wij ons eigen AI-harnas hebben opgezet (en wat er onderweg misging)

Van theorie naar praktijk

In het vorige artikel beschreven we waarom de AI-harnas belangrijker wordt dan de keuze voor het model.

De korte versie: voor veel MKB-taken zijn de grote taalmodellen inmiddels goed genoeg. Het verschil zit niet meer vooral in Claude, GPT of Gemini. Het verschil zit in wat je eromheen organiseert: de context die het model krijgt, de tools die het mag gebruiken, de manier waarop taken worden verdeeld en de feedback waardoor het systeem beter wordt.

Dat was de theorie. Dit artikel is het praktijkvervolg. Hoe hebben wij onze eigen AI-harnas ingericht? Wat werkt goed? Waar liepen we vast? En welke lessen zijn relevant voor MKB-bedrijven die AI niet als losse prompt willen gebruiken, maar als serieus onderdeel van hun bedrijfsvoering? Geen gladde showcase dus, wel een eerlijk werkverslag.

Onszelf als eerste klant

Bij And AI behandelen we onszelf bewust als eerste klant. We bouwen AI-systemen eerst voor onze eigen workflows, gebruiken ze dagelijks, lopen tegen de beperkingen aan en verbeteren ze daarna pas verder voor klanten.

Dat klinkt logisch, maar dat is het in de AI-markt niet altijd. Veel bureaus bouwen AI-oplossingen voor klanten, terwijl ze intern nog vooral met losse ChatGPT-prompts werken. Wij hebben gekozen voor de omgekeerde route: eerst zelf voelen waar het schuurt.

Het voordeel daarvan is concreet. Je ontdekt eerder waarom een systeem dat op papier werkt in de praktijk stukloopt, bijvoorbeeld op ontbrekende context, te brede tooltoegang, slechte validatie, foutieve exports of correcties die nergens worden opgeslagen. De belangrijkste les: een AI-systeem in productie is nooit af. Het moet gecontroleerd worden, kunnen leren en continu worden bijgesteld.

De vier onderdelen van onze AI-harnas

Een werkend AI-systeem bestaat niet alleen uit een model. Het model is belangrijk, maar het verschil zit meestal in wat eromheen staat. Bij ons bestaat de harnas uit vier onderdelen: context, tools, orkestratie en feedback.

Context: drie vaults, één bewust zonder AI

Wij gebruiken drie aparte Obsidian-vaults. De management-vault bevat strategische beslissingen, projectstatussen, klantdossiers en meeting-samenvattingen. De development-vault bevat technische documentatie, architectuurkeuzes en sessielogs van ons bouwwerk. De business-vault bevat HR-gegevens, financiële afspraken, contractwaarden en vertrouwelijke informatie.

Die laatste vault heeft bewust geen AI-toegang. Niet omdat dat technisch niet kan, maar omdat we vinden dat sommige informatie niet door een taalmodel hoeft te lopen, ook niet als het op papier veilig kan. Sommige grenzen wil je niet pas trekken als er iets misgaat.

Daarnaast gebruiken we context uit Fireflies, ClickUp, Gmail en GitHub: niet alles tegelijk, maar alleen waar het relevant is voor de taak. Een meeting-agent hoeft geen financiële afspraken te zien, een development-agent hoeft geen saleshistorie te lezen, en een sales-agent hoeft niet bij technische sessielogs te kunnen als dat voor zijn taak niets toevoegt.

Het principe daarachter is simpel: geef een kaart, geen handleiding. Een agent hoeft niet alle informatie tegelijk te krijgen. Hij moet eerst kunnen zien waar de juiste informatie staat, en daarna gericht ophalen wat nodig is. Dat voorkomt ruis, versnelt het werk en maakt de uitkomst beter controleerbaar.

Tools: bewust beperken per agent

We hebben momenteel achttien gespecialiseerde agents in productie. Elke agent heeft een bewust beperkte set tools. Sommige agents mogen alleen lezen, andere mogen taken aanmaken, code aanpassen of bestanden klaarzetten. Niet elke agent krijgt toegang tot alles.

Dat is geen beperking uit zwakte, maar een ontwerpkeuze. Hoe meer tools een agent heeft, hoe groter de kans dat hij de verkeerde route kiest. Een brede agent lijkt handig, maar is moeilijker te controleren en lastiger te debuggen. Een goede agent hoeft niet alles te kunnen; hij moet precies genoeg kunnen om zijn taak betrouwbaar uit te voeren.

Dat maakt het systeem eerlijker. Je weet wat een agent kan, wat hij niet kan, en waar menselijke controle nodig blijft. Dat is veel bruikbaarder dan een agent die “alles” kan, maar waarvan niemand precies begrijpt wat hij doet.

Orkestratie: twee teams, drie pipelines

Onze agents zijn verdeeld over twee teams. AIKO DEV richt zich op development, technische research, code reviews en pull requests. AIKO OPS richt zich op sales, finance, intake, klantoverzicht en interne bedrijfsvoering.

Daaroverheen lopen drie hoofdpipelines. De sales-pipeline begint bij een nieuwe lead en loopt via prospect-research, gespreksvoorbereiding, meeting-opname, transcript-verwerking en offertebijlage. De meeting-pipeline begint bij een Fireflies-opname en loopt via transcript-extractie, ticket-aanmaak en memory-update. De development-pipeline begint bij een specificatie en loopt via epic-aanmaak, codering, security-review en pull request.

Een belangrijke keuze: agents geven werk aan elkaar door via het filesystem, niet via de volledige conversatiecontext. Dat klinkt technisch, maar het principe is eenvoudig. We willen niet dat één agent de redenering van een andere agent klakkeloos meeneemt. Elke agent moet zijn eigen taak uitvoeren op basis van de juiste input, niet op basis van de hele gedachtegang ervoor. Zo blijft het werk beter controleerbaar, en als er iets fout gaat, kun je terugvinden waar het fout ging.

Feedback: correcties moeten ergens heen

Het feedback-systeem heeft ons het meeste tijd gekost, maar levert ook het meeste op. Een AI-systeem wordt niet vanzelf beter omdat iemand een keer zegt dat iets fout is. Die correctie moet ergens worden vastgelegd en op het juiste moment opnieuw worden gebruikt.

Wij werken met drie niveaus. Tier 1 bevat kritieke regels die altijd worden gelezen en direct in agent-prompts zitten. Tier 2 bevat actieve werkregels die per sessie beschikbaar zijn als achtergrondinformatie. Tier 3 is archief: nuttige historische context, maar niet actief in de dagelijkse flow.

Daarnaast gebruiken we drie mechanismen: na een sessie kunnen correcties worden vastgelegd, handmatig gecorrigeerde output kan worden vergeleken met de oorspronkelijke output om patronen te vinden, en kritieke regels worden afgedwongen via hooks en validatiestappen. De les is simpel: feedback moet ontworpen worden, anders verdwijnt hij.

Drie uitdagingen die we niet zagen aankomen

De opzet klinkt achteraf logisch. Maar in de praktijk liepen we tegen drie structurele problemen aan.

Het zelflerende systeem werkt niet vanzelf

Het idee was simpel: leg correcties vast als geheugen, en het systeem leert. In de praktijk werkt dat niet zo automatisch.

Een voorbeeld: we hadden vastgelegd dat we geen em-dashes wilden gebruiken. Bij PDF-generatie ging dat goed, maar bij LinkedIn-posts verscheen de em-dash alsnog. De regel bestond wel, maar werd niet in elke context afgedwongen. Een ander voorbeeld: klantcijfers stonden verspreid over meerdere documenten. Eén document werd gecorrigeerd, maar de oude cijfers bleven op andere plekken staan. Het systeem had dus geen centraal besef dat de waarheid gewijzigd was.

De les: “onthouden” is niet genoeg, een regel moet worden afgedwongen waar hij belangrijk is. Daarvoor zijn er grofweg drie opties: inbouwen in de agent-prompt, afdwingen via een hook of accepteren dat het niet betrouwbaar gebeurt. Sindsdien stellen we bij correcties expliciet de vraag: waar moet deze regel gelden? Alleen in offertes, ook in LinkedIn-posts, alleen bij PDF-generatie of overal? Zonder die keuze wordt geheugen een rommelige bak goede bedoelingen.

Presentaties bleken verraderlijk

Presentaties maken met AI lijkt eenvoudig, tot je het serieus probeert te automatiseren. Wij liepen tegen allerlei kleine fouten aan die in de praktijk groot worden: een font dat niet geïnstalleerd was, een tekstlaag die in de PDF-export onder een vlak verdween, een verkeerd logo op een donkere achtergrond, een slide die in de preview goed leek maar in de export niet klopte.

Dat zijn geen spectaculaire AI-fouten, maar juist daarom zijn ze gevaarlijk. Ze lijken klein, tot je een presentatie naar een klant stuurt en de covertekst niet leesbaar is.

De les: een presentatie is niet één taak, maar een keten van stappen. Structuur, copy, ontwerp, fonts, lagen, export, contrast, logo’s, huisstijl en validatie moeten allemaal kloppen. Daarom is validatie geen extra stap aan het einde, maar onderdeel van het systeem. Een AI die een presentatie maakt, moet niet alleen slides genereren. Hij moet ook controleren of de output klopt.

Skills kosten meer tijd dan je denkt

We hebben inmiddels tientallen skills gebouwd of getest. Sommige werken goed, andere zijn herschreven, en een paar bleken achteraf niet de moeite waard. Onze eigen website was oorspronkelijk ingeschat op twaalf uur, uiteindelijk kostte hij veertig uur. Niet omdat AI niets kon, maar omdat stabiel maken, testen, corrigeren en opnieuw structureren veel tijd kost.

Dat is een terugkerend patroon. De vraag is niet: kunnen we dit als skill bouwen? Meestal kan dat wel. De betere vraag is: is deze skill de tijd waard, hoeveel iteraties heeft hij nodig en bestaat er al een native oplossing die sneller of betrouwbaarder is?

Dat is een belangrijk verschil. AI maakt bouwen makkelijker, maar niet automatisch alles zinvol om te bouwen. Sommige automatiseringen verdienen een robuuste skill, andere blijven beter een prompt, checklist of standaardproces.

Wat dit voor het MKB betekent

De les voor het MKB is niet dat ieder bedrijf zijn eigen AI-harnas van nul af aan moet bouwen. Dat is meestal niet realistisch en ook niet nodig. De les is wel dat elk serieus AI-project langs dezelfde vier vragen moet: welke context heeft de AI nodig, welke tools mag de AI gebruiken, hoe worden taken verdeeld en gecontroleerd, en hoe vloeien correcties terug?

Als die vragen niet beantwoord zijn, heb je geen AI-implementatie. Dan heb je een losse prompt, een chatbot of een demo. Dat kan nuttig zijn, maar het is nog geen systeem dat structureel werk uit handen neemt.

Voor MKB-bedrijven zijn drie lessen direct toepasbaar. Eén: begin intern. Kies een proces dat je zelf goed begrijpt en gebruik dat als eerste test. Daar leer je sneller van dan van een extern klantproces. Twee: plan ruim. AI-projecten kosten vaak twee tot drie keer meer iteratie dan je eerste inschatting, niet omdat de techniek niets kan, maar omdat betrouwbaarheid tijd kost. Drie: bouw feedback eerder in dan extra functionaliteit. Een klein systeem dat goed leert van correcties is waardevoller dan een groot systeem dat dezelfde fouten blijft herhalen.

Hoe je hier praktisch aan begint

Begin niet met de vraag welk model je moet kiezen, maar met het proces. Pak één proces waar veel herhaling in zit, waar voldoende informatie beschikbaar is en waar menselijke controle logisch blijft. Denk aan projectrapportages, gespreksverslagen, offertevoorbereiding, interne kennisvragen of documentanalyse.

Loop daarna vier vragen langs. Context: welke informatie heeft de AI nodig om goed werk te leveren? Staat die informatie op één plek, of moet een medewerker die steeds opnieuw aanleveren? Tools: wat mag de AI doen behalve antwoorden geven? Mag hij documenten lezen, taken aanmaken, conceptmails schrijven of systemen bijwerken? Orkestratie: is dit één brede agent, of zijn er meerdere kleine stappen met duidelijke controlepunten? Feedback: wat gebeurt er als iemand de output corrigeert? Wordt die correctie vastgelegd, of verdwijnt hij in de inbox?

Als drie van de vier vragen geen helder antwoord hebben, weet je waar je eerste werk zit. Concurrentievoordeel zit niet in modelkeuze, niet in de zoveelste tool. Het zit in hoe goed je organisatie leert van wat misgaat.

Veelgestelde vragen