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 niet voor mij. Ze 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 keer bekeken moeten worden 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. Dat formaat werkt prima voor eenmalige vragen. Het is het verkeerde formaat voor de rest van het werk.
De rest van mijn werk verloopt in batches, is 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. Dus een paar maanden geleden stopte ik met proberen om chat hiervoor te laten werken en bouwde ik meteen de vorm die het werk allang had: een kanbanbord waarop de tickets aan agents worden toegewezen in plaats van aan mensen.
Op dit punt zouden de meeste artikelen het een "agent workflow" noemen. Ik houd niet van die term. Een workflow impliceert lineaire, end-to-end automatisering die eenmalig draait. Wat ik eigenlijk wilde was het tegenovergestelde: een queue van kleine, individueel afgebakende taken die elke agent kan oppakken, uitvoeren, en teruggeven voor review. Minder "Zapier met prompts", meer "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 ik 's nachts wil draaien wanneer de kosten lager liggen, 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. Als een ticket hier langer dan een uur blijft staan, 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 precies de bedoeling. Wie ooit een echte engineering-backlog heeft beheerd, kan hier zonder training mee werken. De agents zijn het nieuwe onderdeel, niet de UI.
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, 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, rol, en e-mail confidence score. De overige 6% zitten in een needs-review bucket. Ik keurde de 94% goed, opende de needs-review bucket, markeerde de 18 die het waard waren om handmatig 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, stelde de planning in om vannacht te draaien, 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. Ik review 's ochtends. De rest van de dag is van mij.
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. Dit was vanaf dag één een harde regel: één fout die bij meerdere klanten tegelijk schade aanricht (in het vak heet dat cross-tenant blast radius) 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. Ze zijn composable: een ticket kan meerdere skills achter elkaar aanroepen, waarbij de output van de één de input voor de volgende wordt. De agent bepaalt de orkestratie op basis van de ticketomschrijving. Ik pas een skill aan wanneer de output niet meer bruikbaar is, niet wanneer het systeem stuk is.
Agents
Een agent is een geconfigureerde persona, model, en 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 pipeline-checks (Haiku, snel, geen scraper). Een QA-agent die de output van de andere twee leest en de samenvatting in In Review produceert voordat ik hem zie. Van alle toevoegingen heeft de QA-agent de meeste impact gehad. Als hij een run markeert als "heeft menselijke aandacht nodig", 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. Dat werkt voor nieuwe vragen. Het werkt niet voor terugkerend werk, omdat het formaat bij elke iteratie mijn aandacht verspilt. Elke prompt die ik moet typen is aandacht die ik niet besteed aan beoordeling.
Datzelfde werk verplaatsen naar een ticketsysteem draaide de asymmetrie om. Nu besteedt de agent aandacht aan het werk, en ik besteed aandacht aan review. De twee activiteiten vinden niet langer in dezelfde sessie plaats. De agent kan om 02:00 draaien, falen, opnieuw proberen, slagen, en een samenvatting van 200 woorden achterlaten in Done. Ik lees de samenvatting, niet de trace. Als de samenvatting logisch aanvoelt en de metric binnen bereik ligt, keur ik goed. Klopt een van de twee niet, 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 allemaal 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 initiële bouw is niet niks. Een werkende ticketloop is geen weekendklusje. Je hebt een queue nodig, een runtime die eruit kan pakken, een skill-registry, en review-tooling. Ik heb flink beknibbeld op visuals, 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 visuals heb bespaard, betaal ik sindsdien terug.
- De agent-QA-laag maakt het bruikbaar. Zonder een agent die de output leest en samenvat voordat ik hem zie, groeit de reviewqueue sneller dan ik kan bijhouden. 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. Een live beslissing in een ticket forceren levert alleen een Done-kolom vol halve beslissingen op, die alsnog op mij wachten.
Voor wie is dit nu interessant, en voor wie nog niet?
Eerst de verwachtingen recht zetten, want in Nederland denkt een groot deel van de beslissers bij "AI agent" nog aan een chatbot op de website. Dit is iets anders: geen kanaal richting je klanten, maar een manier om je eigen terugkerende werk uit te besteden aan software die je 's ochtends controleert.
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 en 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. Vervolgens hoef je geen eigen platform te schrijven: een bestaand bord en één agent die op een vast tijdstip de bovenste kaart oppakt is genoeg om te testen of het patroon bij jouw werk past. Het bord is de makkelijke helft; de discipline om werk in afgebakende taken met een acceptatiecriterium te gieten is de moeilijke helft, en precies daar zit de winst.
Wat ik niet anders zou doen
Twee ontwerpkeuzes die uiteindelijk 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 begint ertoe te doen 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, geen dubbelzinnigheid. "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, precies het probleem waar je vanaf wilde.
Waar ik uitkom
Het moeilijkste deel was niet de capaciteit van de agent. De agents zijn kant-en-klare modellen met redelijke prompts. Het moeilijkste deel was het werk zelf adresseerbaar maken. Elke klus moest een zelfstandig naamwoord worden met een ID, een body, en een acceptatiecriterium. Zodra het een zelfstandig naamwoord was, kon een agent het oppakken.
Als jij dezelfde wrijving voelt bij chat-gebaseerde agents (goede antwoorden, maar geen invloed op je dag), dan zit de oplossing niet in een geavanceerdere agent. De oplossing is een queue met status. Zodra het werk in tickets zit, wordt de agent goedkoper, gaat de review sneller, en verandert de vorm van je dag van "het model managen" naar "de backlog managen". Dat laatste kun je 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.