Onze AI schreef keurige mails. De fout zat bijna altijd in de eerste zin.

Van de oprichter

Ik ben Menno, oprichter van Canoniek. Ik ben geen programmeur en ik heb nog nooit een regel code geschreven. Wat ik wel heb is vijfentwintig jaar in de digitale marketing en een hoofd dat in processen denkt. Met dat procesdenken en Claude Code bouw ik tegenwoordig dingen waarvoor ik vroeger een team nodig dacht te hebben. Vandaag deel ik een fout die we lang over het hoofd zagen omdat hij er netjes uitzag, zodat jij hem sneller herkent dan wij.

In het kort. Onze AI-assistenten schreven nette, uitgebreide berichten. Te uitgebreid. We dachten dat dat een kwestie van stijl was. Tot we merkten dat de feitelijke fouten stelselmatig in hetzelfde stuk zaten: de ongevraagde aanloop aan het begin. Dat is het enige deel van een bericht dat niet uit een bron komt, maar ter plekke wordt bedacht. Wijdlopigheid is dus niet alleen vervelend. Het is de plek waar het verzinsel ontstaat.

De mail die klopte, behalve de opening

We schreven eerder over een assistent die antwoordde om te antwoorden: hij stuurde een keurig mailtje terug terwijl er werk lag. Dit is de opvolger van dat probleem, en hij is vervelender, want hij is moeilijker te zien.

Een van onze assistenten stelde een mail op voor een klant. De inhoud klopte. De afspraken klopten, de bedragen klopten, de vervolgstap klopte. Alleen begon het bericht met een zin in de trant van “zoals we vorige week bespraken”. Dat gesprek was niet vorige week. Het was drie weken eerder, en het ging over iets anders.

Eén zin, en de hele mail was onbruikbaar. Niet omdat de rest fout was, maar omdat een klant die dat leest terecht denkt: als dit niet klopt, wat klopt er dan nog meer niet? Je kunt zo’n bericht niet half versturen.

Toen we dit vaker zagen, viel het patroon op. De fout zat nooit in de kern. Hij zat in de aanloop, in de samenvatting vooraf, in de terugblik die niemand had gevraagd. Precies in het deel dat het bericht langer maakte.

Je AI praat te veel omdat hij daarvoor beloond is

Wij dachten aanvankelijk dat dit slordigheid was, iets wat je met een betere instructie wegpoetst. Dat is het niet. Het is aangeleerd gedrag, en het zit dieper dan een instructie reikt.

Taalmodellen worden bijgestuurd met menselijke beoordelingen. Mensen kregen twee antwoorden te zien en kozen welke beter was. Uit dat werk komt een bekend en goed gedocumenteerd effect, dat in de literatuur length bias heet: beoordelaars kiezen systematisch het langere antwoord. Niet omdat het beter is, maar omdat het grondiger oogt. Een uitgebreid antwoord voelt als moeite, en moeite voelt als kwaliteit.

Het model heeft daaruit precies de verkeerde les getrokken. Het produceert lengte omdat lengte scoorde. Dat is geen fout in de zin van een bug, het is het gedrag waar het model op is afgericht. En daarom breekt het dwars door je instructie heen: je vraagt om kort, maar je vraagt iets wat tegen zijn eigen training in gaat.

Voor een kantoor is dat een verschil dat telt. Slordigheid los je op met een betere afspraak. Getraind gedrag los je op met structuur.

Waarom “hou het kort” niet werkt

Onze eerste reflex was de voor de hand liggende: gewoon in de instructie zetten dat het korter moet. Wees beknopt. Geen inleiding. Niet wijdlopig.

Dat werkte niet, en het ging op twee verschillende manieren mis.

Verbied je een concreet onderdeel, “geen aanloop”, dan krijg je dat onderdeel alsnog. Je hebt het genoemd, en daarmee ligt het op tafel. Dat is de roze olifant: probeer maar eens niet aan een roze olifant te denken.

Verbied je een richting, “niet te formeel”, dan gebeurt iets anders en vervelenders. Hij wordt niet stijf, hij schiet door naar de andere kant en doet opeens joviaal. Het is altijd te veel of te weinig, nooit het midden. Dat is ook logisch: “niet te formeel” zegt waar hij weg moet, niet waar hij moet uitkomen. Zonder eindpunt wordt afstand nemen het doel, en dan is verder weg altijd beter. Wij zien dat het sterkst bij feedback tussendoor. Zeg je dat een tekst te lang is, dan komt er niet een goede kortere versie terug maar een uitgeklede.

Wat wel aankomt is een opdracht die zegt waar hij moet uitkomen in plaats van waar hij weg moet. Niet “wees niet wijdlopig”, maar “lever de mail zelf, van aanhef tot ondertekening”. Niet “geen aanloop”, maar “begin bij het voorstel”. Dat is dezelfde regel, andersom geformuleerd, en dat verschil is niet cosmetisch.

Hoe we het nu doen: niet sturen op lengte, maar op begin en herkomst

De ingreep waarmee het bij ons ophield, is dat we het over lengte niet meer hebben. In onze instructie staat nergens dat iets kort moet zijn. Er staat twee dingen: waar een bericht begint, en dat elke zin ergens vandaan moet komen. Begin bij de statuswijziging of het voorstel, en zet er alleen in wat gevraagd is en wat is nagetrokken.

Daar zit de hele truc in: een aanloopje komt nergens vandaan, dus het haalt de bron-toets niet. Het is de enige alinea die niet uit een dossier, een mail of een systeem is opgehaald, maar ter plekke bedacht om beleefd te zijn. Je hoeft het niet te verbieden.

En dat werkt beter dan een lengte-instructie omdat het geen schuifknop is. “Begin bij het voorstel” doe je wel of niet.

Daarnaast scheiden we nadenken en opleveren, twee dingen die we eerst op één hoop gooiden.

Een assistent mag intern zo uitgebreid redeneren als hij wil. Sterker nog, dat moet je niet inperken. Zet je een lengtelimiet op het denken zelf, dan gaat de kwaliteit van het denken achteruit, want dan moet hij gaan formuleren voordat hij klaar is met nadenken. Wat wel moet, is dat er van al dat denkwerk niets in de uitgaande tekst terechtkomt behalve de uitkomst.

Daarbij hoort een tweede inzicht dat we duur hebben geleerd: er is geen enkele regel die voor alles tegelijk werkt. In een intern gesprek wil je juist de onderbouwing zien. Wordt daar te vroeg samengevat, dan mis je waar de conclusie op rust. In een mail naar buiten is elke uitleggende zin een probleem, want die verraadt niet alleen dat er een machine aan het werk was, maar is ook precies de plek waar het verzinsel binnenkomt. Eén regel voor beide domeinen levert altijd op één van de twee slecht werk op.

De stappen

Dit staat sinds eind juli in de instructie waarmee onze assistenten werken. Ik zet het hier zoals het bij ons staat, want het aardige is dat er geen enkel verbod in zit.

1. Zeg waar het bericht begint. Bij ons: elk bericht opent, na een korte groet, direct met de actuele statuswijziging, het concrete voorstel of de vraag waar het om gaat. De geschiedenis en de verantwoording vooraf blijven onbesproken. Dat is dezelfde regel als “geen aanloop”, maar hij geeft een eindpunt in plaats van een vluchtrichting.
2. Koppel elke zin aan een bron. In een uitgaand bericht staat alleen wat gevraagd is en wat is nagetrokken. Kan een gegeven niet aan een document, een mail of een systeem gekoppeld worden, dan hoort het er niet in, hoe kort ook. Deze regel vangt de aanloop vanzelf af, want die heeft per definitie geen bron.
3. Kort betekent dichter, niet minder. De regel bij ons luidt: beknoptheid door informatiedichtheid, niet door inhoud te schrappen. Dat zinnetje is er specifiek om het doorschieten te voorkomen.
4. Zet het verbod in de controle, niet in de opdracht. Wij hanteren de afspraak dat elke laag die tekst maakt alleen positieve regels krijgt, en dat de scherp geformuleerde fout uitsluitend in de controlelaag staat, bij de partij die achteraf beoordeelt. Twee formuleringen van dezelfde regel, elk op de plek waar hij werkt.
5. Controleer of de regel gelezen wordt. De valkuil waar wij in trapten: een regel keurig vastleggen in een bestand dat niets of niemand op het juiste moment inleest. Vastgelegd is niet hetzelfde als actief. Bij elke nieuwe regel hoort daarom de vraag wie hem leest, en wanneer.

Wat negentien mails ons lieten zien

We hebben negentien berichten die onze assistenten opstelden vergeleken met wat er uiteindelijk daadwerkelijk verzonden is, na onze eigen correcties. Niet om de assistent te beoordelen, maar om te zien wat een mens er stelselmatig aan verandert. Dat patroon was opvallend consistent.

Wat de assistent oplevert	Wat wij eruit haalden of toevoegden
Aanloop met een terugblik op de geschiedenis	Geschrapt, vrijwel elke keer dat het voorkwam
Uitleg waarom iets voorgesteld wordt	Geschrapt, de lezer kent zijn eigen dossier
Jargon en systeemtaal	Vervangen door gewone woorden
Concreet getal, datum of bedrag	Toegevoegd waar het ontbrak
Eigen waarneming of anekdote	Toegevoegd

Acht van de negentien gingen overigens ongewijzigd de deur uit. Dat waren steevast de korte, feitelijke berichten; het patroon hierboven geldt vooral zodra een bericht iets moet overtuigen.

De rode draad is verrassend scherp: wij halen verantwoording weg en voegen onderbouwing toe. Minder uitleggen waarom iets klopt, meer laten zien waaruit het blijkt. Dat is wat “korter” bij ons in de praktijk betekende, en het is iets anders dan simpelweg schrappen.

“Waarom praten al die agents toch zoveel poep?”

Dat vroeg ik toen we het patroon eenmaal doorhadden, en daar is het onderzoek uit gekomen waar dit stuk op rust. Het antwoord bleek niet “omdat ze slecht zijn ingesteld”, maar “omdat ze daarvoor beloond zijn”.

Waarom dit een vak blijft

Het klinkt eenvoudig als je het zo opschrijft. Zeg waar een bericht begint, eis van elke zin een bron, maak het dichter in plaats van korter, en zet het verbod bij de controle in plaats van in de opdracht.

De moeite zit niet in het bedenken ervan, maar in het volhouden. Elke regel moet ergens staan waar hij ook echt gelezen wordt op het moment dat het ertoe doet, anders is hij een goed voornemen. Elk soort bericht heeft zijn eigen versie nodig, want intern en extern vragen het tegenovergestelde. En je merkt pas dat een regel niet aankomt als er een mail de deur uit is die niet klopt.

Dat is precies het werk dat wij doen: niet een AI aanzetten, maar de structuur eromheen inrichten en bijhouden. Op je eigen infrastructuur, met jouw eigen richtlijnen erin.

Eerlijk is eerlijk

Onderweg lag er een voorstel om het tellend op te lossen: maximaal zoveel zinnen per soort bericht, een automatische controle op woordental en op openingszinnen die we niet willen. Dat is er nooit gekomen en dat gaat er ook niet komen. Het is dezelfde denkfout in een nieuw jasje, want een aantal is ook maar een schaal om op door te schieten.

Wat er wel is gekomen staat sinds 29 juli in de instructie die onze assistenten bij elke sessie inlezen, en het effect is voor mij het duidelijkst te merken aan wat er niet meer gebeurt: ik zie geen aanloopjes meer. De berichten die ik ter goedkeuring krijg beginnen bij wat er speelt.

Waar ik eerlijk in wil zijn: dat is mijn waarneming als lezer van alles wat er uitgaat, geen meting. Er draait geen teller mee die controleert of de regel wordt nageleefd, en die komt er ook niet. Wat ons betreft is dat geen tekortkoming maar dezelfde keuze als hierboven: dit is werk dat je beoordeelt, niet werk dat je afvinkt.

Zelf aan de slag of laat ons helpen

Wil je dit zelf proberen, dan staat de bredere methode open op GitHub. Je kunt vandaag beginnen met de eenvoudigste versie: zet in je instructie dat een bericht direct met de kern begint en dat alles wat erin staat aan een bron te koppelen moet zijn.

Wil je liever dat het meteen goed staat, plan dan een kennismaking. Wij komen niet om uren te schrijven, maar om ons framework snel en zorgvuldig op jouw eigen infrastructuur in te richten.