Bouw je eigen e-mailassistent met AI: wat werkt en wat niet?

Ik ben op zijn zachtst gezegd geen fan van e-mail. Als het geen ongewenste updates, nieuwsbrieven waar je je nooit voor hebt aangemeld of automatische verkoopmails zijn, dan is het wel de takenlijst van iemand anders die je inbox vult.

Dus ik kijk er zelden naar.

Daardoor mis ik af en toe iets belangrijks, en nog erger, ik reageer soms veel te laat op mensen die beter verdienen. En nee, ik wil geen PA. ‘Maar een PA blinkt uit in wat jij niet kunt’, ja, dat weet ik. En ze zijn geweldig. Maar wat maakt mij zo bijzonder dat ik in aanmerking kom voor een PA? Het mist de gelijkwaardigheid waar ik in mijn werk naar streef.

Na jarenlang te hebben gesleuteld aan ‘slimme’ e-mailfilters die voortdurend moesten worden bijgewerkt, besloot ik AI-e-mailautomatisering te proberen met een twist: alles draait lokaal, dus mijn gegevens – en nog belangrijker, de gegevens van de mensen die mij mailen – verlaten mijn computer nooit.

Deze automatisering met een twist is wat mij betreft een uitgelezen voorbeeld van waar AI waarde toevoegt: repetitieve taken overnemen en zelf in control blijven als het gaat om kwaliteit, privacy en waardevolle interacties met collega’s en klanten. Dus doe er je voordeel mee zodat minder tijd kwijt bent aan mail en meer tijd kunt besteden aan interacties die er echt toe doen.

In dit artikel deel ik:

• Welke open-sourcemodellen echt werken voor het classificeren van e-mails
• Waarom het aanroepen van tools lastiger is dan je zou verwachten
• De debugging-nachtmerries van N8N (en hoe je die oplost)
• Echte prestatiecijfers: wat 80% nauwkeurigheid eigenlijk betekent

Ik duik soms de diepte in en het wordt zo nu en dan technisch, maar ik neem je dan ook van A tot Z mee in het bouwen van mijn e-mailfabriek.

Het doel van mijn ‘e-mailfabriek’ was simpel: spam archiveren en de rest in drie hoofdcategorieën sorteren:

• Actie: ik moet er iets mee doen
• Lezen: ik moet ervan op de hoogte zijn
• Archiveren: tot ziens

Dan zijn er nog een paar uitzonderingen. Zaken die in mijn agenda moeten worden gezet, zijn daar een voorbeeld van. Laten we eens kijken of we dat automatisch kunnen doen voordat we het bericht categoriseren of archiveren.

Als een actie om een antwoord vraagt, zou het ook heel fijn zijn om een bericht op te stellen met de juiste contactnaam en handtekening in de juiste taal. En ik krijg vaak facturen die in het administratiesysteem van Voys moeten worden verwerkt, dus die moeten worden doorgestuurd naar een ander e-mailadres.

Mijn tools voor deze klus: N8N als workflow-engine, gekoppeld aan open-source AI-modellen via Ollama. Met Ollama kun je grote taalmodellen rechtstreeks op je lokale machine draaien, wat volledige privacy garandeert en de flexibiliteit biedt om meerdere modellen te draaien wanneer dat nodig is.

Tools geselecteerd, missie duidelijk. Laten we dit eens proberen. En man, wat heb ik veel geleerd.

Om de e-mailautomatisering met AI goed te laten werken, heb je de juiste ondersteuning door AI-tools nodig. Een LLM functioneert doorgaans als een systeem voor het genereren van tekst of afbeeldingen. Tool-ondersteuning houdt in dat een LLM gebruik kan maken van externe tools, functies of integraties met andere systemen (API’s) om acties uit te voeren die verder gaan dan het genereren van tekst.

Hier liep ik tegen de eerste problemen aan, want niet elk model biedt toolondersteuning.

Modellen die toolondersteuning bieden zijn onder andere Llama 3.1 en Qwen 3. Llama is het open-sourcemodel van Meta dat sinds versie 3.1 toolondersteuning biedt. Llama 3.2 ondersteunt ook kleinere modellen. Daarover later meer. Qwen 3 is ontwikkeld door Alibaba en heeft een denkmodus. Maar dat denken interfereert vaak met het aanroepen van tools, dus online wordt vaak gezegd dat Qwen 2.5 voor dit doel wellicht beter werkt.

Je ziet vaak iets als :4b of :8b achter een modelnaam staan. Dit geeft het aantal parameters aan, oftewel hoeveel miljarden gewichten het model heeft. Meer parameters betekent over het algemeen meer mogelijkheden, maar ook trager en meer geheugengebruik.

Kwantisering is iets heel anders. Het gaat om precisie: hoeveel bits er worden gebruikt om elke parameter op te slaan. Zie het als beeldcompressie. Een foto in volledige kwaliteit neemt meer ruimte in beslag dan een JPEG, maar de JPEG is meestal goed genoeg.

Wanneer je een model downloadt via Ollama, kiest het een verstandige standaardkwantisering voor je. Als je meer controle wilt (bijvoorbeeld een kleinere versie die sneller draait op beperkte hardware), kun je zoeken naar varianten met namen als Q4_K_M of Q8_0. Het getal geeft het aantal bits per gewicht aan: Q4 gebruikt ongeveer 4 bits, Q8 gebruikt 8 bits.

Een lagere kwantisering betekent een kleiner bestand, snellere inferentie en minder benodigd geheugen, maar levert mogelijk slechtere output. Q4 is meestal de beste keuze voor lokaal gebruik: ongeveer vier keer kleiner dan volledige precisie met minimaal kwaliteitsverlies.

Welke modellen werken het beste? In mijn geval Qwen3:4b. “Maar net zei je nog dat de denkmodus van Qwen 3 dingen in de war brengt.” Dat klopt, maar de niet-denkmodus heeft aanzienlijke verbeteringen opgeleverd in het 4b-model, en het is klein en relatief snel. Het model had echter vaak moeite om ‘zichzelf’ te vertellen dat een tool-aanroep succesvol was, wat resulteerde in een tool-aanroep-lus. Dit werd opgelost met betere prompts en uitvoeropmaak.

Ik heb ook Llama3.1:8b getest, dat sneller is en kwam niet in een lus terecht, maar bracht wel een heleboel nieuwe problemen met zich mee. Het kon maar niet beslissen hoe het antwoorden moest opmaken, waardoor m’n systeem in de war raakte en placeholder-rommel serveerde. In wezen heeft het moeite met het genereren van complexere JSON. Daarover later meer. Erger nog, op de vraag: “Is 5 november vóór 3 december?”, haalde Llama zijn schouders op en gokte verkeerd.

Qwen3:4b is weliswaar langzamer, maar kan beide gebruikssituaties met een beetje hulp veel beter aan.

De les? Een sneller model dat je verkeerde antwoorden geeft, is eigenlijk niet sneller; het verspilt gewoon vol vertrouwen je tijd.

Voor het schrijven van e-mails heb ik het grotere Qwen3:14b-model getest, maar dat bleef zijn gedachten in de e-mails opnemen. Je kunt ook de parameter think: false niet doorgeven, wat niet helpt. Het toevoegen van uitvoeropmaak leek overdreven, dus ben ik overgestapt op Gemma3:12B. Maar dat deed hetzelfde. Dus ben ik teruggegaan naar het forceren van uitvoeropmaak en ben ik bij Gemma3:12B gebleven, omdat dit model de Nederlandse taal beter ondersteunt. Alle modellen die ik heb gebruikt, hebben 4-bits kwantisering.

Nu je een model hebt met ondersteuning voor tools, is het tijd om te leren hoe je het kunt gebruiken. Om dit te begrijpen, moet je weten hoe de ondersteuning voor tools en agents onder de motorkap van N8N werkt.

Wanneer je dit soort workflows bouwt, bouw je in feite AI-agenten. LangChain wordt langzaamaan de standaard voor het bouwen van agenten, en N8N maakt onder de motorkap gebruik van LangChain, zodat het daarbovenop als een visueel framework kan functioneren. Dat is erg handig, omdat een visuele interface voor veel gebruikers makkelijker te onderhouden en te begrijpen is dan LangChain ooit zal zijn.

Wat is LangChain? Een open-source framework met een kant-en-klare agent-architectuur en integraties voor veel AI-modellen en -tools.

LangChain werkt beter als je een specifiek formaat (JSON) als invoer gebruikt voor tools. JSON (JavaScript Object Notation) is een eenvoudig, op tekst gebaseerd formaat voor het uitwisselen van gegevens. Het is een formaat dat zowel voor mensen als voor machines leesbaar is.

Maar zelfs taalmodellen met toolondersteuning geven vaak gewone tekst uit, en in dat geval werken de agents niet voor je.

Je loopt dus vaak tegen problemen aan waardoor standaardbouwstenen onbruikbaar worden. Het Text ‘Classifier-blok’ is een voorbeeld. Het mislukte omdat het JSON-uitvoer verwachtte, maar alleen ‘READ’ kreeg van Llama3.1:8b.

Je kunt een model zoals Qwen3:4b dwingen om JSON uit te voeren, wat helpt. Zonder dit af te dwingen, zou het model soms kunnen vergeten om de JSON-verwerking uit te voeren. We moeten hiervoor een andere oplossing vinden.

In veel N8N AI-blokken kun je de optie ‘Specifiek uitvoerformaat vereisen’ inschakelen. Vervolgens kun je het blok ‘Structured Output Parser’ toevoegen en het gewenste JSON-schema definiëren. Hierdoor worden sommige dynamische uitvoeropties die LLM’s vaak bieden, uitgeschakeld en wordt de uitvoer van het blok veel betrouwbaarder. De Text Classifier behoort helaas niet tot de blokken die vervangen moesten worden.

Die schakelaar voor automatisch corrigeren? Ja, handig, maar daarvoor moet er wel een LLM verbonden zijn.

Ideaal voor productomgevingen, maar minder geschikt voor trage testomgevingen. Het hangt ook af van hoe zwaar het model is dat je gebruikt. Het zou bovendien alleen als noodoplossing moeten dienen, en zodra je merkt dat het te vaak op de noodoplossing terugvalt, moet je je systeem echt eens onder de loep nemen en verbeteren. Soms is een codeblok dat de gewenste informatie uit de uitvoer haalt, eigenlijk een betere oplossing.

Een ander probleem waar ik tegenaan liep, was de manier waarop de invoer aan een AI-bouwsteen wordt aangeboden.

Ik besloot eerst om de volledige e-mail in het systeem in te voeren, maar een e-mail bevat vaak veel overbodige opmaakcode. Een e-mail van twee alinea’s kan oplopen tot 1 MB aan gegevens.

Standaard koppel je de output van de ene bouwsteen aan de input van een andere. Als een blok meerdere outputs geeft (bijvoorbeeld 104 e-mails), worden deze één voor één verwerkt door het volgende blok. Het AI-blok werkt echter anders. Het stuurt elke e-mail één voor één naar het taalmodel voor analyse, maar doet dat 104 keer voordat het de juiste tools aanroept: archiveren, taggen, het schrijven van conceptantwoorden.

Als je 104 berichten van 1 MB in batches moet verwerken op een zwaarder model, treden er al snel fouten op.

De eerste oplossing was om de e-mails te vereenvoudigen. Gmail heeft een ‘vereenvoudigde’ API-aanroep die alleen eenvoudige inhoud retourneert. Het alternatief is om het veld met de minste opmaak te selecteren, maar ik vind de vereenvoudigde versie prettig omdat deze zo licht is.

Het volgende dat nodig is om het systeem beheersbaar te maken, is de e-mails één voor één doorlopen om het debuggen eenvoudig te houden.

We stuiten nu op het volgende probleem: hoeveel kan één AI-tool met tool-aanroepfunctie aan? Ik begon met archiveren en labelen, voegde daarna een tool voor het schrijven van concept-e-mails toe, maar kreeg al snel te maken met prestatieproblemen. Hoewel het aanroepen van tools voor het archiveren en labelen prima verliep, werden de concept-e-mails nooit geschreven.

Dus heb ik besloten het systeem op te splitsen. Eerst bepalen we wat voor soort e-mail het is (classificatie), en daarna roepen we de tools aan.

Dat werkt een stuk beter. Zoals je kunt zien, is het kalendergedeelte nog niet geïmplementeerd. Maar let wel: dat tekstclassificatie-element is vervangen vanwege problemen met de JSON-uitvoer.

Dit klinkt allemaal geweldig, maar idealiter wil je het systeem feedback geven over waar het fout is gegaan, zodat het zich kan verbeteren. Dat is een heel nieuw ‘can of worms’ dat we gaan openen, maar nog niet gaan opeten.

Waarom? Omdat je een vorm van geheugen of input nodig hebt voor het LLM, en daarvoor is het goed om je te verdiepen in de basisprincipes van LLM’s.

Het bouwen van een groot taalmodel is een proces dat uit meerdere stappen bestaat. Het begint met het trainen van een basismodel op grote hoeveelheden trainingsdata. Aangezien er geen nieuwe data kan worden toegevoegd zonder het model opnieuw te trainen, is dit model statisch. Het model wordt vervolgens verfijnd of afgestemd. Deze afstemming wordt in het model zelf ingebakken.

Vervolgens is er de vaste systeemprompt. Dit is de basisprompt die elke LLM-bouwer gebruikt om het model basisinstructies te geven. Wanneer je een LLM een instructie geeft, wordt deze in feite boven op de systeemprompt gelegd, die vervolgens aan het afgestemde model wordt doorgegeven.

Ik zou ook kunnen uitleggen dat dit wordt getokeniseerd, maar dat is te gedetailleerd en voorlopig niet relevant. Wat je moet onthouden:

• Je prompt + de systeemprompt zijn de twee dingen die aan het model worden doorgegeven.
• Die systeemprompt en het model zelf zijn statisch: je kunt er geen nieuwe gegevens aan toevoegen.

Het model is statisch. Maar ik wil het meer context geven over wat het in het verleden heeft gedaan en hoe het kan verbeteren. Hoe kunnen we dat doen? Dit is waar RAG om de hoek komt kijken.

Een RAG doorzoekt externe bronnen – vaak een vector-database – op passages die relevant zijn voor de vraag van de gebruiker. En hier wordt het slim. Vervolgens vult het de prompt aan: jouw vraag plus de opgehaalde passages worden samen in de LLM ingevoerd, zodat het model zijn antwoord in een concrete context kan plaatsen. Cool, toch?!

Waarom is dat nuttig?

• Het stelt je in staat om kennis (documenten, wiki’s, logboeken, privégegevens) bij te werken of te vervangen zonder het model opnieuw te trainen, wat goedkoper is en de antwoorden actueel en domeinspecifiek houdt.
• Het verbetert de feitelijke nauwkeurigheid en traceerbaarheid, omdat antwoorden gebaseerd zijn op opgehaalde bronnen waarover je zelf de controle hebt, vaak met citaten of verwijzingen naar die documenten.

Maar in wezen breid je je prompt uit met relevante gegevens.

Het echt coole hier is eigenlijk de vector-database. Door de manier waarop deze informatie opslaat – een numerieke vector-weergave die een ‘embedding’ wordt genoemd – ontstaat relevantie zonder vooraf gedefinieerde relationele structuren.

Hoe dan ook, idealiter zou een e-mailsysteem in de loop van de tijd verbeteren en persoonlijker worden, dus ik zou graag zoiets in N8N bouwen. Maar voorlopig is dat nog een brug te ver. Het is fijn om te weten dat N8N wel bouwstenen heeft voor embeddings en een eenvoudige vector-opslag, maar het voelt allemaal erg basaal aan.

Maar vooral KISS: KEEP IT SIMPLE STUPID.

Nu we dit allemaal hebben besproken, gaan we terug naar de agenda. Allereerst is het HEEL belangrijk om te begrijpen: een LLM begrijpt geen tijd. Je MOET het dus context geven over tijd, zoals de datum van vandaag, om met datumgegevens te kunnen werken. En ik heb nog veel meer geleerd over agenda-afspraken, dus hier is de lijst.

Niet alle agendaconflicten zijn gelijk. Het markeren van elke overlapping zorgt voor ruis, en je hebt vaak veel overlappende dagelijkse persoonlijke afspraken (lunchblokken, focustijd, dagelijkse routines) die kunnen worden verplaatst. Het helpt om onderscheid te maken tussen ‘soft’ en ‘hard’. Het is erg handig om flexibele afspraken in je Google Agenda als ‘Vrij’ te markeren, omdat de API deze kan zien, zodat de AI ze als input kan gebruiken.

SOFT-afspraken (negeer bij conflicten): Afspraken gemarkeerd als ‘Vrij’ in Google Calendar, terugkerende afspraken zonder andere deelnemers, persoonlijke blokkades, routines en tijdregistratie.

HARD-afspraken (echte conflicten): Afspraken met externe deelnemers, afspraken met fysieke locaties, afspraken gemarkeerd als ‘Bezet’ met verplichtingen.

Dit weerspiegelt hoe mensen daadwerkelijk over hun agenda denken.

Ik haalde alle afspraken van de dag ervoor en de dag erna op, maar dit leidde tot veel agenda-afspraken – vooral uitnodigingen voor meerdere dagen. Als je dat rechtstreeks koppelt aan een AI-blok, wordt elke afspraak één voor één getest. Dat is niet wat we willen. Het helpt echt om alle afspraken te aggregeren en dat aan de AI te voeren.

Als een agenda-afspraak wordt bijgewerkt, worden standaard alleen de gewijzigde onderdelen – zoals een nieuwe starttijd of een nieuwe locatie – weergegeven. De overige velden van de agenda-afspraak – zoals de eindtijd – blijven leeg.

Dat betekent dat je zou moeten controleren wat de oorspronkelijke gebeurtenis was en wat er is gewijzigd. De eenvoudigere oplossing: laat de LLM alle gegevens weergeven alsof het een nieuwe gebeurtenis is en gebruik die in het update-knooppunt.

Een paar snelle tips om het testen makkelijker te maken bij het gebruik van AI-blokken in N8N.

Je kunt de uitvoergegevens van een blok vastzetten, zodat deze statisch worden en je het blok niet opnieuw hoeft uit te voeren om gegevens voor testdoeleinden te verkrijgen. Dit is een handige functie.

Het testen van LLM-knooppunten is lastig. Ten eerste zijn ze traag, en als je de ‘loop building loop’ gebruikt, kun je de uitvoergegevens niet vastzetten. Het helpt om het ‘Edit fields’-blok te gebruiken en de JSON-uitvoer daarin te plaatsen. Verwijder de verbinding met de rest van de flow en zet de uitvoer vast, zodat je deze kunt gebruiken als invoer voor de blokken die je wilt testen. Op deze manier kun je deze blokken effectief bouwen.

Als het deel van de workflow dat je wilt testen nog steeds is gekoppeld aan de volledige workflow, krijg je vaak vreemde fouten, zelfs als je de gegevens hebt vastgezet. Het loskoppelen van het deel dat je wilt testen is meestal de enige oplossing. Verderop in dit artikel geef ik nog een paar tips voor dit soort fouten.

Wanneer knooppunten vastgezette of nepgegevens bevatten, kan .item mislukken. Gebruik .first() voor betrouwbaarheid:

javascript

`// Kwetsbaar $(‘Node’).item.json.field

// Robuust $(‘Node’).first().json.field`

Wanneer Switch-knooppunten niet overeenkomen ondanks dat ze er correct uitzien, controleer dan op onzichtbare tekens (spaties, tekens met een breedte van nul) in je match-waarden. Kopiëren en plakken vanuit andere bronnen zorgt hier vaak voor.

Tijdens het werken in N8N krijg je deze foutmelding vaak te zien. Geen idee wat het betekent, lost zich vaak vanzelf op:

Kan eigenschappen van undefined niet lezen (leest ‘disabled’)

Maar nadat ik een extra optie aan de Text Classifier had toegevoegd, zat ik vast.

Symptomen:

• De workflow crasht bij het verbinden van Loop Over Items met de Text Classifier
• Als je de Loop verwijdert → werkt de workflow prima
• Loop verbonden met zichzelf → werkt prima
• Loop verbonden met Text Classifier → crasht direct
• Ik vermoedde dat de 6e output (INVOICE) het knooppunt beschadigde

Op internet wordt nu aangeraden om de workflow op de lelijke manier te resetten: Ctrl+A → Ctrl+C → Delete → Ctrl+V. Dat werkte niet. Ik heb toen alles geprobeerd: het Text Classifier-knooppunt helemaal opnieuw opbouwen, op GitHub zoeken naar bekende bugs, N8N updaten naar de nieuwste versie, System Prompt Template-opties toevoegen, outputs verwijderen en opnieuw toevoegen, en het loop-knooppunt opnieuw opbouwen.

Maar NIETS werkte.

De werkelijke oorzaak: een knooppunt dat er helemaal niets mee te maken had (de e-mailontwerper) had twee verbindingen met verschillende outputs (READ en ACTION_REPLY) van de classificator, maar de verbindingslijnen overlappen elkaar perfect in het canvas, waardoor het lijkt alsof het één verbinding is. Deze onzichtbare dubbele verbinding zorgde voor een ongeldige workflowstatus. Ik denk niet dat de classificator-bouwsteen de enige is die dit probleem veroorzaakt.

Geleerde les: als je cryptische, ongedefinieerde fouten krijgt in N8N, controleer dan op overlappende verbindingslijnen. Selecteer verdachte knooppunten en inspecteer hun verbindingen.

Wat ook echt kan helpen, is de workflow exporteren in JSON-formaat om alle verbindingen expliciet te zien. N8N mist momenteel validatie voor deze randgevallen en waarschuwt je niet voor ongeldige verbindingsstatussen. Exporteren naar JSON en het laten analyseren door bijvoorbeeld Claude of ChatGPT levert vaak niets op, maar soms leidt het tot de waardevolle inzichten waarnaar je op zoek was.

Wat ook echt kan helpen, zijn de N8N-logs. Klik op ‘executions’ en je ziet elke run, hoe die is verlopen en vaak ook waar het misgaat.

Dit is ook de reden waarom ik besloot de hele loop-functie te verwijderen.

Ik heb uiteindelijk de hele loop verwijderd omdat deze niet langer nodig was na het verwerken van alle e-mails. Ik besloot om de flow gewoon aan te roepen voor elke e-mail die binnenkwam.

De fout: Probleem bij het uitvoeren van de workflow: De uitdrukking is geëvalueerd als een falsy-waarde: a.ok(from)

Deze fout verschijnt soms constant (ja, je leest het goed) tijdens het testen, vooral bij het testen van individuele knooppunten of vertakkingen, bij het opnieuw uitvoeren van delen van een workflow na het aanbrengen van wijzigingen, of wanneer knooppunten verwijzen naar gegevens van eerdere knooppunten die niet in deze testcyclus zijn uitgevoerd.

N8N probeert ALLE uitdrukkingen in een knooppunt te evalueren, zelfs als je één specifiek ding wilt testen. Als een knooppunt waarnaar wordt verwezen geen uitvoer heeft geproduceerd in de huidige testrun, retourneert de uitdrukking undefined → falsy-waarde → fout → de hele workflow wil opnieuw worden uitgevoerd vanaf het begin.

$json.From wanneer het invoerknooppunt nog niet is uitgevoerd, $(‘Some Node’).item.json.field wanneer ‘Some Node’ geen uitvoergegevens heeft, verwijzingen naar de lus-context buiten een actieve lus, het testen van een knooppunt in een vertakking die specifieke Switch-routering vereist.

1. Plaats mock-gegevens op upstream-knooppunten om hun output te simuleren
2. Voeg fallbacks toe aan expressies: {{ $json.From || ‘test@example.com’ }}
3. Koppel je test los van de volledige workflow om het testen te vergemakkelijken
4. Gebruik first() in plaats van item, zoals we eerder hebben besproken

Ik denk dat N8N zijn testomgeving zou kunnen verbeteren door echte dry runs toe te voegen, of door te testen met mock-data. Toekomstige verbeteringen in N8N zullen snellere ontwikkeling mogelijk maken, maar zullen ook helpen bij het oplossen van enkele van de fundamentele problemen die ten grondslag liggen aan dit soort kwesties.

Datumnotaties in IT-systemen zijn waardeloos. En het wordt er niet beter op als je AI gebruikt.

De belangrijkste vraag blijft: hoe goed is dit privacyvriendelijke AI-e-mailsysteem?

Kort gezegd: het is mijn tijdsinvestering van ongeveer 25 uur aan opzetten en leren zeker waard. Maar ik zal er wat dieper op ingaan.

Dezelfde e-mail, twee keer gescand, kan verschillende resultaten opleveren. Dat kun je niet uitschakelen of veranderen. Dat zal altijd zo zijn vanwege de manier waarop LLM-systemen werken. Soms kiest het taalmodel ervoor om de e-mail te archiveren. Soms besluit het dat dezelfde e-mail een antwoord nodig heeft.

Maar in ongeveer 80% van de gevallen maakt de LLM de juiste en dezelfde categorisering. Dat is geweldig. En vaak, wanneer het systeem moeite twijfelt, zouden beide opties redelijke oplossingen zijn geweest.

Het element ‘human in the loop’ blijft essentieel. Omdat ik kan zien hoe e-mails worden gecategoriseerd, kan ik het model ook trainen om het beter te doen en de algemene prestaties ervan monitoren.

• Vooraf opgestelde antwoorden met de juiste handtekening, in de juiste taal, waarbij de persoon bij zijn of haar juiste naam wordt aangesproken, allemaal automatisch en zonder CRM-integraties.
• Automatisch doorsturen van e-mails met facturen naar de juiste finance-collega.
• Automatische agendaplanning (tot nu toe beperkt getest).

De e-mailconcepten die het systeem schrijft, kunnen echter nooit zonder menselijke tussenkomst worden verzonden. De antwoorden zijn vaak vreselijk voor algemene vragen zoals “Wil je spreken op dit evenement?”. Maar zelfs als de concept-e-mails niet geweldig zijn, vormen ze wel een goed begin van het bericht.

Concepten zijn echt goed voor technische vragen in de support-inbox van Voys. Ik heb een kleine test gedaan en het resultaat was fantastisch. Ik heb wel een beetje valsgespeeld door mijn systeem te laten communiceren met de AI-chatbot die we hebben gebouwd voor onze Engelstalige helppagina’s, die supergoed presteert.

Dus hoe specifieker de vragen worden en hoe beter je kennisbank en AI-systemen zijn, hoe hoger de kwaliteit van de concepten zal zijn.

Als ik de prestaties van dit systeem vergelijk met iets als Claude, dan is de kloof tussen open-sourcemodellen en commerciële varianten nog steeds groter dan ik had verwacht.

Ik gebruik Claude nu al meer dan een jaar en heb het verbeterd met geheugen, MCP’s en andere slimme integraties, die ik ook gebruik om code te schrijven. Daardoor weet ik goed hoe ik met Claude als assistent kan samenwerken.

De systemen die ik in N8N heb gebouwd zijn kwetsbaar en hebben veel bijsturing nodig. Ik weet dat dit inherent is aan taalmodellen, maar ik had op iets anders gehoopt. Ik hoopte dat kleinere, efficiëntere open-sourcemodellen zouden kunnen draaien zonder veel energie of rekenkracht te verbruiken, terwijl ze toch uitstekende prestaties leveren. Maar we behalen redelijke prestaties, wat voorlopig goed genoeg is.

Je merkt ook dat de markt nog steeds in een zeer actieve ontwikkelingsfase zit. Veel van de concepten die ik in dit artikel heb besproken, zijn nog erg nieuw. Het aanroepen van tools is bijvoorbeeld pas in de afgelopen één of twee jaar in deze modellen geïntegreerd. Het is dan ook niet vreemd dat de prestaties teleurstellend kunnen zijn als je ze gebruikt.

Het is goed om te beseffen dat we werken op het snijvlak van wat technologie kan. Om Kevin Kelly, oprichter van Wired, te citeren: “You have to find the edges to see where the center is moving.”

Die visie vind ik waardevol. Als je, net als ik, nu kunt beginnen met het experimenteren met en implementeren van AI-automatisering, zullen delen van wat je bouwt leiden tot voordelen waar je wat aan hebt: effectiever werken en veel minder saai werk doen.

Hetzelfde zie ik bij Voys: experimenteren met AI helpt ons om op verantwoorde wijze te innoveren, zo verbeteren we ons product en onze features, terwijl mijn collega’s de controle behouden. Zo versterkt AI zinvol menselijk werk in plaats van dat het collega’s vervangt.

Op dit moment is mijn inbox voor het eerst in vijf jaar leeg, wat op de een of andere manier voelde alsof er een last van mijn schouders viel. Dat maakt mijn investering van 25 uur meer dan de moeite waard.