Ik check het zoals de meeste mensen hun e-mail checken. Elke ochtend, voor het eerste telefoontje, voor ik de inbox open. Vijf kolommen: Wachtrij, Todo, In Progress, In Review, Done. De kaarten zijn voor de agents. 's Nachts pakken ze tickets uit de wachtrij, doen het werk en zetten de resultaten in Done, met een metric in de body. Mijn taak is die metric bekijken, beslissen of het erdoor mag of wordt afgewezen, en tickets die nog een ronde nodig hebben opnieuw indienen. Het scherm is een Linear-board, dezelfde soort takenlijst die softwareteams gebruiken. De werkers zijn AI-agents. Dat patroon heeft mijn ochtenden compleet veranderd.
Waarom ik stopte met chatten met agents
Voor de meeste mensen is de manier om een AI-agent te gebruiken in 2026 nog steeds een chatbox. Je typt een prompt, hij werkt een minuut of twee, jij leest het antwoord. Voor eenmalige vragen werkt dat formaat prima. Voor de rest van het werk is het het verkeerde formaat.
De rest van mijn werk verloopt in batches, staat ingepland en is klantspecifiek. "Verrijk deze 300 leads aan de hand van het ICP-profiel", de omschrijving van de ideale klant die we per opdrachtgever vastleggen. "Vernieuw het LinkedIn-signaal voor de 80 accounts die we volgen." "Herclassificeer de reacties op de campagne van gisteren." Niets daarvan past in een chat. Het past in een ticket. Een paar maanden geleden ben ik daarom gestopt met proberen chat hiervoor werkend te krijgen, en heb ik de vorm gebouwd die het werk allang had: een kanbanbord waarop tickets aan agents worden toegewezen in plaats van aan mensen.
De meeste artikelen zouden dit een "agent workflow" noemen. Die term dekt de lading niet. Een workflow suggereert lineaire automatisering van begin tot eind, die eenmalig draait. Ik wilde het omgekeerde: een wachtrij met kleine, afgebakende taken die elke agent kan oppakken, uitvoeren en teruggeven voor beoordeling. Het lijkt minder op Zapier met prompts en meer op een team dat tickets aanneemt.
De vorm, in één scherm
Het dashboard heeft dezelfde structuur als Linear, GitHub Projects, of elke kanbantool die je ooit hebt gebruikt.
- Wachtrij. Tickets die ik heb ingediend maar nog niet ingepland. Vaak zijn dit batchklussen die lang draaien en waar niemand op hoeft te wachten, of klussen die afhankelijk zijn van een eerder ticket dat eerst afgerond moet zijn.
- Todo. Tickets ingepland voor de volgende agent-run. De runtime pakt eerst uit deze kolom.
- In Progress. Een agent is begonnen, nog niet klaar. Ik kijk zelden naar deze kolom. Blijft een ticket hier hangen tot voorbij de maximale looptijd, dan beëindigt de runtime het.
- In Review. De agent beschouwt het werk als af. Het resultaat is bijgevoegd, met metrics. Wacht op mijn goedkeuring of terugkoppeling.
- Done. Goedgekeurd. De metric blijft bijgevoegd zodat ik runs in de loop van de tijd kan vergelijken.
Elk ticket heeft een projectcode. BUR voor BurnoutPoli, KSV voor KSV, enzovoort. Zelfde schema als Linear, zelfde hotkey-navigatie, zelfde drag-to-reorder. Die vertrouwdheid is de bedoeling: wie ooit een echte engineering-backlog heeft beheerd, kan hier zonder training mee werken. Het nieuwe onderdeel zijn de agents, de interface kende je al.
Hoe een typische ochtend eruitziet
Concreet voorbeeld van vanochtend. Ik opende het board en zag twee tickets in Done.
Het echte board, vanochtend. BUR-1 in Wachtrij, de twee KSV-tickets in Done met hun metrics erbij.
KSV-4, Leads aanvullen. Body zegt "Pipeline OK, +677 leads (totaal 677)." Vertaling: de agent heeft gescraped, gededupliceerd en 677 nieuwe prospects ingevoegd op basis van het KSV-ICP, inclusief dekkingscontroles. Ik tikte op de regel, keek naar de eerste tien leads en accepteerde. Verstreken tijd: 90 seconden.
KSV-3, Verrijking. Body zegt "Enrichment klaar, 94% tel dekking." Dezelfde leadset ging door de enrichment-pipeline. 94% kreeg een schone LinkedIn-match, een rol en een confidence-score op het contactgegeven. De overige 6% staat op een lijst die handmatige controle nodig heeft. Ik keurde de 94% goed, opende die lijst, markeerde de 18 regels die het waard waren om na te trekken en zette de rest weg als WONTFIX. Tijd: 4 minuten.
Daarna keek ik naar de Wachtrij. Eén ticket stond erin.
BUR-1, Leads aanvullen. Body zegt "Vind en verrijk 300 nieuwe leads op basis van ICP-profiel." Dit is de volgende batch voor BurnoutPoli. Ik verplaatste het van Wachtrij naar Todo, plande het voor vannacht en klapte de laptop dicht. Totale tijd op het board: 7 minuten. De runtime pakt het ticket om 02:00 op, draait ongeveer een uur, en morgenochtend ligt het resultaat klaar.
Dat is de loop. Het werk gebeurt 's nachts en ik beoordeel het 's ochtends; de rest van de dag houd ik over.
De drie dingen onder het board
Onder het dashboard zitten drie stukken infrastructuur waar het meeste bouwwerk in zat. Dit is het meest technische deel van het verhaal; wie alleen het patroon wil snappen, kan doorscrollen naar de verschuiving in denkmodel.
Runtimes
Een runtime is het onderdeel dat een ticket daadwerkelijk oppakt en uitvoert. Die van mij draaien in containers, zodat ik ze strikte resourcegrenzen en een harde maximale looptijd kan meegeven. Eén runtime per klant, met API-keys, databaseverbindingen en Slack-hooks die uitsluitend voor die klant gelden. Een ticket met het label BUR-1 kan niet per ongeluk naar de KSV-pipeline schrijven, want de runtime heeft daar geen credentials voor. Dat was vanaf dag één een harde regel. Eén fout die bij meerdere klanten tegelijk schade aanricht, in het vak cross-tenant blast radius genoemd, is het faalmechanisme dat platforms de das omdoet.
Skills
Een skill is een markdown-bestand met een gedefinieerd inputcontract, een gedefinieerd outputcontract en een voorbeeld. Het is de eenheid van herbruikbare expertise die een agent kan aanroepen. Voorbeelden uit mijn eigen set:
/find-by-icp.md, scrape en valideer prospects tegen een ICP-definitie. Input: ICP JSON. Output: leads-array./enrich-linkedin.md, neem een lead met e-mail en voeg rol, senioriteit, huidige werkgever en confidence toe. Input: leads-array. Output: leads-array met verrijkingsvelden./classify-reply.md, classificeer een binnenkomende campagnereactie als positief, ooo (out of office), neutraal, negatief./audit-account-roas.md, geef bij een MCC-account (het Google Ads-beheerdersaccount waar meerdere klantaccounts onder hangen) een ROAS-audit met drie gemarkeerde issues.
Tot nu toe zitten er ongeveer 40 skills in de collectie. Je kunt ze aan elkaar knopen: een ticket kan meerdere skills achter elkaar aanroepen, waarbij de output van de één de input voor de volgende wordt. De agent bepaalt die volgorde op basis van de ticketomschrijving. Een skill pas ik aan zodra de output niet meer bruikbaar is; dat is onderhoud aan de instructie, niet aan de code eronder.
Agents
Een agent is een geconfigureerde persona, een model en een toolset. Ik draai er drie. Een research-agent voor outbound en ICP-werk (Claude Sonnet, langere context, scraper-tools). Een maintenance-agent voor dagelijkse MCC- en pipelinechecks (Haiku, snel, geen scraper). En een QA-agent die de output van de andere twee leest en de samenvatting in In Review schrijft voordat ik hem zie. Van alle toevoegingen heeft die QA-agent het meeste verschil gemaakt. Markeert hij een run als "heeft menselijke aandacht nodig", dan vertrouw ik die markering. Blijft hij stil, dan vertrouw ik de run.
De verschuiving in denkmodel
Ik zag AI vroeger als iets waar ik dingen aan vroeg. Vraag erin, antwoord eruit, ik beoordeel het antwoord. Voor nieuwe vragen werkt dat. Voor terugkerend werk werkt het niet, omdat het formaat bij elke iteratie mijn aandacht opeist. Elke prompt die ik moet typen is aandacht die ik niet aan beoordelen besteed.
Datzelfde werk verplaatsen naar een ticketsysteem draaide die verhouding om. Nu besteedt de agent aandacht aan het werk en ik aan de beoordeling. Die twee gebeuren niet langer in dezelfde sessie. De agent kan om 02:00 draaien, falen, opnieuw proberen, slagen, en een samenvatting van 200 woorden achterlaten in Done. Ik lees de samenvatting, de trace laat ik liggen. Klopt de samenvatting en ligt de metric binnen bereik, dan keur ik goed. Wijkt een van de twee af, dan open ik het ticket en lees ik verder.
Naast elkaar gezet ziet die verschuiving er zo uit:
| Chatten met AI | Tickets toewijzen aan AI | |
|---|---|---|
| Wie start het werk | Jij, per prompt, elke keer opnieuw | Jij één keer, daarna de planner |
| Wanneer het gebeurt | Binnen kantooruren, terwijl jij wacht | 's Nachts, buiten je werkuren |
| Waar jouw aandacht heen gaat | Prompts formuleren en antwoorden lezen | Resultaten beoordelen |
| Wat er achterblijft | Een chatgeschiedenis | Een ticket met metric, vergelijkbaar per run |
| Volume, bij mij | Ongeveer 30 sessies per maand | 200 tot 300 tickets per maand |
Die laatste regel is het verschil dat telt. In een chat-first-maand draaide ik misschien 30 agent-sessies, allemaal binnen kantooruren, en die onderbraken stuk voor stuk ander werk. In een kanbanmaand draai ik 200 tot 300 tickets, het merendeel 's nachts, waarvan bijna geen enkele mijn werkuren raakt.
De eerlijke kosten
Drie afwegingen, zodat dit niet klinkt als een verkooppraatje.
- De eerste bouw is niet niks. Een werkende ticketloop is geen weekendklusje. Je hebt een wachtrij nodig, een runtime die eruit kan pakken, een skill-registry en gereedschap om te beoordelen. Ik heb flink beknibbeld op de vormgeving, maar nergens op isolatie en op de garantie dat dezelfde klus twee keer draaien nooit dubbele data oplevert (in het vak: idempotentie). Wat ik op vormgeving bespaarde, betaal ik sindsdien terug.
- De QA-laag maakt het pas bruikbaar. Zonder een agent die de output leest en samenvat voordat ik hem zie, groeit de stapel te beoordelen tickets sneller dan ik hem wegwerk. De helft van mijn vroege Done-kolom was "run afgerond, maar ik heb geen idee wat er eigenlijk gebeurd is". De QA-agent loste dat op. Hem er later bij zetten kostte drie keer zoveel moeite als wanneer ik dat meteen op dag één had gedaan.
- Niet elke klus past in een ticket. Alles waar ik zelf bij aanwezig moet zijn (een live advertentietekst-review, een gevoelig klantgesprek) komt niet op het board. Het board is voor batchwerk, gepland werk en terugkerend werk. Forceer je een live beslissing in een ticket, dan levert dat een Done-kolom vol halve beslissingen op die alsnog op mij wachten.
Wanneer een ticketloop loont, en wanneer een chatbox volstaat
Eerst een verwachting rechtzetten, want in Nederland denkt een groot deel van de beslissers bij "AI-agent" nog aan een chatbot op de website. Dit staat daar los van: het is intern gereedschap, geen kanaal richting je klanten. Je besteedt je eigen terugkerende werk uit aan software en controleert 's ochtends het resultaat.
Interessant is dit patroon nu vooral voor bedrijven en bureaus met terugkerend, afgebakend datawerk: leadlijsten aanvullen, rapportages draaien, accounts controleren, reacties classificeren, feeds opschonen. Werk dat elke week terugkomt en waarvan je vooraf kunt opschrijven wanneer het resultaat goed genoeg is. Heb je dat soort werk niet, of is vrijwel alles in je bedrijf maatwerk en live contact, dan levert een ticketloop je weinig op. Dan is een chatbox of een goede assistent gewoon de betere vorm. Daar komt bij dat veel Nederlandse bedrijven de basis nog missen waar agents op draaien: schone data, een fatsoenlijke API op de eigen systemen, gedocumenteerde processen. Zonder die basis automatiseer je vooral je eigen rommel.
De realistische eerste stap is dan ook geen bord bouwen. Houd twee weken bij welke taken steeds terugkomen, en of je per taak kunt formuleren wat het acceptatiecriterium is. Taken die dat halen zijn ticketkandidaten. Daarna hoef je nog steeds geen eigen platform te schrijven: een bestaand bord en één agent die op een vast tijdstip de bovenste kaart oppakt zijn genoeg om te testen of het patroon bij jouw werk past. Het bord is het makkelijke deel. De discipline om werk in afgebakende taken met een acceptatiecriterium te gieten is waar de winst zit.
Wat ik niet anders zou doen
Twee ontwerpkeuzes die belangrijker bleken dan ik destijds verwachtte.
Projectcodes per klant, vanaf dag één. De Linear-stijl code (BUR-1, KSV-3) betekent dat elk ticket een parseerbare eigenaar heeft. Dat gaat meetellen zodra je verder groeit dan twee klanten, want facturatie, kostentoewijzing en incidenttriage draaien allemaal op dat voorvoegsel. Per-klant-prefixen achteraf toevoegen aan een platte ticketpool is een migratie die ik nooit heb hoeven doen, en daar ben ik blij om.
Status is een eersteklas veld, geen tag. Een ticket heeft precies één status en er is geen ruimte voor twijfel. "In Review" is een kolom, geen vlag. De boardstatus komt exact overeen met de runtimestatus. Zodra je tickets in twee kolommen of in geen enkele kolom laat bestaan, herontdek je e-mailtriage, het probleem waar je juist vanaf wilde.
Waar ik uitkom
Het moeilijkste zat niet in de capaciteit van de agent; de agents zijn kant-en-klare modellen met redelijke prompts. Het moeilijkste was het werk zelf adresseerbaar maken. Elke klus moest een eigen adres krijgen: een ID, een omschrijving en een acceptatiecriterium. Pas toen kon een agent hem oppakken.
Voel jij dezelfde wrijving bij chat-gebaseerde agents, goede antwoorden die je dag niet veranderen, dan zit de winst in een wachtrij met status. Zodra het werk in tickets zit, wordt de agent goedkoper en gaat de beoordeling sneller. Je dag verschuift van het model managen naar de backlog managen, en dat laatste kun je waarschijnlijk allang.
Als je wilt sparren of dit patroon bij jouw stack past, stuur me een bericht. Mail naar info@jermayads.nl of gebruik jermayads.nl/contact.