# Alejandro Rioja — NL > Alejandro Rioja — AI agent systems for founders. Plus posts on growth, marketing, sales, ops, and business from inside live P&Ls. Site: https://alejandrorioja.com/nl/ Author: Alejandro Rioja Language: nl --- ## AI-Agenten met Menselijke Controle: Wanneer een Goedkeuringspoort Bouwen (en Wanneer Niet) Source: https://alejandrorioja.com/nl/human-in-the-loop-ai-agents-when-to-build-an-approval-gate/ Published: 2026-07-23 Tags: AI Agents, Operations TL;DR: Een goedkeuringspoort heeft zin wanneer een fout duur, onomkeerbaar of klantgericht is — en wanneer een mens het op tijd kan opvangen. Het heeft geen zin wanneer het volume te hoog is om te beoordelen, de fout goedkoop te herstellen is, of mensen goedkeuren zonder te lezen. Ik gebruik vier vragen om te beslissen, en de meeste van mijn 30+ productie-agenten hebben helemaal geen goedkeuringspoort. ## Inhoudsopgave _Gepubliceerd juli 2026._ **TL;DR:** Een goedkeuringspoort heeft zin wanneer een fout duur, onomkeerbaar of klantgericht is — en wanneer een mens het op tijd kan opvangen. Het heeft geen zin wanneer het volume te hoog is om te beoordelen, fouten goedkoop te herstellen zijn, of mensen goedkeuren zonder te lezen. Ik gebruik vier vragen om te beslissen, en de meeste van mijn 30+ productie-agenten werken volledig geautomatiseerd. **Notitie van de operator:** Ik run agenten in twee bedrijven — een consultancymerk en Pickleland, een pickleballfaciliteit in Pflugerville, TX. Aanvankelijk zette ik overal goedkeuringspoorten neer omdat het "veilig" voelde. Binnen enkele weken had ik een Slack-kanaal vol notificaties die niemand las, en technisch gecontroleerde agenten die praktisch zonder toezicht waren. Dat is erger dan geen poort: de illusie van toezicht zonder de substantie. Dit artikel legt uit hoe ik nu over deze beslissing nadenk. ## Wat een menselijke toezichtpoort werkelijk is In zijn eenvoudigste vorm is een goedkeuringspoort een pauze in de workflow van een agent waar een mens moet bevestigen voordat de agent doorgaat. De agent stelt een e-mail op — een mens keurt het goed voor verzending. De agent markeert een transactie — een mens beoordeelt voordat de terugbetaling wordt verwerkt. De poort kan synchroon zijn (de agent blokkeert totdat iemand goedkeurt) of asynchroon (de agent zet de actie in een wachtrij, stuurt een notificatie, en een mens keurt goed vanuit een dashboard of Slack-bericht op eigen tempo). Asynchroon is bijna altijd beter voor alles wat niet tijdkritisch is, omdat synchrone poorten tegendraadse druk in de wachtrij creëren en de betrouwbaarheidsgaranties van de agent ondermijnen. Wat een poort niet is: een herhaallus, een betrouwbaarheidsdrempel of een terugval naar een eenvoudiger model. Dat zijn foutafhandelingsmechanismen binnen de agent. Een goedkeuringspoort gaat over menselijk oordeel dat de lus binnenkomt — bewust, op een specifiek punt, om een reden. ## De vier vragen die ik stel Voordat ik een poort toevoeg, loop ik vier vragen door. Een "ja" op een ervan is een signaal om er een te overwegen. Een "ja" op alle vier betekent dat de poort structureel noodzakelijk is. **1. Is de actie onomkeerbaar (of duur om terug te draaien)?** Een e-mail naar 10.000 mensen sturen kan niet ongedaan worden gemaakt. Een betaling indienen kan niet eenvoudig worden teruggeroepen. Een databaserecord verwijderen zonder back-up is permanent. Onomkeerbaarheid is het sterkste argument voor een poort, omdat de agent niet ongedaan kan maken wat hij heeft gedaan. Vergelijk dat met: een inkomende vraag voorzien van een categorie. Als het label verkeerd is, corrigeer je het in twee klikken. Geen poort nodig. **2. Als de agent het fout heeft, wie betaalt?** Een intern label verkeerd — ik besteed een paar seconden aan het corrigeren. Een klantgerichte e-mail verkeerd — de klant betaalt met een slechte ervaring, en ik betaal met een vertrouwensverlies. Een financiële transactie verkeerd — ik betaal met echt geld en mogelijk nalevingsrisico. Agenten die alleen interne systemen beïnvloeden, kunnen meer fouten tolereren zonder een poort. Agenten die klanten of geld aanraken, moeten het recht verdienen om onbeheerd te werken. **3. Kan een mens de fout echt opvangen voordat het ertoe doet?** Dit is de vraag die de meeste mensen overslaan, en het is degene die meer poorten elimineert dan welke andere ook. Als een agent 500 items per uur verwerkt en je een Slack-notificatie per item ontvangt, leest niemand alle 500. Je creëert alertmoeheid, geen toezicht. De rekensom is eenvoudig: een poort voegt alleen waarde toe als een mens het gemarkeerde item realistisch kan beoordelen binnen het beschikbare tijdvenster. **4. Lezen mensen betrouwbaar wat de agent presenteert?** Als je goedkeuringswachtrij zich vult en mensen goedkeuren zonder te lezen, is de poort erger dan geen poort — het creëert vals vertrouwen dat een mens het werk heeft gecontroleerd. ## Wanneer poorten duidelijk zinvol zijn Dit zijn de patronen waarbij ik altijd een poort toevoeg, zonder uitzonderingen: - **Onomkeerbare externe communicatie** — e-mails, sms'jes, sociale mediaberichten naar echte mensen. De agent stelt op; een mens verzendt. Afhankelijk van het volume. - **Financiële acties boven een drempel** — alles wat geld beweegt krijgt een poort als het boven een euro-minimum ligt dat ik per context instel. - **Nieuwe patronen die de agent nog niet heeft gezien** — als de classifier van de agent iets markeert als "onbekend" of buiten zijn trainingsdistributie, is dat een gedwongen escalatie. - **Nalevingsgevoelige uitvoer** — alles wat HIPAA, PCI, juridische kennisgevingen of gereguleerde financiële inhoud aanraakt, wordt beoordeeld door een persoon. ## Wanneer poorten het product stil saboteren Dit zijn de patronen waarbij een poort veilig lijkt maar adoptie stil breekt: - **Hoog-volume, omkeerbare operaties** — als je het in twee klikken ongedaan kunt maken en het 200 keer per dag gebeurt, wint beoordelingsmoeheid. - **Tijdkritische workflows** — een agent die in 30 seconden reageert op inkomende klantvragen zou geen synchrone poort moeten hebben. - **Taken waarbij de mens minder context heeft dan de agent** — als de agent 50 pagina's context heeft gelezen voor een classificatie en de beoordelaar een samenvatting van één regel krijgt, is de beoordeling theater. - **Interne verrijking en labeling** — CRM-records taggen, uitgaven categoriseren, vergadernotities samenvatten. De inzet rechtvaardigt de onderbreking niet. ## De drie poortpatronen die ik daadwerkelijk implementeer Wanneer een poort gerechtvaardigd is, kies ik een van drie implementaties: **1. Asynchrone goedkeuring via Slack/e-mail** De agent voltooit zijn concept, plaatst een bericht in een aangewezen Slack-kanaal met de voorgestelde actie en een goedkeuren/afwijzen-knop, en pauzeert. Ik gebruik Cloudflare Queues om de hangende actie vast te houden, en een aparte Worker die luistert naar de goedkeuringswebhook voordat hij hervat. Werkt goed voor: e-mailconcepten, sociale media-inhoud, significante CRM-updates. **2. Op betrouwbaarheid gebaseerde escalatie** De agent draait volledig geautomatiseerd voor hoog-betrouwbare uitvoer (zeg, ≥0,85 betrouwbaarheid op een gestructureerd schema) en stuurt laag-betrouwbare items door naar een menselijke wachtrij. Werkt goed voor: classificatie, routing, triage. **3. Dashboard-beoordeling met batch-goedkeuring** In plaats van een poort per item, komen alle agentuitvoeren in een beoordelingsdashboard terecht. Een mens beoordeelt in batch — bijvoorbeeld elke ochtend — en keurt in groepen goed of corrigeert. Werkt goed voor: inhoudsgeneratie, rapportopstelling, geplande samenvattingen. ## De alertmoeheidsval Elke poort die je toevoegt is een permanente belasting op iemands aandacht. Het risico is niet alleen dat één poort wordt genegeerd — het is dat drie poorten een lawaaierig Slack-kanaal creëren dat mensen traint om alle notificaties te negeren. De discipline die ik heb opgebouwd: elke poort heeft een expliciete eigenaar en een expliciete SLA. Als niemand consistent binnen de SLA beoordeelt, wordt de poort verwijderd en vervangen door een audittrail. Ik doe maandelijkse audits van alle goedkeuringswachtrijen. ## Verbinding met agentbetrouwbaarheid Een poort is één laag van een betrouwbaarheidsstack, niet de hele stack. Mijn volledige betrouwbaarheidsstack voor een productieagent: 1. **Eval-harnas** — bevestigt correcte uitvoer voor implementatie. 2. **Gestructureerde uitvoer met schemavalidatie** — de uitvoer van de agent is beperkt tot een getypeerd schema. 3. **Betrouwbaarheidsdrempel** — laag-betrouwbare uitvoer gaat naar menselijke beoordeling. 4. **Auditlog** — elke actie van de agent wordt geregistreerd. 5. **Menselijke goedkeuringspoort** — alleen voor acties waarbij het bovenstaande niet voldoende is. ## Mijn vuistregel Als ik niet zou willen dat een junior medewerker dit zonder overleg met mij doet, heeft de agent een poort nodig. Als ik een junior medewerker het zonder nadenken zou laten doen, moet de agent onbeheerd werken. ## FAQ ### Hoe ga ik om met een agent die goedkeuring nodig heeft maar hoog-volume draait? Verander de architectuur: eis geen goedkeuring per item — eis goedkeuring per patroon. Laat de agent draaien, maar laat hem statistische anomalieën presenteren voor menselijke beoordeling. ### Wat als een fout ernstige schade kan veroorzaken maar ik me geen volledige menselijke beoordeling kan veroorloven? Dat is meestal een signaal om de agent voor die actie nog niet in te zetten. Als je [Claude](/recommends/claude) als modellaag gebruikt, maken de tool-use-patronen van de Anthropic SDK het gemakkelijk om een "escaleer"-tool te definiëren die de agent kan aanroepen wanneer hij vertrouwen mist. --- ## Claude Tool Use: Zo Geef Ik Mijn AI-Agents Echte Mogelijkheden Source: https://alejandrorioja.com/nl/claude-tool-use-production-agents/ Published: 2026-07-21 Tags: AI Agents, Claude TL;DR: Claude tool use laat uw agent acties ondernemen — niet alleen tekst genereren. U definieert tools als JSON-schema's, Claude beslist wanneer ze worden aangeroepen, en uw code voert de echte actie uit. De lus heeft drie stappen: stuur bericht → ontvang tool_use-blok → voer uit en stuur resultaat terug. Ik heb dit geïmplementeerd in 15+ productie-agents op Cloudflare Workers. Het faalpatroon ligt bijna nooit bij de AI — het zijn onduidelijke tool-resultaten die terugkomen. ## Inhoudsopgave _Bijgewerkt juli 2026._ **TL;DR:** Claude tool use laat uw agent acties ondernemen — niet alleen tekst genereren. U definieert tools als JSON-schema's, Claude beslist wanneer ze worden aangeroepen, en uw code voert de echte actie uit. De lus heeft drie stappen: stuur bericht → ontvang tool_use-blok → voer uit en stuur resultaat terug. Ik heb dit geïmplementeerd in 15+ productie-agents op Cloudflare Workers. Het faalpatroon ligt bijna nooit bij de AI — het zijn onduidelijke tool-resultaten die terugkomen. **[Operatorperspectief]** Ik beheer 30+ productie-AI-agents verspreid over een consultancymerk en Pickleland, een pickleballaccommodatie in Pflugerville, TX. Ongeveer de helft gebruikt tool use — de Claude API-functie die het model in staat stelt functies aan te roepen die uw code definieert. Dit is het patroon waar ik op ben uitgekomen na implementeren en itereren in productie. ## Waarom tool use verandert wat een agent kan doen Zonder tools kan een agent alleen tekst genereren. Dat is nuttig voor samenvattingen, opstellen en classificeren — maar dat is niet wat de meeste bedrijfsautomatiseringen echt nodig hebben. Bedrijfsautomatiseringen moeten informatie opzoeken, naar databases schrijven, API's aanroepen, berichten sturen. Tool use is hoe u Claude die toegang geeft. U definieert een set tools als JSON-schema's. Claude leest de schema's, beslist welke tool aan te roepen en met welke argumenten, en geeft een gestructureerd `tool_use`-inhoudsblok terug. Uw code voert de eigenlijke functie uit. Claude krijgt het resultaat en beslist wat er daarna moet gebeuren — inclusief het aanroepen van een andere tool of het produceren van een definitief tekstantwoord. De sleutel: **Claude beslist wanneer en of een tool wordt aangeroepen.** U definieert de mogelijkheden. Het model redeneert over wanneer ze te gebruiken. ## Hoe de API-stroom werkt De tool use-lus heeft drie stappen. U doorloopt deze lus één of meerdere keren afhankelijk van hoeveel tool-aanroepen het model maakt. **Stap 1: Stuur uw bericht met gedefinieerde tools** ```typescript const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 1024, tools: [ { name: "check_court_availability", description: "Check if a court is available at a given date, time, and duration", input_schema: { type: "object", properties: { date: { type: "string", description: "Date in YYYY-MM-DD format", }, time: { type: "string", description: "Start time in HH:MM format (24h)", }, duration_minutes: { type: "number", description: "Duration of the booking in minutes", }, }, required: ["date", "time", "duration_minutes"], }, }, ], messages: [ { role: "user", content: "Is a court available tomorrow at 2pm for 90 minutes?", }, ], }); ``` **Stap 2: Controleer of Claude een tool wil aanroepen** ```typescript if (response.stop_reason === "tool_use") { const toolUseBlock = response.content.find( (block): block is Anthropic.ToolUseBlock => block.type === "tool_use" ); if (!toolUseBlock) throw new Error("Expected tool_use block"); // Run your actual function const toolResult = await checkCourtAvailability( toolUseBlock.input as CourtAvailabilityInput ); // Step 3: Return the result to Claude const finalResponse = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 1024, tools: [ /* same tools as before */ ], messages: [ { role: "user", content: "Is a court available tomorrow at 2pm for 90 minutes?", }, { role: "assistant", content: response.content }, { role: "user", content: [ { type: "tool_result", tool_use_id: toolUseBlock.id, content: JSON.stringify(toolResult), }, ], }, ], }); // finalResponse.content now has the text answer } ``` Dat is het volledige patroon. Drie API-interacties per tool-aanroep: tools definiëren → `tool_use`-blok ontvangen → resultaat teruggeven. ## Echt voorbeeld: de Pickleland beschikbaarheidscontrole Pickleland is een pickleballaccommodatie. We ontvangen boekingsverzoeken op Facebook Messenger, in reacties en via een chatbot. De vraag is bijna altijd een variatie van "zijn jullie zaterdag om 15:00 open?" of "kan ik een baan boeken voor mijn groep van 8 personen?" De beschikbaarheidscontroler-agent gebruikt tool use om het echte boekingssysteem in real-time te raadplegen in plaats van een standaardantwoord te geven. Hier is de volledige agent — vereenvoudigd maar productiegetrouw: ```typescript // workers/availability-checker.ts import Anthropic from "@anthropic-ai/sdk"; const anthropic = new Anthropic(); const AVAILABILITY_TOOLS: Anthropic.Tool[] = [ { name: "check_availability", description: "Check court availability for a date, time, and group size. Returns available courts and their prices.", input_schema: { type: "object", properties: { date: { type: "string", description: "YYYY-MM-DD" }, start_time: { type: "string", description: "HH:MM (24h)" }, duration_minutes: { type: "number" }, players: { type: "number", description: "Number of players" }, }, required: ["date", "start_time", "duration_minutes"], }, }, { name: "get_pricing", description: "Get current pricing for court rentals and open play sessions", input_schema: { type: "object", properties: { session_type: { type: "string", enum: ["court_rental", "open_play", "clinics"], }, }, required: ["session_type"], }, }, ]; export async function handleInquiry( userMessage: string, env: Env ): Promise { const messages: Anthropic.MessageParam[] = [ { role: "user", content: userMessage }, ]; // Agentic loop — keep going until stop_reason is "end_turn" while (true) { const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 512, system: "You are the booking assistant for Pickleland, a pickleball facility in Pflugerville, TX. " + "Use the tools to look up real availability and pricing. Never make up availability or prices. " + "If the customer wants to book, direct them to pickleland.com/book.", tools: AVAILABILITY_TOOLS, messages, }); // Push the assistant's response into message history messages.push({ role: "assistant", content: response.content }); if (response.stop_reason === "end_turn") { const textBlock = response.content.find( (b): b is Anthropic.TextBlock => b.type === "text" ); return ( textBlock?.text ?? "I wasn't able to answer that — please call us directly." ); } if (response.stop_reason === "tool_use") { // Process ALL tool calls in this response (Claude can request multiple at once) const toolResults: Anthropic.ToolResultBlockParam[] = []; for (const block of response.content) { if (block.type !== "tool_use") continue; let result: unknown; switch (block.name) { case "check_availability": result = await checkAvailability( block.input as AvailabilityInput, env ); break; case "get_pricing": result = await getPricing(block.input as PricingInput, env); break; default: result = { error: `Unknown tool: ${block.name}` }; } toolResults.push({ type: "tool_result", tool_use_id: block.id, content: JSON.stringify(result), }); } // Return all tool results in a single user message messages.push({ role: "user", content: toolResults }); } } } ``` Twee dingen om hier te noemen. **De agentische lus.** Ik ga door tot `stop_reason === "end_turn"`. Claude kan `check_availability` aanroepen, beslissen dat het ook de prijs nodig heeft, `get_pricing` aanroepen, en dan het definitieve antwoord produceren — dat zijn drie API-aanroepen voor één gebruikersbericht. De lus handelt dit af zonder speciale logica. **Meerdere tool-aanroepen per beurt.** Claude kan meerdere `tool_use`-blokken in één enkel antwoord retourneren. Ik verwerk ze allemaal en geef alle resultaten terug in één enkel `user`-bericht. Als u ze één voor één verwerkt en individueel terugstuurt, onderbreekt u de gespreksstroom en verspilt u tokens. ## Echt voorbeeld: de lead-onderzoeksagent Mijn consultancymerk gebruikt een onderzoeksagent die inkomende leads verrijkt voordat ik met ze praat. Wanneer iemand het contactformulier invult, onderzoekt de agent het bedrijf en extraheert wat ik moet weten voor het gesprek. De tooldefinities hiervoor bevatten een schrijftool — en hier wordt het patroon interessant: ```typescript const RESEARCH_TOOLS: Anthropic.Tool[] = [ { name: "search_company", description: "Search for information about a company", input_schema: { type: "object", properties: { company_name: { type: "string" }, website: { type: "string", description: "Company website if known" }, }, required: ["company_name"], }, }, { name: "save_research", description: "Save the completed research summary to Airtable. Call this when all research is complete.", input_schema: { type: "object", properties: { company_summary: { type: "string" }, estimated_size: { type: "string", enum: ["1-10", "11-50", "51-200", "200+"], }, likely_use_case: { type: "string" }, priority: { type: "string", enum: ["high", "medium", "low"] }, notes: { type: "string" }, }, required: [ "company_summary", "estimated_size", "likely_use_case", "priority", ], }, }, ]; ``` `save_research` is wat ik een **schrijftool** noem — het doel is niet informatie ophalen, maar de output van Claude in gestructureerde vorm in een database vastleggen. Ik gebruik dit patroon in plaats van te proberen JSON te parsen uit een tekstantwoord. Claude weet wanneer het onderzoek klaar is en roept `save_research` aan met correct getypeerde velden. Ik schrijf nooit een parser. Dit is de schoonste toepassing van tool use: definieer een tool voor een "definitieve actie" met het exacte schema dat u wilt, en Claude levert gestructureerde output via de tool-aanroep. Geen tekstparsing, geen regex, geen JSONSchema-validatie van vrije tekstoutput. ## Één tool vs. meerdere Het instinct bij het starten met tool use is een grote tool te bouwen die alles doet. Weersta dit. Kleine, gefocuste tools zijn beter om drie redenen: 1. **Claude redeneert beter over kleine tools.** Een tool genaamd `get_court_status` die beschikbaarheid retourneert is gemakkelijker voor het model te verwerken dan een tool genaamd `manage_facility` die een `mode`-parameter neemt en intern aftakt. 2. **Kleine tools zijn makkelijker te testen.** Elke tool is een TypeScript-functie die u onafhankelijk van de LLM unit kunt testen. Dat moet u doen — tool-bugs zijn moeilijk te debuggen in een live gesprek. 3. **Claude kan kleine tools parallelliseren.** Als twee tools niet van elkaar afhankelijk zijn, kan Claude ze in hetzelfde antwoord aanroepen en verwerkt u ze parallel. Dit werkt alleen als de tools echt onafhankelijk zijn. De uitzondering: tools die toegang nodig hebben tot veel gedeelde interne state. Als de functie 10 variabelen van dezelfde gegevensbron nodig heeft, klopt één tool met een rijker schema beter dan 10 tools die elk afzonderlijk de database benaderen. Mijn vuistregel: begin met één tool per afzonderlijke mogelijkheid. Voeg tools samen alleen wanneer u ziet dat Claude ze bij elk verzoek samen aanroept. ## Kostenimplicaties Tool use voegt tokens toe. Elke tooldefinitie gaat in de systeempromptcontext. Elk `tool_use`- en `tool_result`-blok verbruikt tokens in de gespreksgeschiedenis. Voor een agentische multi-beurt-lus stapelt dit snel op. Voor de Pickleland beschikbaarheidscontrole voert een typisch gesprek in totaal 3–4 API-aanroepen uit (initieel bericht + 1–2 tool-aanroepen + eindantwoord), elk met 600–900 tokens. Tegen Haiku-prijzen kost dit minder dan $0,001 per verzoek. Zoals ik uitleg in [de post over AI-agenten kostenberekening](/ai-agent-cost-math-when-haiku-beats-sonnet/), verwerkt Haiku goed gedefinieerde tool-aanroepopdrachten betrouwbaar en is het 10× goedkoper dan Sonnet voor hetzelfde tokenvolume. De lead-onderzoeksagent draait op Sonnet omdat de beoordelingsbeslissingen — een lead prioriteren, fit inschatten — meer redeneerkapaciteit vereisen dan Haiku betrouwbaar levert op open invoer. De berekening werkt nog steeds omdat het zelden wordt uitgevoerd (een paar keer per week, niet duizenden per dag). De modelkeuze volgt de taakcomplexiteit, niet persoonlijke voorkeur. ## Het faalpatroon waar niemand over spreekt Het meest voorkomende faalpatroon dat ik zie bij tool use in productie is niet Claude die de verkeerde tool aanroept. Het is de tool die iets teruggeeft waar Claude niet duidelijk over kan redeneren. Als uw tool een ruwe database-object met 40 velden teruggeeft, raakt Claude in de war over welke velden belangrijk zijn. Als uw tool een uitzondering gooit (die verschijnt als een Worker-crash in plaats van een tool-resultaat), breekt de lus stil af. Als uw tool `null` retourneert wanneer het "geen resultaten" bedoelt, weet Claude niet of het opnieuw moet proberen of opgeven. Drie regels voor tool-resultaten: **Geef compacte, expliciete resultaten terug.** `{ available: true, courts: ["Court 3", "Court 5"], price_per_hour: 20 }` — niet de volledige databaserij. **Vang fouten op binnen de tool-functie en geef ze terug als gestructureerde resultaten.** `{ error: "booking system timeout", retry: true }` — geen gegooide uitzondering die de Worker laat crashen. **Maak "geen resultaten" expliciet.** `{ available: false, next_available: "2026-07-23T14:00:00Z" }` — niet `null` of een lege array zonder context. Claude redeneert veel beter over duidelijke signalen dan over onduidelijke retourwaarden. Elk uur dat ik heb besteed aan het debuggen van tool use in productie ging over onduidelijke resultaten, niet over het redeneren van het model. ## De conclusie van de operator Tool use is de functie die Claude transformeert van een tekstgenerator in een operator. Definieer gefocuste tools met duidelijke invoerschema's. Verwerk alle `tool_use`-blokken in één enkel antwoord aan het model. Voer de agentische lus uit totdat `stop_reason === "end_turn"`. Geef schone, compacte resultaten terug van uw tool-functies — geen ruwe data-objecten, geen gegooide uitzonderingen, geen onduidelijke nulls. Het model handelt het redeneren af. Uw code handelt de echte acties af. Houd die twee taken duidelijk gescheiden en de architectuur blijft onderhoudbaar zelfs als u tools toevoegt. Als u uw eerste tool use-agent bouwt, begin dan met het bovenstaande patroon van de beschikbaarheidscontrole — één tool, één doel, één agentische lus. Zet dat in productie. Voeg dan de tweede tool toe. --- **Gerelateerd:** [De agent-stack die ik gebruik om 30+ productie-agents te draaien](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) · [Haiku vs Sonnet: de kostenberekening voor agent-taken](/ai-agent-cost-math-when-haiku-beats-sonnet/) · [Event-getriggerde vs geplande agents: welk patroon voor welke taak](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) **Bouwt u een tool use-agent en loopt u vast?** [Neem contact op](/contact/) — ik ontwerp en bouw productie-agentarchitecturen voor operatorteams. ## FAQ ### Werkt Claude tool use met alle modellen? Ja — tool use wordt ondersteund door alle huidige Claude-modellen. [Claude](/recommends/claude) Haiku verwerkt goed gedefinieerde tools met duidelijke schema's betrouwbaar en is de goedkoopste optie voor taaktypen met hoog volume. Sonnet verwerkt meer ambigue of open tool-aanroepbeslissingen beter. Begin met Haiku; ga hoger als de outputkwaliteit onvoldoende is. ### Wat is het verschil tussen Claude tool use en OpenAI function calling? Mechanisch identiek. OpenAI bedacht "function calling"; Anthropic noemt het "tool use". In beide gevallen: u definieert JSON-schema's, het model geeft gestructureerde aanroepen terug, uw code voert de functie uit. De API-vorm verschilt maar het concept is hetzelfde. ### Kan Claude meerdere tools aanroepen in één enkel antwoord? Ja. Claude kan meerdere `tool_use`-blokken in één enkel `assistant`-antwoord retourneren. Verwerk ze allemaal en geef alle resultaten terug in één enkel `user`-bericht. Zie het agentische luspatroon in het Pickleland-voorbeeld hierboven — de `for`-lus over `response.content` handelt dit correct af. ### Hoeveel tools moet ik definiëren per agent? Ik blijf onder 8–10 tools per agent. Daarboven heb ik Claude soms de verkeerde tool zien kiezen bij de eerste poging, wat tokens verspilt in een correctielus. Als u meer dan 10 mogelijkheden nodig heeft, splits de agent in meerdere agents met gespecialiseerde toolsets in plaats van één agent te bouwen die alles weet. ### Moet ik tool use gebruiken voor gestructureerde output? Ja — het `save_research`-schrijftool-patroon is schoner dan Claude te vragen JSON in een tekstblok te retourneren en dat vervolgens te parsen. Definieer een tool voor een "definitieve actie" met het exacte schema dat u wilt. Claude roept het aan met correct getypeerde velden wanneer het klaar is. Geen parser nodig. --- ## Hoe Zoekmachines Contentkwaliteit Daadwerkelijk Beoordelen in 2026 Source: https://alejandrorioja.com/nl/how-search-engines-evaluate-content-quality/ Published: 2026-07-20 Tags: SEO, GEO ## Inhoudsopgave _Gepubliceerd juli 2026._ **TL;DR:** Zoekmachines en AI-engines zijn allebei gestopt met het scoren van pagina's in isolatie. Ze scoren sites — diepgang in de dekking van een onderwerp, vertrouwenssignalen die kritische blik doorstaan, en consistentie over maanden, niet één geweldig artikel. Ik run 384 Engelstalige posts vertaald naar 13 talen en volg wekelijks of ik geciteerd word door ChatGPT, Perplexity en Google AI Overviews. Het patroon is consistent: geïsoleerde posts stagneren, clusters stapelen zich op, en de vertrouwenssignalen die citatiepercentages beïnvloeden zijn saai, structureel en goedkoop om te bouwen. **Blik van de operator:** Ik theoretiseer niet over contentkwaliteit — ik run de content-engine voor deze site en zie wat er gebeurt met citatiepercentages als ik iets verander. Deze post is volledig opgebouwd uit dingen die ik gemeten heb op alejandrorioja.com: echte clustergroottes, een echt zes weken durend citatie-experiment, echte schema-markup-tests. Niets hierin is een gok over hoe algoritmes "waarschijnlijk" werken. ## Kwaliteit stopte al een tijdje geleden een per-pagina-vraag te zijn Het mentale model dat de meeste mensen nog steeds aanhouden is: schrijf een goed artikel, het rankt. Dat was nooit volledig waar, en het is nu actief misleidend voor alles behalve een smalle long-tail term. Ik heb een directe manier om dit op mijn eigen site te zien. Ik publiceer binnen een handvol echte clusters — een cluster van 29 posts over AI-agents en Claude, een "Hoe Verdient X Geld"-cluster met verdienmodel-uitleg die inmiddels 20 posts telt (Google, OpenAI, Anthropic, Uber, Salesforce, en meer), en een groot SEO/GEO-cluster dat het grootste losstaande onderwerp op de site is qua aantal tags. Een op zichzelf staande post over een onderwerp dat ik maar één keer heb aangeraakt, gedraagt zich compleet anders dan een post die binnen een van deze clusters zit, zelfs wanneer het losse stuk objectief beter geschreven is. De geclusterde posts worden vaker geciteerd, ranken stabieler en herstellen sneller na een algoritme-update. De geïsoleerde posts pieken of niet, en als ze dat niet doen, is er geen omringende autoriteit om op terug te vallen. Dat is het echte mechanisme achter wat vaak wordt verkocht als een [AI-topical-authority-strategie](https://www.linkbuildinghq.com/blog/how-to-build-topical-authority-for-ai/) — geen mystieke vertrouwensscore, maar het simpele feit dat een pagina die naast 28 andere pagina's over hetzelfde onderwerp staat, zowel de crawler van Google als de retrieval-stap van een LLM meer onderbouwende context geeft om op te leunen. Ik heb bewust [de volledige mechaniek van die structuur](/pillar-content/) uitgeschreven — de korte versie is dat een cluster alleen werkt als elke post erin naar de pillar linkt en de pillar terug linkt, zodat de thematische kaart expliciet is in plaats van iets wat de crawler zelf moet reconstrueren. De praktische test die ik toepas voordat ik iets nieuws publiceer: verlengt deze post een cluster die ik al bezit, of start hij iets losstaands? Losstaande posts zijn niet verboden — sommige zoekopdrachten hebben oprecht maar één pagina nodig — maar ik weet vooraf dat een losstaande post alleen concurreert op paginaniveau-signalen, zonder het cumulatieve effect dat een clusterpost gratis krijgt. ## "Echte waarde, geen opvulling" is een testbare claim, geen gevoel De generieke versie van dit advies zegt "voeg diepgang en context toe, herhaal geen algemeen beschikbare informatie". Waar, maar nutteloos zonder een manier om het te controleren. Hier is mijn echte test, gedraaid op echte schaal: ik heb 384 Engelstalige posts. Elke post wordt vertaald naar 12 andere talen door [een agent die ik precies daarvoor gebouwd heb](/how-to-translate-one-blog-post-into-13-languages-with-one-agent/). Vertalen is goedkoop — de hele achterstand van 341 posts kostte ongeveer $1,70 aan API-calls op Haiku. Schrijven is dat niet. Als ik volume kon opvullen door hetzelfde idee licht herschreven in tien verschillende framings te presenteren, zou die agent me duplicatie net zo makkelijk laten opschalen als vertaling. Dat doe ik niet, omdat gedupliceerde framing de echte test niet doorstaat: beantwoordt deze pagina een vraag die geen andere pagina op mijn site al even goed of beter beantwoordt? Dat is het filter dat er meer toe doet dan welke stijlrichtlijn dan ook. "Opvulling" is geen toonprobleem, het is een redundantieprobleem — een pagina die een naburige pagina herhaalt zonder een nieuwe invalshoek, cijfer of voorbeeld toe te voegen. Ik controleer dit vóór publicatie door te vragen of de nieuwe post de citaties van een bestaande post zou kannibaliseren in plaats van nieuw citatie-oppervlak toe te voegen. Als twee posts op mijn site dezelfde zoekopdracht even goed zouden beantwoorden, is een van de twee opvulling, hoe goed die ook geschreven is. ## Vertrouwenssignalen die ik daadwerkelijk gebouwd en gemeten heb "Betrouwbaarheid" is de vaagste term in elk generiek SEO-artikel, meestal gevolgd door een lijstje als "citeer bronnen, toon expertise, houd dingen accuraat" zonder enige manier om te verifiëren of dat ook maar iets heeft bewogen. De concrete versie die ik run: schema-markup, omdat dit het enige vertrouwenssignaal is dat een AI-engine mechanisch verwerkt in plaats van af te leiden. Ik heb [de volledige implementatie](/schema-markup-for-geo/) elders uitgewerkt en ben dieper ingegaan op [welke types daadwerkelijk lonen](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/). De korte versie: `Article`/`BlogPosting` met een echte, met naam genoemde auteur en een eerlijke `dateModified` is het auteurschapsanker; `FAQPage` en `HowTo` zijn de types met de hoogste impact omdat ze het model een vooraf beantwoorde vraag of een vooraf gestructureerde procedure aanreiken in plaats van het model die uit proza te laten afleiden; `Person`- en `Organization`-schema bestaan zodat het model mij niet verwart met iemand anders die mijn naam deelt. Niets hiervan is abstract voor mij — het is de interventie achter een echt resultaat. Het toepassen van een vierdelige structurele overlay (TL;DR-blok, genummerde stappen, FAQ-sectie, primaire-bron-citaties) op 41 pillar-posts die al Google AI Overviews triggerden, bracht de citatiefrequentie van 4 van de 41 naar 19 van de 41 over zes weken — [de volledige zes weken durende test staat hier uitgeschreven](/google-ai-overview-citation-case-study/). Dat is geen "voeg vertrouwenssignalen toe en hoop maar". Dat is een gemeten voor/na op mijn eigen pagina's, met de kanttekening die de post zelf duidelijk vermeldt: het werkte alleen op pagina's die al de autoriteitsbodem hadden van organisch top-5 ranken. Structuur versterkt een bestaand signaal; het fabriceert er geen uit het niets. ## Consistentie stapelt zich op, maar "consistentie" betekent geen constante updates De generieke claim hier is meestal "actualiteit is belangrijk maar niet elk artikel hoeft geüpdatet te worden", gesteld zonder enige echte cadans eraan gekoppeld. Hier is de mijne. Ik raak de meeste posts na publicatie niet meer aan. Ik onderhoud wel een doorlopende set pillar-posts en update ze elke 6-12 maanden wanneer de onderliggende feiten veranderen — er verschijnt een nieuw model, de prijs van een tool verandert, een statistiek wordt verouderd. `dateModified` verandert alleen wanneer de content daadwerkelijk verandert; ik heb getest of het faken daarvan werkt, en dat doet het niet — engines doorzien een opgeschoven datum zonder inhoudelijke bewerking, precies wat de AI Overview-casestudy ook vond. Het consistentiesignaal dat ik daadwerkelijk wekelijks in de gaten houd is niet publicatiecadans, maar citatiedekking: ik draai wekelijks een bijgehouden lijst met bedrijfskritische zoekopdrachten door ChatGPT, Perplexity en Google en log of ik geciteerd word — [de methodologie staat hier](/how-to-measure-ai-search-traffic/). Citatiedekking is een voorlopende indicator — hij beweegt voordat verwijzingsverkeer of merkzoek-stijging dat doen, dus het is het getal dat me vertelt of een cluster daadwerkelijk autoriteit opbouwt over tijd of gewoon stilstaat. Een site die één keer publiceert en dan stil wordt, krijgt geen tweede blik van die wekelijkse check; een site die een cluster blijft uitbreiden wel. ## Wat "sitebrede" beoordeling daadwerkelijk beloont, laag voor laag De drie engines die ik volg wegen niet dezelfde signalen identiek. Dit is de praktische tabel die ik in mijn hoofd houd bij het beslissen waar ik inspanning in investeer: | Kwaliteitslaag | Hoe dit er in de praktijk daadwerkelijk uitziet | Waar ik het gemeten heb | | --- | --- | --- | | Thematische diepgang | 20-30+ onderling gelinkte posts over één onderwerp, pillar die naar elke clusterpost linkt en terug | AI Agents-cluster (29 posts), "Hoe Verdient X Geld"-cluster (20 posts) | | Structurele extraheerbaarheid | TL;DR-blok, genummerde stappen, FAQ, afgestemd op echte gebruikersformuleringen | 4/41 → 19/41 AI Overview-citaties in 6 weken | | Auteurschap/vertrouwen | Met naam genoemde auteur + accurate `dateModified` + Person/Organization-schema | Schema-markup voor GEO, uitsplitsing van schematypes | | Consistentie over tijd | Wekelijkse citatietracking over engines heen, geen constante herschrijvingen | Methodologie voor AI-zoekmeting | De faalmodus die ik het vaakst zie in generiek advies is het behandelen van deze lagen als één ongedifferentieerde "kwaliteits"-score. Dat zijn ze niet. Een pagina kan uitblinken in structurele extraheerbaarheid en toch verliezen van een concurrent met meer thematische diepgang. Een pagina kan binnen een diep cluster zitten en toch een specifieke citatie verliezen aan een frissere concurrent met beter schema. Weten welke laag daadwerkelijk het knelpunt is voor een gegeven pagina is het grootste deel van het werk. ## Waar dit misgaat — de eerlijke kanttekeningen Ik markeer liever de grenzen dan het patroon te overdrijven: - **Domeinautoriteit is nog steeds een poort.** De AI Overview-interventie werkte alleen op pagina's die al organisch top-5 rankten. Structuur versterkte een bestaand signaal; het creëerde geen autoriteit vanaf een koude pagina. - **Engines lopen uiteen in wat ze belonen.** Toen ik dezelfde 50 head-terms door ChatGPT en Google draaide, vond ik slechts ongeveer 40% overlap in welke bronnen geciteerd werden — [volledige uitsplitsing hier](/chatgpt-search-vs-google-50-term-test/). Optimaliseren voor "zoekmachines" als één doelwit is al het verkeerde frame; je optimaliseert voor meerdere engines die het eens zijn over de basis en uiteenlopen over de rest. - **Sommige categorieën hebben oprecht geen cluster nodig.** Een handvol van mijn best presterende pagina's zijn echte losstaande stukken. Diepgang is een hefboom, geen universele vereiste — een cluster forceren waar de zoekruimte er geen ondersteunt, produceert precies de dunne, opgevulde content die het hele framework juist zou moeten vermijden. ## FAQ ### Kan één uitstekend artikel ooit een middelmatig cluster overtreffen? Ja, voor een voldoende smalle zoekopdracht met lage concurrentie. Maar voor elke head-term met echte concurrentie zijn de pagina's die hun positie op lange termijn behouden vrijwel altijd ondersteund door een cluster. Ik heb geïsoleerde posts zien pieken en wegzakken op een manier die geclusterde posts niet doen. ### Hoeveel posts heeft een onderwerp nodig voordat het als een echt cluster telt? Er is geen hard getal, maar in mijn eigen data wordt het effect duidelijk zichtbaar ergens rond de 8-10 werkelijk verschillende posts over subonderwerpen van hetzelfde thema — genoeg zodat de pillar zinvol naar buiten kan linken en elke clusterpost ergens specifieks heeft om lezers naartoe te sturen die meer diepgang nodig hebben. ### Is schema-markup echt noodzakelijk, of is goed schrijven genoeg? Goed schrijven is noodzakelijk maar niet voldoende specifiek voor citatie door AI-engines. Engines halen gestructureerde feiten betrouwbaarder uit `FAQPage`- en `HowTo`-schema dan uit puur proza, omdat het schema de afleidingsstap wegneemt. Ik heb citatiestijgingen gemeten van enkele tot midden-tiental procentpunten door het toe te voegen aan posts die voorheen schemaloos waren. ### Hoe vaak moet ik oude content updaten in plaats van nieuwe posts te publiceren? Ik update pillar-posts elke 6-12 maanden wanneer een echt feit verandert, en ik schuif `dateModified` nooit op zonder inhoudelijke bewerking. Het grootste deel van mijn contentbudget gaat naar nieuwe, cluster-uitbreidende posts, niet naar herschrijvingen — actualiteit is belangrijk, maar het is niet de dominante hefboom vergeleken met thematische diepgang en structuur. ### Wat is het ene aanpassing met de hoogste hefboomwerking om als eerste te fixen? Als een pagina al redelijk goed organisch rankt maar niet geciteerd wordt door AI-engines, voeg dan een schoon TL;DR-blok toe dat de head-zoekopdracht direct beantwoordt. In mijn eigen zes weken durende test was dat verreweg de grootste hefboom — groter dan FAQ-schema, groter dan primaire-bron-citaties, groter dan genummerde stappen. ## De conclusie Beoordeling van contentkwaliteit verschoof van de pagina naar de site, en de sitebrede signalen die daadwerkelijk het verschil maken zijn meetbaar, niet mystiek: clusterdiepgang die je kunt tellen, structurele overlays die je A/B kunt testen, schema dat je kunt valideren, en een citatiedekking-getal dat je wekelijks kunt bijhouden. Niets daarvan vereist raden wat een algoritme "wil". Het vereist publiceren binnen een echte thematische structuur, engines een schoon, extraheerbaar antwoord geven in plaats van ze er een te laten afleiden, en het resultaat vaak genoeg controleren om te weten of het werkt. Ik run al deze vier disciplines op deze site elke week, en de cijfers hierboven zijn wat ze daadwerkelijk hebben opgeleverd — niet wat een generieke gids beweert dat ze zouden moeten opleveren. --- ## Claude vs ChatGPT voor Bedrijven in 2026: Een Eerlijke Kijk van een Operator Source: https://alejandrorioja.com/nl/claude-vs-chatgpt-for-business-2026/ Published: 2026-07-18 Tags: AI Agents, Productivity TL;DR: Claude wint bij het bouwen van agents, werk met lange contexten, coderen en alles wat op schaal in productie draait. ChatGPT wint bij consumentenintegraties, spraakmodus en het bredere plugin-ecosysteem als jouw workflow in de chatinterface leeft. Als je geautomatiseerde workflows of AI-agents bouwt, is Claude het betere fundament. Als je een capabele chatassistent met meer verbindingen van derden wilt, heeft ChatGPT de voordeel. Voor de meeste ondernemers is de echte vraag: chat je met AI of bouw je met AI? Dat antwoord bepaalt het hulpmiddel. ## Inhoudsopgave _Gepubliceerd juli 2026._ **TL;DR:** Claude wint bij het bouwen van agents, werk met lange contexten, coderen en alles wat op schaal in productie draait. ChatGPT wint bij consumentenintegraties, spraakmodus en het bredere plugin-ecosysteem als jouw workflow in de chatinterface leeft. Als je geautomatiseerde workflows of AI-agents bouwt, is Claude het betere fundament. Als je een capabele chatassistent met meer verbindingen van derden wilt, heeft ChatGPT de voordeel. Voor de meeste ondernemers is de echte vraag: chat je met AI of bouw je met AI? Dat antwoord bepaalt het hulpmiddel. **[Perspectief van de operator]** Ik beheer twee bedrijven — een consultingmerk en Pickleland, een pickleballfaciliteit in Pflugerville, TX — met meer dan 30 AI-agents in productie die reacties op sociale media, eventpromotie, boekingsopvolging, nieuwsbriefconcepten en meer beheren. Mijn volledige agentstack is gebouwd op [Claude](/recommends/claude). Ik heb ook ChatGPT genoeg gebruikt om te weten waar elk hulpmiddel faalt. Dit is geen benchmarkreview. Het is het perspectief van een beoefenaar. ## De vraag die er echt toe doet De meeste vergelijkingen vragen: "Welk model is slimmer?" Dat is de verkeerde vraag voor zakelijk gebruik. De juiste vraag is: **wat bouw je en wat moet het betrouwbaar op schaal doen?** Een marketingmanager die wil dat AI helpt bij het opstellen van teksten heeft andere vereisten dan een oprichter die een geautomatiseerde leadkwalificatiepipeline bouwt. Een solopreneur die AI gebruikt om zich voor te bereiden op vergaderingen heeft andere behoeften dan een operator die agents bouwt die 500 klantverzoeken per week verwerken. Het hulpmiddel dat voor één wint, is vaak het verkeerde voor de ander. Dat kader bepaalt alles wat volgt. ## Waar Claude wint ### 1. Werk met lange contexten Het native contextvenster van Claude — 200K tokens — verwerkt dingen die andere modellen doen crashen. Ik geef regelmatig volledige klantgespreksgeschiedenissen, hele contractconcepten of meerdocumentonderzoekssamenvattingen aan Claude en vraag het te synthetiseren of kruisverwijzingen te maken. Het houdt de draad vast. Concurrerende modellen ondersteunen technisch lange contexten nu, maar de praktische degradatie bij complexe taken is nog steeds slechter dan die van Claude. Voor zakelijke taken waarbij het lezen van lange documenten, het analyseren van dichte data-exports of het handhaven van coherentie in lange workflows betrokken is, heeft Claude een echte voorsprong. ### 2. Agentgedrag in productie Wanneer je Claude als agent uitvoert — tools aanroepen, beslissingen nemen in een lus, schrijven naar databases, fouten afhandelen — gedraagt het zich consistenter dan ChatGPT in mijn ervaring. Het volgt systeem-promptinstructies betrouwbaarder, produceert gestructureerde output die gemakkelijker te parsen is en heeft minder kans om af te dwalen van de taak wanneer de context langer wordt. Dit is enorm belangrijk voor agents. Een model dat jouw systeemprompt 95% van de tijd volgt versus 99% van de tijd klinkt vergelijkbaar. Bij 500 aanroepen per dag zijn dat 25 afwijkingsgevallen per dag om op te sporen en op te ruimen. Het artikel dat ik schreef over [hoe AI-agentsysteemprompts te schrijven die niet falen in productie](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/) behandelt dit in detail, maar de korte versie is: de instructienaleving van Claude op systeempromptniveau is de beste die ik heb getest. ### 3. Coderen en technisch werk Ik bouw bijna alles in TypeScript op Cloudflare Workers. Claude Code is mijn dagelijkse ontwikkeltool — en het is echt nuttig in plaats van alleen "goed genoeg". Voor architectuurvragen, debuggen, refactoring en het schrijven van agentlogica van nul overtreft Claude consequent wat ik heb gebruikt op het equivalent van ChatGPT. Dit is niet slechts een vergelijking van Claude Code versus ChatGPT Chat. Zelfs ruwe Claude Opus 4.8 via de API schrijft schonere code met minder gehallucineeerde imports dan het GPT-4o-equivalent op dezelfde taken. ### 4. Ontwikkelaarservaring op de API Als je bouwt met de API — niet alleen chatten — is de ontwikkelaarservaring van Claude beter in 2026. De Anthropic SDK is schoon, het tokentellingseindpunt is echt nuttig voor kostenscatting, promptcaching is goed geïmplementeerd en bespaart echt geld op herhaalde contexten, en de foutafhandeling is voorspelbaar. Voor iedereen die programmatisch agents bouwt, doet het API-kwaliteitsverschil er toe. Het is niet groot, maar het is consistent. ### 5. Instructietrouw bij complexe prompts Claude verwerkt genuanceerde systeemprompts met meerdere condities beter dan ChatGPT. Wanneer ik een agent nodig heb die een reeks regels volgt — "als de reactie een vraag is, doe X; als het een klacht is, doe Y; als het concurrenten noemt, markeer het voor menselijke beoordeling" — analyseert en past Claude die vertakkingen consistenter toe. Voor eenvoudige prompts is het verschil minimaal. Voor complexe voorwaardelijke logica ingebed in een systeemprompt is Claude betrouwbaarder. ## Waar ChatGPT wint ### 1. Consumentenintegraties en plugins Het plugin-ecosysteem van ChatGPT en het aanbod van tools via de native interface zijn breder. Als jouw workflow al leeft in tools die native ChatGPT-integraties hebben — bepaalde CRM's, productiviteitsapps, onderzoekstools — en je werkt voornamelijk via een chatinterface, besparen de out-of-the-box verbindingen van ChatGPT wrijving. Voor gevorderde gebruikers die alles vanuit de chat-UI willen doen zonder aangepaste integraties te bouwen, telt dit. ### 2. Spraakmodus De Advanced Voice Mode van ChatGPT is echt uitstekend. Voor mobiel gebruik, ideeën mondeling uitwerken of telefoongesprekken voorbereiden tijdens het rijden, is het de beste spraak-AI-interface die ik heb gebruikt. Claude heeft spraakinvoer maar niets vergelijkbaar met de volledige conversationele spraakmodus van GPT-4o medio 2026. Als spraak een primaire interface is voor jouw gebruiksscenario, wint ChatGPT duidelijk. ### 3. Beeldgeneratie (via DALL-E) ChatGPT Plus bevat beeldgeneratie via DALL-E in hetzelfde abonnement. Claude genereert native geen afbeeldingen. Als je één tool wilt voor tekst- en beeldwerk zonder Midjourney of een andere service toe te voegen, heeft ChatGPT een voordeel. ### 4. Bekendheid en adoptie Meer mensen hebben ChatGPT gebruikt. Als je AI-tools introduceert bij een team zonder AI-ervaring, heeft beginnen met ChatGPT minder weerstand — de meeste mensen hebben het minstens één keer geopend. Dat is geen capaciteitsvoordeel, maar inwerksnelheid is een echte operationele factor. ## Kostenvergelijking Dit is waar dingen genuanceerd worden, en waar de meeste vergelijkingen misleiden. Beide platforms hebben gelaagde prijzen. Op API-niveau: - **Claude Haiku 4.5** en **GPT-4o mini** zijn de goedkope werkpaarden voor eenvoudige taken met hoog volume. Ze zijn vergelijkbaar in prijsbereik, waarbij de keuze voornamelijk wordt bepaald door taakvereisten. - **Claude Sonnet/Opus** en **GPT-4o** zijn het midden tot hogere segment. Claude heeft [promptcaching](/prompt-caching-cut-your-claude-costs-without-switching-models/) dat de kosten aanzienlijk verlaagt bij workflows met herhaalde context — als jouw agents dezelfde systeemprompt en hetzelfde contextvenster hergebruiken bij aanroepen, kan de gecachede prijs van Claude 50–80% goedkoper zijn dan het niet-gecachede tarief. ChatGPT heeft geen direct equivalent. - Op het hoogste niveau bevinden Claude Fable 5 en de nieuwste GPT-4-varianten zich in dezelfde ruwe kostenklasse, maar het tokenizerverschil telt — Fable 5 heeft een tokenizer die tokens anders telt dan eerdere modellen, dus referentietokenaantallen vertalen niet direct. Conclusie over kosten: **voor productieagents met hoog aanroepvolume maakt het promptcaching van Claude het materieel goedkoper** bij workloads die context hergebruiken. Voor puur pay-per-call op verse contexten zijn ze dicht genoeg bij elkaar dat prestaties de keuze moeten bepalen, niet de lijstprijs. Het kader dat ik gebruik om dit te evalueren, staat in het [artikel over AI-agentkosten wiskunde](/ai-agent-cost-math-when-haiku-beats-sonnet/). ## De beslissingsmatrix | Gebruiksscenario | Winnaar | |---|---| | AI-agents bouwen in productie | Claude | | Complex coderen en architectuur | Claude | | Documentanalyse met lange context | Claude | | Chatassistent met pluginintegraties | ChatGPT | | Workflows met spraak als primaire interface | ChatGPT | | Afbeeldingen + tekst in één interface | ChatGPT | | API-gestuurde automatisering op schaal | Claude | | Teaminwerkprogramma zonder AI-ervaring | ChatGPT | | Klantgerichte agents in productie | Claude | | Kostenefficiëntie bij hoog-volume pipelines | Claude (met caching) | ## Mijn echte antwoord Ik gebruik [Claude](/recommends/claude) voor alles in productie. Niet omdat het elke benchmark wint — dat doet het niet — maar omdat: 1. Mijn agents de systeemprominstructies betrouwbaar genoeg volgen dat ik bijna geen tijd besteed aan het opruimen van gehallucineeerde of taakloze outputs. 2. De Cloudflare Workers + Claude API-stack kost minder dan $100/maand voor mijn gecombineerde workload, en promptcaching heeft de kosten op mijn zwaarste workflows met meer dan de helft verminderd. 3. Claude Code is mijn primaire codeerinterface geworden, en hetzelfde model beschikbaar hebben voor zowel ontwikkeling als productie vereenvoudigt het mentale model. 4. Voor taken met lange context — PDF's lezen, synthetiseren over documenten, coherentie handhaven in meerstappen workflows — verwerkt Claude het volledige 200K-venster beter dan ik elders heb ervaren. Als ik een team zou leiden dat AI-ondersteunde tools nodig heeft zonder aangepaste infrastructuur te bouwen, zou ik ze waarschijnlijk op ChatGPT Plus zetten — de out-of-the-box pluginbreedte en spraakmodus zijn echt nuttig op consumentenniveau. Maar voor het bouwen van dingen in plaats van ze alleen te gebruiken, is Claude het juiste fundament. ## Veelgestelde vragen ### Is Claude slimmer dan ChatGPT? Geen van beide is universeel slimmer. Claude is beter bij redeneren met lange contexten, instructienaleving en coderen. ChatGPT (GPT-4o) is beter bij multimodale taken met afbeeldingen en spraak. Specifieke benchmarks wisselen tussen hen bij elke modelrelease. De nuttigere vraag is welk model beter is voor jouw specifieke taak. ### Kan ik zowel Claude als ChatGPT gebruiken? Ja, en voor sommige workflows wil je dat misschien. De Claude API en de OpenAI API zijn beide eenvoudig te integreren. Sommige teams gebruiken Claude voor agent-backends en ChatGPT voor gebruikersgerichte chatinterfaces met integraties. Dat gezegd hebbende, twee AI-providers draaien voegt operationele complexiteit toe — referentiebeheer, kostenbewaking, gedragsverschillen om te beheren. Begin met één. ### Welke is beter voor contentschrijven? Claude, naar mijn ervaring. Het produceert output die minder generiek klinkt, handhaaft een specifieke stijl beter wanneer voorbeelden worden gegeven en verwerkt langformige inhoud coherenter. Voor korte sociale content of e-mails waar elk werkt, is het verschil klein. ### Heeft Claude een gratis laag? Ja — Claude.ai heeft een gratis laag met berichtlimieten. [Claude Pro en Max-abonnementen](/recommends/claude) verwijderen limieten en voegen prioriteitstoegang, bestandsuploads en het volledige contextvenster toe. ChatGPT heeft ook een gratis laag met gebruiksbeperkt GPT-4o-toegang. ### Moet ik overstappen van ChatGPT naar Claude? Als je AI voornamelijk gebruikt als chatinterface en tevreden bent met ChatGPT, is de overstapkosten misschien niet de moeite waard tenzij je een specifieke behoefte hebt die Claude beter vervult. Als je automatiseringen, agents of coderingswerk bouwt, zou ik sterk aanraden Claude te proberen — het agentgedrag en de ontwikkelaarservaring maken een significant verschil voor productie-workloads. --- ## Hoe je een geproductiseerde dienst opbouwt: mijn framework voor het omzetten van expertise in schaalbare inkomsten Source: https://alejandrorioja.com/nl/productized-service-how-to-package-your-expertise/ Published: 2026-07-16 Tags: Entrepreneurship, Marketing TL;DR: Een geproductiseerde dienst is een aanbieding met vaste scope en vaste prijs die je elke keer op dezelfde manier levert. Vier stappen: vind het werk waarvoor klanten je al herhaaldelijk inhuren, definieer de scopegrenzen hard, stel de prijs in op basis van de resultaatwaarde (niet uren), en bouw het leveringssysteem voordat je aan de volgende klant verkoopt. De meeste consultants slaan stap vier over en zitten vast met het ruilen van tijd voor geld. Dat is de enige stap die echt schaal creëert. ## Inhoudsopgave _Gepubliceerd in juli 2026._ **TL;DR:** Een geproductiseerde dienst is een aanbieding met vaste scope en vaste prijs die je elke keer op dezelfde manier levert. Vier stappen: vind het werk waarvoor klanten je al herhaaldelijk inhuren, definieer de scopegrenzen hard, stel de prijs in op basis van de resultaatwaarde (niet uren), en bouw het leveringssysteem voordat je aan de volgende klant verkoopt. De meeste consultants slaan stap vier over en zitten vast met het ruilen van tijd voor geld. Dat is de enige stap die echt schaal creëert. **[Noot van de operator]** Ik bracht jaren door met het uitvoeren van maatwerk consultancyopdrachten — elke met een andere scope, een andere prijs, een andere levering. Het resultaat was een bedrijf dat mijn directe aandacht vereiste bij elk project. Productisering heeft dat veranderd: mijn meest gevraagde werk omzetten in gedefinieerde aanbiedingen met duidelijke deliverables, vaste prijzen en een herhaalbaar leveringshandboek. Hier is het exacte framework en de fouten die ik maakte bij het opbouwen ervan. ## Wat een geproductiseerde dienst werkelijk is Een geproductiseerde dienst is geen retainer. Het is geen abonnement. Het is een gedefinieerde, herhaalbare aanbieding met een vaste scope, een vaste prijs en een leveringsproces dat goed genoeg gedocumenteerd is om elke keer op dezelfde manier te werken. Het contrast met maatwerk consultancy: in plaats van "we doen AI-automatiseringsstrategie voor $X–Y afhankelijk van de scope," verkoop je "een AI-automatiseringsroadmap: een schriftelijke audit van 5 workflows, geprioritiseerde build-aanbevelingen en een 30-minuten leveringsgesprek, voor €2.500." Scope vast. Prijs vast. Tijdlijn vast. De enige variabele is of de klant ja zegt. Het verschil met een retainer is dat het projectgebaseerd is. Duidelijk begin. Duidelijk einde. Geen open maandelijkse facturering, geen scopedrift, geen "kun je ook even naar dit kijken?" gesprekken achteraf. Wat het schaalbaar maakt: het systeem, niet de aanbieding. Een vaste-prijs-aanbieding is alleen herbeprijs maatwerk. Een geproductiseerde dienst heeft een leveringshandboek erachter. ## Stap 1: Vind waarvoor klanten je al inhuren De makkelijkste geproductiseerde dienst om te bouwen is de dienst die je al herhaaldelijk levert maar elke keer behandelt als maatwerk. Kijk terug op je laatste 10–15 klanten of projecten en zoek naar patronen: - Welk probleem komt het meest voor? - Welke deliverable produceer je het vaakst? - Welk type opdracht verloopt het soepelst en krijgt de beste klantfeedback? Voor mij was het patroon duidelijk: klanten bleven om hetzelfde vragen — hulp bij het in kaart brengen van hun processen, kiezen welke te automatiseren en de juiste tools selecteren. Ik deed het herhaaldelijk maar met een andere scope elke keer. Dat patroon is je startpunt. Niet een nieuwe dienst waarvan je denkt dat de markt hem nodig heeft. Wat je al doet. Een filter: productiseer alleen werk waarbij de output grotendeels hetzelfde is voor alle klanten. Als elke klant een compleet andere deliverable krijgt, is het werk nog niet productiseerbaar — het is nog echt maatwerk. Dat is goed; het betekent alleen dat het definitiewerk eerst komt. ## Stap 2: Definieer de scopegrenzen — en houd je eraan Hier gaat de meeste consultants mis. Ze definiëren de aanbieding vaag, laten de scope open voor interpretatie en belanden in dezelfde scope-drift-gesprekken als voorheen. Een geproductiseerde dienst vereist harde scopegrenzen. Je definieert wat inbegrepen is en wat niet, schriftelijk, voor het eerste verkoopgesprek. Voorbeeldscopedefinitie voor een AI-automatiseringsstrategie sprint: **Inbegrepen:** - 60 minuten gestructureerd intakegesprek - Schriftelijke audit van maximaal 5 workflows - Geprioritiseerde automatiseringsroadmap met tool-aanbevelingen - Build-vs.-koop-beoordeling voor de top-3 kandidaten - 30 minuten leveringsoverzichtsgesprek **Niet inbegrepen:** - Implementatie (bouwen van agenten of integraties) - Revisies na levering - Meer dan 5 workflows - Werk buiten de overeengekomen automatiseringsscope De "niet inbegrepen"-lijst is net zo belangrijk als de "inbegrepen"-lijst. Wanneer een klant iets vraagt buiten de grenzen, heb je twee keuzes: zeggen dat het buiten deze aanbieding valt, of een scoped add-on maken met eigen prijs. Wat je niet doet, is het absorberen. Dit voelt aanvankelijk ongemakkelijk. Je bent gewend om ja te zeggen om klanten tevreden te houden. Productisering vereist "dat is een apart project" te zeggen — en dat consequent te menen. ## Stap 3: Stel de prijs in op basis van resultaatwaarde, niet je uren Uurfacturering en geproductiseerde diensten gaan niet samen. Op het moment dat je begint te berekenen op basis van je tijd, heb je het weer maatwerk gemaakt. Drie variabelen om een geproductiseerde aanbieding te beprijzen: 1. **De kosten van de klant om het probleem niet op te lossen.** Een AI-automatiseringsroadmap die €4.000/maand aan operationele efficiëntie vrijmaakt, is duizenden waard voor de koper. Je 8 uur werk is het verkeerde prijsanker. 2. **Wat kopers uitgeven aan vergelijkbare resultaten.** Niet wat concurrenten rekenen — wat klanten daadwerkelijk uitgeven aan vergelijkbare resultaten van consultants, fractioneel executives of software die het probleem gedeeltelijk oplost. Dit stelt je plafond vast. 3. **Je minimale vloer.** Wat moet je verdienen aan deze aanbieding zodat het je aandacht waard is, rekening houdend met levertijd, klantbeheer en overhead? Dit stelt je vloer vast. Stel je prijs in die range. Voor vroege geproductiseerde aanbiedingen, begin in het midden. Naarmate je getuigenissen verzamelt en de leveringssnelheid verfijnt, beweeg je naar het plafond. Geen kortingen. Als iemand de aanbieding niet kan betalen, is hij niet de juiste klant ervoor. Je kunt een goedkopere aanbieding bouwen voor een ander segment — maar verdun de primaire aanbieding niet met ad-hoc kortingen, anders ben je terug bij maatwerk-pricing. ## Stap 4: Bouw het leveringssysteem voor de volgende verkoop Deze stap bepaalt of je een geproductiseerde dienst hebt of slechts een vaste-prijs-opdracht. Na je eerste levering — voor je aan de volgende verkoopt — doe dit: 1. **Documenteer elke stap in volgorde.** Geen vaag overzicht. Een checklist gedetailleerd genoeg zodat iemand bekend met het domein 80% van het proces ervan kan uitvoeren. Ik bewaar deze in [Notion](/recommends/notion) — één pagina per workflowstap, met sjablonen, voorbeeldoutputs en beslisbomen voor de lastige oordelen. 2. **Identificeer wat langer duurde dan het zou moeten.** Elke eerste levering is trager dan nodig. Vind de knelpunten en systematiseer ze: intake-formulieren, deliverable-sjablonen, voorgebouwde frameworks. 3. **Bouw het gestructureerde intakeproces.** Het verkrijgen van de informatie van de klant in een gestandaardiseerd formulier voor het gesprek is wat de levering voorspelbaar maakt. Het gesprek is voor verduidelijkingsvragen, niet informatieverzameling. 4. **Maak het deliverable-sjabloon.** Elke klant krijgt dezelfde outputstructuur. Inhoud varieert; structuur niet. Dit maakt de levering snel en de output consistent en professioneel elke keer. Als je deze stap overslaat en gewoon de volgende verkoopt, doe je nog steeds maatwerk — je hebt het alleen een vaste prijs gegeven. Het systeem is wat het werkelijk schaalbaar maakt. ## Wat productisering werkelijk ontsluit Het belangrijkste voordeel is niet hogere inkomsten. Het is betere inkomsten: voorspelbare vraag, snellere levering, minder onderhandelingsgesprekken en de mogelijkheid om nee te zeggen tegen klanten die iets buiten de aanbieding willen. Een tweede voordeel: de leveringsdocumentatie wordt intellectueel eigendom. Het handboek dat je bouwt voor een geproductiseerde consultancyaanbieding is het grootste deel van de inhoud voor een cursus of trainingsprogramma. Ik deed dit met AI-automatiseringsconsultancy — het leveringshandboek werd direct de curriculumruggegraat van mijn AI Agents for Beginners-cursus. Een derde voordeel: hefboom. Met een gedocumenteerd systeem kun je iemand trainen om delen van de levering uit te voeren — de audit, het onderzoek, het opstellen van documenten — terwijl jij je concentreert op intake- en leveringsgesprekken. Dat is het begin van afstappen van de één-op-één tijd-voor-geld loopband. ## De tools die ik gebruik voor het beheren van geproductiseerde aanbiedingen **[Airtable](/recommends/airtable)** — één rij per klantopdracht, met bijhouden van status, deliverable-links en betalingen. Schaalt van één naar vijftig klanten zonder complexiteit. **[Notion](/recommends/notion)** — leveringshandboeken en klantgerichte werkruimten. Elke klant krijgt een gedeelde Notion-werkruimte gebouwd vanuit een sjabloon dat verfijnd is over herhaalde leveringen. **[ConvertKit](/recommends/convertkit)** — beheer van wachtlijsten en follow-up-sequenties. Wanneer een aanbieding vol is (capaciteit vult snel met vaste-scope-werk), houdt een wachtlijstsequentie warme leads betrokken tot de volgende opening. ## De meest voorkomende fouten **Productiseren voordat je het genoeg hebt geleverd.** Als je dit werk niet 3–5 keer hebt gedaan, ken je de echte scope nog niet. Lever het eerst als maatwerk. Leer waar de grenzen zijn. Definieer dan het product. **De scope vaag laten.** Een geproductiseerde dienst met ongedefinieerde scope is een maatwerkproject met vaste prijs — wat het slechtste van beide werelden is. Definieer wat erin zit, definieer wat er niet in zit, leg het schriftelijk vast en zet het op de verkooppagina. **Ja zeggen op verzoeken buiten de scope.** Als een klant meer wil, maak een add-on met eigen scope en prijs. Absorbeer het niet zomaar deze keer. **Het leveringssysteem overslaan.** Je bent niet klaar na de eerste levering. Bouw het handboek voordat je de tweede verkoopt. Het systeem is wat het product maakt. ## FAQ ### Met hoeveel geproductiseerde aanbiedingen moet ik beginnen? Eén. Bouw het, lever het, verfijn het systeem, verzamel getuigenissen, overweeg dan een tweede. De meeste mensen die er twee tegelijk lanceren, eindigen met twee halfgebouwde systemen en geen getuigenissen voor geen van beide. ### Heb ik een landingspagina nodig voor ik begin te verkopen? Nee. Voor de eerste 5–10 verkopen is een één-paginaatje-PDF of een goed geschreven e-mail genoeg. Laat websitebouwen niet de reden zijn waarom je nog niets hebt verkocht. ### Wat als een klant iets buiten de scope wil? Vertel hem dat het een apart project is. Offreer een add-on ter plekke of plan een scopinggesprek ervoor. Absorbeer het niet in het huidige project. De discipline van het handhaven van de scope is wat het model laat werken. ### Hoe kom ik aan de eerste klant? Vertel 10 mensen die je werk kennen over de aanbieding — warme gesprekken met mensen die je vertrouwen of iemand kennen die het nodig heeft. De eerste verkoop komt bijna altijd uit een direct gesprek, niet van een landingspagina. Zodra je een case study hebt, begint de [oprichter-geleide verkoopbenadering](/founder-led-sales-how-to-reach-decision-makers/) dit op te schalen. ### Kan ik iets productiseren dat ik maar één keer heb gedaan? Nee. Je begrijpt de echte scope nog niet. Lever het nog twee of drie keer als maatwerk, en formaliseer dan wat je hebt geleerd in het product. --- **Volgende stappen:** Mijn [AI Agents for Beginners-cursus](/course/) behandelt de automatiseringssystemen die geproductiseerde levering schaalbaar maken. Het [cowork-programma](/cowork/) is voor operators die systeem-gedreven bedrijven bouwen en daarvoor een gestructureerde omgeving willen. --- ## LinkedIn-leadgeneratiestrategie: hoe ik B2B-klanten win zonder betaalde advertenties Source: https://alejandrorioja.com/nl/linkedin-lead-generation-strategy/ Published: 2026-07-14 Tags: Marketing, Growth, Entrepreneurship TL;DR: LinkedIn is het gratis kanaal met de meeste hefboomwerking voor B2B-leadgeneratie — mits je het behandelt als een vertrouwensmotor en niet als een massale koude-outreach-machine. Optimaliseer je profiel als een landingspagina, publiceer consistent vanuit één invalshoek van je expertise en bouw een korte contactsequentie op die leidt met waarde. Het samengesteld effect is na 60–90 dagen merkbaar, waarna het vrijwel op zichzelf loopt. Betaalde advertenties zijn optioneel; een sterk profiel en een nuttige contentfeed niet. ## Inhoudsopgave _Gepubliceerd in juli 2026._ **TL;DR:** LinkedIn is het gratis kanaal met de meeste hefboomwerking voor B2B-leadgeneratie — mits je het behandelt als een vertrouwensmotor en niet als een massale koude-outreach-machine. Optimaliseer je profiel als een landingspagina, publiceer consistent vanuit één invalshoek van je expertise en bouw een korte contactsequentie op die leidt met waarde. Het samengesteld effect is na 60–90 dagen merkbaar, waarna het vrijwel op zichzelf loopt. Betaalde advertenties zijn optioneel; een sterk profiel en een nuttige contentfeed niet. **Operatorperspectief:** Ik heb LinkedIn gebruikt om adviesaanvragen, cursuskopers en partnerschapsgesprekken te genereren — alles zonder één advertentie te plaatsen. Wat werkt, is geen hack of tool; het is verschijnen als iemand die oprecht nuttig is in een ruimte die jouw kopers al frequenteren. Dit is het exacte draaiboek dat ik gebruik en de volgorde waarin ik het zou uitvoeren als ik vandaag opnieuw zou beginnen. ## Waarom LinkedIn in 2026 LinkedIns organisch bereik heeft het beter volgehouden dan vrijwel elk ander platform. Een bericht van iemand met een paar honderd relevante volgers kan nog steeds duizenden gerichte professionals bereiken — iets waarvoor op de meeste andere kanalen echt geld nodig is. Het algoritme blijft experticdichte content belonen die opslagen en shares genereert, niet alleen likes. Voor B2B specifiek heeft LinkedIn geen geloofwaardig alternatief: - Beslissers zijn hier toegankelijker dan op enig ander platform. - Het intentiesignaal is professioneel — mensen zijn in de "werkmodus", niet doelloos scrollend. - Een reactie of bericht creëert een openbaar register van je denken dat prospects weken of maanden later kunnen vinden. - InMail en verbindingsverzoeken blijven tot de laagste acquisitiekosten-mechanismen behoren. Het voorbehoud: dezelfde openheid die LinkedIn waardevol maakt, vult het ook met massa-outreach, generieke thought-leadership-berichten en nauwelijks verhulde pitches. De lat om op te vallen is laag. De meeste mensen halen hem simpelweg niet. ## Stap 1: Fix je profiel voordat je iets publiceert Je LinkedIn-profiel is het eerste wat een prospect leest wanneer hij je verbindingsverzoek ontvangt of een bericht tegenkomt dat je hebt geschreven. Als het niet onmiddellijk communiceert aan wie je helpt en hoe, wordt alles wat je daarna doet ondermijnd. De vier plekken die het meest tellen: 1. **Koptekst** — Niet je functietitel. De formule die werkt: _[Wat ik doe] voor [wie] zodat ze [resultaat] kunnen [behalen]_. "Ik help B2B-SaaS-oprichters hun eerste 10 enterprise-deals te sluiten zonder verkoopteam" is doorzoekbaar, specifiek en onmiddellijk zelfselecterend. 2. **Achtergrondafbeelding** — Gebruik die om dezelfde boodschap te versterken. Een clean visual met je niche of een korte bewijsverklaring slaat een generieke gradiënt. 3. **Over-sectie** — Schrijf in de eerste persoon. Twee korte alinea's: wat je doet en voor wie, dan één of twee bewijspunten (klanten, resultaten, prestaties — echte). Eindig met een duidelijke oproep tot actie: "Stuur me een DM als je X probeert te doen." 4. **Uitgelicht-sectie** — Pin één of twee dingen aan: een leadmagneet, je beste bericht, een casestudy, een boekingslink. Dit is eersteklas ruimte die de meeste mensen leeg laten. De test: lees je eigen profiel als een vreemde. Kunnen ze in 10 seconden weten wat je doet, voor wie je het doet en wat ze vervolgens moeten doen? Als dat niet het geval is, blijf dan bewerken. ## Stap 2: Publiceer over één invalshoek, consistent De meest voorkomende LinkedIn-fout is willekeurig posten — maandag een marketingtip, woensdag een motiverend citaat, vrijdag een productpitch. Het algoritme negeert je en je publiek ook. Wat werkt, is het kiezen van één specifieke invalshoek van je expertise en die toe-eigenen. Publiceer vanuit die invalshoek drie tot vier keer per week gedurende 90 dagen. Volume en consistentie slaan inspiratie en afwerking in de beginfase. ### De contentmix die samengesteld effect creëert | Formaat | Gebruik het voor | Waarom het werkt | | --- | --- | --- | | Korte tekstpost (3–5 regels) | Tegendraadse standpunten, snelle frameworks, lessen uit recent werk | Groot bereik, weinig moeite om te consumeren, genereert reacties | | Lijstpost | Stapsgewijze uitsplitsingen, vergelijkingen, tools | Opslagen en shares; algoritme-gunstig | | Verhaalpost | Een specifieke situatie die ik heb meegemaakt, wat ik deed, wat er gebeurde | Bouwt sneller vertrouwen op dan elk ander formaat | | Lang artikel | Diepgaande gidsen, tijdloze uitleg | Geïndexeerd door zoekprogramma's; positioneert je als expert in de loop van de tijd | | Carrousel (document) | Visuele frameworks, samenvattingen van langere berichten | Hoogste opslagpercentage van alle formaten | De verhouding die ik gebruik: 70% korte berichten en lijsten, 20% verhalen, 10% lang formaat of carrousels. De langere berichten krijgen niet veel bereik, maar accumuleren na verloop van tijd in zoekopdrachten en DM-shares. ## Stap 3: Bouw je verbindingsbasis doelgericht op Het juiste LinkedIn-publiek laten groeien is anders dan het in omvang laten groeien. Duizend volgers die precies jouw koper zijn, zijn meer waard dan tienduizend die je collega's of willekeurige toeschouwers zijn. Mijn targetingcriteria: - Beslissers in de sectoren die ik bedien - Oprichters en operators in bedrijven in het inkomstenbereik waarmee ik werk - Tweede-graads verbindingen van bestaande klanten en medewerkers (de warmste bron) - Mensen die interageren met concurrenten of collega's in mijn ruimte Ik stuur dagelijks 15–20 verbindingsverzoeken, elk met een eenregelige notitie die duidelijk maakt waarom ik verbinding maak. Geen pitch — alleen context: "Zag je reactie over [onderwerp], sluit aan bij mijn werk — graag verbinding maken." Die notitie brengt het acceptatiepercentage van ~30% (generiek) naar ~55–65% (specifiek). De notitie heeft maximaal twee zinnen. Maak niet met iedereen verbinding. Een opgeblazen verbindingslijst vol ongekwalificeerde accounts schaadt je daadwerkelijk — LinkedIns algoritme distribueert je berichten gedeeltelijk naar je verbindingen, dus een publiek van lage kwaliteit onderdrukt je bereik. ## Stap 4: Sequenceer je outreach — de drie-aanrakingen-aanpak Zodra iemand verbinding maakt, is het doel niet onmiddellijk pitchen. Het is het starten van een gesprek dat in de loop van de tijd tot een vergadering kan leiden. Mensen die de verbinding behandelen als toestemming om een verkoopdeck te plakken, vergiftigen elk volgend contactmoment. De sequentie die ik gebruik: **Aanraking 1 (Dag 1, binnen 24 uur na verbinding):** Stuur een kort, warm welkomstbericht. Verwijs naar waarom je verbinding hebt gemaakt en deel een nuttige resource — een bericht, een framework, een artikel — relevant voor iets wat ze hebben gedeeld. Geen verzoek. Eindig het als een verklaring, niet als een vraag. **Aanraking 2 (Dag 5–7):** Reageer oprecht op een van hun berichten — niet alleen een like, een echte doordachte reactie die bijdraagt aan het gesprek. Dit houdt je naam zichtbaar in hun feed zonder een andere DM te sturen. **Aanraking 3 (Dag 14–21):** Volg op in DM met een zacht, specifiek verzoek. Een duidelijke vraag die gemakkelijk te beantwoorden is, gekoppeld aan iets relevants dat je in hun werk hebt opgemerkt. Als de timing goed is en de pijn reëel is, worden hier vergaderingen geboekt. Zo niet, ga dan verder — het account is warm en ze kennen je naam. De fout die ik constant zie: aanrakingen 1 en 2 overslaan en direct naar een call-to-action-bericht springen zodra iemand verbinding maakt. Dat is geen leadgeneratie; het is een reputatiebelasting. ## Stap 5: Converteer gesprekken naar vergaderingen Een goed DM-gesprek heeft een schone uitgang naar een kalenderuitnodiging nodig. Op het moment dat iemand oprechte interesse toont, is dat het moment om het verzoek te doen. Het bericht dat converteert: > "Klinkt alsof [specifieke zaak die ze zeiden] voor jou reëel is. Ik heb een paar bedrijven in vergelijkbare situaties geholpen — vertel je graag in 20 minuten hoe we dat aanpakten, geen pitch, gewoon kijken of het relevant is. [boekingslink] — pak een tijdslot als dat nuttig is." Kort, weinig verplichting, gemakkelijk ja te zeggen. De boekingslink elimineert de planningswrijving die de helft van de vergaderingen die zouden moeten plaatsvinden doodt. ## Wat niet te doen De gedragingen die accounts negeren, rapporteren of verbannen: 1. **Massale verbindingsverzoeken zonder context** — LinkedIn zal je account beperken en je acceptatiepercentage zal dalen. 2. **Pitch-eerst DMs** — Het eerste bericht is niet de plek om je product, je prijsstelling of je kalenderlink te introduceren. 3. **Engagement-pods** — Nep-engagement blaast ijdelheidsstatistieken op en wordt algoritmisch gestraft. 4. **Elke dag posten zonder standpunt** — Volume zonder perspectief is ruis. Één bericht per week met echte inzichten slaat zeven "hete meningen" per week zonder substantie. 5. **Outreach automatiseren** — LinkedIns botdetectie is agressiever geworden. Geautomatiseerde verbindingstools en AI-geschreven DM-sequenties op schaal worden gemarkeerd. De sequentie in Stap 4 kost ongeveer 30 minuten per dag en heeft een signaal-ruisverhouding die geen enkel tool kan evenaren. ## Meten wat echt telt IJdelheidsstatistieken om te negeren: impressies, profielweergaven, volgersaantal. De cijfers die je vertellen of het systeem werkt: - **Verbindingsacceptatiepercentage** — doel 50%+ met notitie; als het onder de 30% ligt, herschrijf dan de notitie. - **Responspercentage op follow-upberichten** — 20–30% is gezond voor een goed gerichte lijst. - **Inkomende DMs per maand** — mensen die contact met je opnemen vanwege je content. Volg dit maand voor maand. - **Vergaderingen geboekt via LinkedIn per maand** — het enige cijfer dat correleert met omzet. Ik houd dit bij in een eenvoudige Notion-tabel. Het doel in de eerste 90 dagen is om één inkomende DM per week en één geboekte vergadering per maand alleen via LinkedIn te bereiken. In de derde maand, als de content aanslaat, stijgen die cijfers zonder proportioneel meer inspanning. ## De operatorbalans LinkedIn werkt voor B2B-leadgeneratie omdat het het enige professionele netwerk is waar organisch bereik nog gewicht heeft en waar je reputatie publiekelijk in de loop van de tijd opbouwt. De mechaniek is eenvoudig: een profiel dat uitlegt aan wie je helpt, content die bewijst dat je weet waarover je praat, en een contactsequentie die leidt met waarde in plaats van een pitch. Doe dit consistent 90 dagen lang en de inbounds beginnen te komen. Doe het een jaar lang en het wordt een van je meest betrouwbare bronnen van gekwalificeerde gesprekken — zonder advertentiebudget. --- **Gerelateerd:** [Oprichtergestuurde verkoop](/founder-led-sales-how-to-reach-decision-makers/) · [Hoe een persoonlijk merk opbouwen](/how-to-build-a-personal-brand/) · [Outreachstrategie](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/) --- ## Hoe ik Courtlines bouwde: een SaaS voor clubbeheer, ontwikkeld met Claude Source: https://alejandrorioja.com/nl/how-i-built-courtlines-a-club-management-saas-with-claude/ Published: 2026-07-11 Tags: AI Agents, Case Study TL;DR: Courtlines is het besturingssysteem voor racketsportclubs en -studio's — reserveringen, lidmaatschappen, coaching, kassa en evenementen onder één merkdak. Ik bouwde het als solo-operator met Claude als mijn engineering-partner. De les: AI liet me niet alleen sneller programmeren, het veranderde de omvang van het product dat één persoon geloofwaardig kan lanceren en runnen. ## Inhoudsopgave _Bijgewerkt in juli 2026._ **Kort samengevat:** Courtlines is het besturingssysteem voor racketsportclubs en -studio's — reserveringen, lidmaatschappen, coaching, kassa en evenementen onder één merkdak. Ik bouwde het als solo-operator met Claude als mijn engineering-partner. De les: AI liet me niet alleen sneller programmeren, het veranderde de omvang van het product dat één persoon geloofwaardig kan lanceren en runnen. **[Blik van de operator]** Ik run meer dan 30 productie-agents verspreid over een consultingmerk en Pickleland, de pickleball-faciliteit die ik uitbaat in de regio Austin, TX. Het runnen van een echte faciliteit leerde me precies hoe slecht de software voor clubs zoals de mijne is — dus bouwde ik de software die ik zelf had willen hebben. Dit is het verhaal van [Courtlines](https://courtlines.com), wat het doet, en hoe leunen op Claude één persoon in staat stelde om iets te bouwen waar normaal een heel team voor nodig is. ## Waarom een club een besturingssysteem nodig heeft, geen app Als je nooit een sportfaciliteit hebt gerund, is het softwareprobleem onzichtbaar. Van buitenaf ziet het eruit als "mensen reserveren banen." Van binnenuit is een club een klein, rommelig bedrijf met een tiental bewegende onderdelen die het allemaal met elkaar eens moeten zijn. Een lid reserveert een baan. Die reservering moet weten of ze een lidmaatschapsplan hebben, of ze tegoeden hebben, of de baan al gereserveerd is voor een clinic, of er een coach is toegewezen, en of de balie de prijs heeft aangepast. Wanneer ze verschijnen, rekent iemand aan de balie een blik ballen af — dat is de kassa. Ze schrijven hun kind in voor een jeugdprogramma — dat zijn evenementen en gezinsaccounts. Ze kopen een pakket van 10 lessen — dat is een coachingpakket met zijn eigen uitbetalingslogica naar de coach. Ze verwijzen een vriend door — dat is een lidmaatschapstrechter. De meeste clubs runnen dit op drie of vier losgekoppelde tools plus een spreadsheet plus een groepsapp. Het reserveringssysteem weet niets van de kassa. De kassa weet niets van lidmaatschappen. Aan het eind van de maand kloppen niemands cijfers. **Courtlines is het antwoord op "wat als dat allemaal één systeem was?"** Het is geen reserveringsapp met er functies bovenop geschroefd — het is één enkel besturingssysteem waarin de agenda, de lidmaatschappen, de kassa, de coachinguitbetalingen en de openbare evenementenpagina's allemaal dezelfde onderliggende data zijn. Dat is de hele these, en het is de slogan op de site: het besturingssysteem voor clubs en studio's. ## Wat Courtlines echt doet Op hoofdlijnen geeft [Courtlines](https://courtlines.com) een club: - **Een sleep-en-neerzet baanraster** voor de balie — elke reservering, clinic en blokkering op één scherm dat een beheerder in realtime kan herschikken. - **Reserveringen en vrij spel** voor leden, inclusief de ongemakkelijke-maar-essentiële randgevallen: terugkerende reserveringen, wachtlijsten, annuleringsvensters en tegoeden. - **Lidmaatschappen en facturatie** — plannen, gezinsaccounts, jeugd-/kinderlogins gekoppeld aan een ouder, en het aanmaanproces dat voorkomt dat inkomsten stilletjes weglekken. - **Coaching** — lespakketten, planning en geautomatiseerde uitbetalingen aan zelfstandige coaches. - **Kassa** — een echte kassa voor de pro shop en het café, gekoppeld aan dezelfde klantgegevens als al het andere. - **Evenementen en openbare pagina's** — clinics, competities en toernooien met openbare pagina's die mensen kunnen vinden en waarvoor ze zich kunnen inschrijven. Het ontwerpdoel is dat het platform verdwijnt. Een club zet zijn eigen merk erbovenop, en voor de leden voelt het gewoon als "de app van onze club," niet als "een of andere SaaS waarvoor we betalen." Dat is een bewust contrast met de gevestigde spelers in deze ruimte — de CourtReserves en Skedda's van deze wereld — waar de software het merk is en de club de huurder. Pickleland is tenant #1. Ik kan me niet verschuilen achter een demo; het ding moet daadwerkelijk een faciliteit runnen waarvoor ik persoonlijk verantwoordelijk ben. Die beperking is de beste productmanager die ik ooit heb gehad. Je kunt [Pickleland hier bekijken](https://pickleland.com) — het is de proeftuin in de echte wereld, en elke ruwe rand waar een lid tegenaan loopt is een bug die ik dezelfde dag voel. ## Het deel dat me verraste: wat één operator nu kan lanceren Hier is de eerlijke versie van het verhaal, en het is de reden dat ik dit bericht schrijf in plaats van gewoon stilletjes te lanceren. Een multi-tenant SaaS met facturatie, kassa, rolgebaseerde toegang, coachinguitbetalingen en een openbaar evenementensysteem is geen weekendproject. Tien jaar geleden was dit een seed-gefinancierd team van vijf tot acht engineers voor een jaar. Het is het soort omvang waarbij een solo-oprichter meestal vriendelijk wordt geadviseerd om het terug te brengen tot één functie en geld op te halen. Ik bouwde het als één persoon, met **Claude als mijn belangrijkste engineering-partner.** Niet "ik vroeg ChatGPT soms om een snippet" — ik bedoel dat Claude de grote meerderheid van de code in dit systeem schreef, werkend vanuit specificaties en productbeslissingen die van mij zijn. Mijn werk verschoof van *de implementatie typen* naar *beslissen wat waar is*: hoe het datamodel eruit moet zien, wat een rol mag doen, wat "klaar" betekent voor een functie, en wat veilig is om te lanceren. De interessante verschuiving is niet snelheid, hoewel het wel sneller is. Het is **omvang.** AI maakte me geen 2×-ontwikkelaar op dezelfde productomvang. Het veranderde de omvang van het product dat ik geloofwaardig kan bouwen en, net zo belangrijk, alleen kan *bedienen en onderhouden*. Een codebase die maar één mens schreef zou onder zijn eigen gewicht bezwijken. Een codebase waarin een AI-partner het implementatiedetail vasthoudt en ik de architectuur en de vangrails vasthoud, is een werkelijk ander soort ding — en het is de reden dat een solo-operator nu een categorie kan bestormen die vroeger een heel bedrijf vereiste. Ik publiceer hier bewust niet mijn exacte draaiboek voor Courtlines — dat is het deel dat ik als concurrentievoordeel beschouw, en ik heb liever dat mijn concurrenten blijven geloven dat dit een groot team kost. Maar als je de *mechaniek* wilt zien van hoe ik Claude op een echt project draai, in detail, dan heb ik het allemaal opgeschreven voor een veel kleinere build: een mobiele game die ik naar de app stores bracht. Zie [hoe ik Quads, een mobiel bordspel, met Claude bouwde](/how-i-built-quads-a-mobile-board-game-with-claude/) — dezelfde werkwijze, niets te verbergen, alle trucs op tafel. ## De principes waarop ik geen compromissen sluit Zelfs met het draaiboek privé, zijn een paar principes het vermelden waard omdat ze gelden voor iedereen die serieuze software met AI bouwt: **De mens houdt de gevaarlijke pennen vast.** Er is een klein aantal handelingen waarbij een fout duur en moeilijk terug te draaien is — schemawijzigingen, deploys, alles wat geld of productiedata raakt. Die blijven stevig bij mij. AI mag ze voorstellen; het mag ze niet uitvoeren. Die grens duidelijk trekken is wat het veilig maakt om AI overal elders veel speelruimte te geven. **Groene tests zijn noodzakelijk, niet voldoende.** Een reserveringsflow die elke unittest doorstaat, kan nog steeds zichtbaar kapot zijn in een echte browser. De belangrijkste verificatie voor een product met een gebruikersinterface is een mens — of een begeleid proces — die er daadwerkelijk doorheen klikt tegen realistische data. Tests zijn een gradient die dingen verhindert slechter te worden; ze zijn geen bewijs dat een functie werkt. Deze les leerde ik op de dure manier, en het veranderde permanent hoe ik "klaar" definieer. **Specificaties zijn de echte interface.** De hefboom zit niet in slim prompten — het zit in het onderhouden van heldere, actuele documenten over wat het systeem is en wat elk onderdeel geacht wordt te doen. Tijd besteed aan het precies houden daarvan betaalt zich vele malen terug over elke toekomstige sessie. Wil je de diepere versie hiervan, dan is het dezelfde discipline die ik beschrijf in [hoe je systeemprompts voor AI-agents schrijft die niet falen in productie](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/). **Bouw het ding waarmee je moet leven.** De allerbeste beslissing was Courtlines een faciliteit laten runnen die van mij is. Het is makkelijk om een demo te lanceren die indruk maakt; het is onmogelijk je te verschuilen voor software waar je eigen leden van afhankelijk zijn. Als je met AI bouwt, richt het dan op een probleem dat je persoonlijk voelt — de realiteitscheck is meer waard dan welke testsuite dan ook. ## Waar dit past bij al het andere dat ik bouw Courtlines bestaat niet in isolatie. Het is onderdeel van een klein racketsport-ecosysteem dat ik bouw: [The Court Scout](https://thecourtscout.com) is een geverifieerde gids van pickleball-banen, gebouwd om werkelijk nauwkeuriger te zijn dan de gescrapete gidsen waarmee het concurreert, en Pickleland is de vlaggenschipfaciliteit waartegen alles wordt getest. De gids helpt spelers banen te vinden; Courtlines helpt de clubs achter die banen om daadwerkelijk te draaien. Het bindweefsel over alles heen is hetzelfde operationele model: een solo-operator versterkt door AI, die meer terrein bestrijkt dan een solo-operator historisch gezien kon. Courtlines is tot nu toe de meest ambitieuze uitdrukking van dat model — een volledig SaaS-platform waar ik een paar jaar geleden simpelweg niet alleen aan begonnen zou zijn. Als je een racketsportclub of een studio runt en je bent het zat om vier tools aan elkaar te knopen, werp dan een blik op [Courtlines](https://courtlines.com). En als je een bouwer bent die zich afvraagt hoe ver je AI kunt duwen op een echt product, dan is dat het hele punt van dit bericht: verder dan je waarschijnlijk denkt. ## Veelgestelde vragen ### Wat is Courtlines? Courtlines is een multi-tenant besturingssysteem voor racketsportclubs en -studio's — pickleball, tennis, padel en verder. Het combineert reserveringen, lidmaatschappen, coaching, kassa en evenementenbeheer in één merkplatform, zodat een club zijn hele bedrijf vanuit één systeem runt in plaats van vier losgekoppelde tools. Je kunt het bekijken op [courtlines.com](https://courtlines.com). ### Heeft Claude echt het grootste deel van de code geschreven? Ja. Claude was mijn belangrijkste engineering-partner en schreef de grote meerderheid van de implementatie, werkend vanuit specificaties, architectuur en productbeslissingen die ik bezit en beheer. Ik houd het schema, de deploys en de definitie van "klaar" vast; de AI houdt het implementatiedetail vast. Die taakverdeling is wat een solo-gebouwde SaaS van deze omvang onderhoudbaar maakt. ### Kan één persoon echt een SaaS van deze omvang bouwen en runnen met AI? Het bouwen ervan is nu werkelijk haalbaar — dat is het verrassende deel. De grotere uitdaging is het bedienen en onderhouden ervan, want een grote codebase heeft iemand nodig die de architectuur begrijpt, zelfs wanneer een AI de details schreef. De sleutel is heldere specificaties bijhouden en standvastig blijven op het kleine aantal handelingen met hoog risico die een mens moet bezitten. Op die manier gedaan is het onderhoudbare terrein voor één operator veel groter dan het vroeger was. ### Waarom je eigen clubsoftware bouwen in plaats van CourtReserve of Skedda te gebruiken? Omdat het runnen van Pickleland me precies liet zien waar de bestaande tools tekortschieten: het reserveringssysteem, de kassa en de lidmaatschappen delen niet één bron van waarheid, dus niets sluit netjes op elkaar aan. Ik wilde een systeem waarin het allemaal dezelfde onderliggende data is en waarin het merk van de club — niet dat van de softwareleverancier — is wat leden zien. Dat is het gat dat Courtlines is gebouwd om te dichten. ### Waar kan ik leren hoe je dagelijks daadwerkelijk met Claude werkt? Ik houd het gedetailleerde Courtlines-draaiboek privé om concurrentieredenen, maar ik documenteerde exact dezelfde werkwijze op een kleiner, volledig open project — een mobiel bordspel genaamd Quads. Lees [hoe ik Quads, een mobiel bordspel, met Claude bouwde](/how-i-built-quads-a-mobile-board-game-with-claude/) voor de mechaniek, of [hoe ik bepaal of een automatisering het bouwen waard is](/ai-agent-roi-how-i-decide-whether-automation-worth-building/) voor het rendementsdenken achter alles wat ik lanceer. --- ## Hoe ik Quads bouwde, een mobiel bordspel, met Claude — van een hackathon van 2 uur tot de App Store Source: https://alejandrorioja.com/nl/how-i-built-quads-a-mobile-board-game-with-claude/ Published: 2026-07-11 Tags: AI Agents TL;DR: Quads is een mobiel bordspel — een strakke interpretatie van het klassieke abstracte spel Quarto — dat begon als een hackathon van 2 uur met een vriend in Colombia en werd gelanceerd in de app stores. Dit is de volledig-open versie van hoe ik met Claude bouw: parallelle agent-worktrees, een echte (niet-LLM) game-AI, offline-first ontwerp, en de specifieke valkuilen die me uren kostten. ## Inhoudsopgave _Bijgewerkt in juli 2026._ **Kort samengevat:** Quads is een mobiel bordspel — een strakke interpretatie van het klassieke abstracte spel Quarto — dat begon als een hackathon van 2 uur met een vriend in Colombia en werd gelanceerd in de app stores. Dit is de volledig-open versie van hoe ik met Claude bouw: parallelle agent-worktrees, een echte (niet-LLM) game-AI, offline-first ontwerp, en de specifieke valkuilen die me uren kostten. **[Blik van de operator]** Ik run meer dan 30 productie-agents verspreid over een consultingmerk en Pickleland, mijn pickleball-faciliteit in de regio Austin. Het meeste van wat ik bouw is serieuze bedrijfssoftware waarbij ik het draaiboek privé houd. Quads is het tegenovergestelde — een leuk zijproject dat ik je van boven tot onder kan laten zien. Als je precies wilt zien hoe ik met Claude werk, zonder dat er iets is weggeslepen, dan is dit het bericht. Je vindt het spel op [playquads.com](https://playquads.com). ## Het begon als een hackathon van 2 uur in Colombia De oorsprong is bijna gênant nonchalant. Ik was op reis in Colombia, en een vriend en ik gaven onszelf een hackathon van 2 uur: kies iets kleins, bouw het met AI, kijk hoe ver we komen. We kwamen uit bij Quarto — een prachtig klein abstract strategiespel dat makkelijk te leren is en verrassend diep. Twee uur later hadden we een speelbaar prototype, en het idee was te goed om op een laptop achter te laten. Wat begon als een uitdaging met tijdslimiet werd een echte, gelanceerde mobiele app op iOS en Android. Die boog — *grap-prototype tot storevermelding* — is de hele reden waarom ik denk dat dit project het schrijven waard is. De afstand tussen "leuk idee" en "iets dat vreemden kunnen downloaden" is ingestort, en Quads is een strakke case study van hoe. Eerst een korte uitweiding over de naam. Het spel is een herimplementatie van **Quarto**, wat een gemerkt spel is in eigendom van Gigamic. Dus de allereerste niet-code-beslissing was om het *niet* Quarto te noemen op enige plek waar een klant het zou zien. Het ging van Quarto (de mechaniek) via een paar tussentijdse namen naar **Quads** — een naam die ik zelf mag gebruiken. Als je een klassieker herimplementeert, regel de merkkwestie dan uit voordat je verliefd wordt op een naam. ## Wat Quads eigenlijk is Voor de niet-ingewijden: Quads wordt gespeeld op een 4×4-bord met 16 unieke stukken. Elk stuk heeft vier binaire eigenschappen — lang of kort, donker of licht, vierkant of rond, massief of hol — en de 16 stukken dekken elke mogelijke combinatie precies één keer. Je wint door een lijn van vier stukken te voltooien die *één willekeurige* eigenschap delen. De draai die het briljant maakt: **je kiest niet het stuk dat je plaatst. Je tegenstander overhandigt het je.** Dan overhandig jij hun stuk. Dus elke beurt is een dubbele klem — je probeert het stuk dat je kreeg te plaatsen zonder een winst op te zetten, terwijl je een stuk kiest om te geven dat je tegenstander het spel niet in handen geeft. Het is elegant en echt lastig. De app biedt vier manieren om te spelen, allemaal volledig offline: tegen de computer over vijf moeilijkheidsniveaus, doorgeef-en-speel op één apparaat, een dagelijkse puzzel, en een asynchrone "daag een vriend uit"-modus. Geen account, geen server, geen login. Die offline-first beslissing stuurde veel van de engineering, en het is een groot deel van waarom een solo-build behapbaar was. ## De spellogica: een hele set regels die uit bitrekenkunde rolt Dit is mijn favoriete deel, want het is het soort ding dat bevredigend is, of AI het nu schreef of niet. Elk van de 16 stukken is gewoon een geheel getal van 0 tot 15. Elk van de vier bits is één eigenschap. Dat is het — de hele stukkenset is de getallen 0–15, want vier bits geven je precies 16 combinaties. Winstdetectie wordt dan bijna triviaal. Voor elke lijn van vier stukken houd je twee lopende accumulatoren bij: de bits die `1` zijn in *elk* stuk, en de bits die `0` zijn in *elk* stuk. Als een van beide accumulatoren niet-nul is na alle vier, zijn de stukken het eens over ten minste één eigenschap — dat is een winst. De hele set regels valt terug op een paar bitsgewijze AND-operaties. Omdat de logica pure functies over gehele getallen is — geen framework, geen UI, geen state — is het direct unit-testbaar, en het is triviaal uit te breiden. Quads biedt zelfs een huisregelvariant waarin de negen 2×2-vierkanten ook als winnende vormen tellen, wat een toevoeging van twee regels is bovenop dezelfde bittruc. Wanneer jij en een AI-partner de kernlogica zo schoon houden, is een functie toevoegen een genoegen in plaats van een risico. ## De AI-tegenstander is geen LLM (en dat is de juiste keuze) Hier is een leermoment dat me aan het hart gaat: **niet elke "AI" hoort een groot taalmodel te zijn.** De Quads-tegenstander is pure klassieke game-AI, en dat hoort ook zo. Bij elke beurt maakt hij twee beslissingen — waar het stuk te plaatsen dat hij kreeg, en welk stuk terug te geven — en de moeilijkheidsgraad schaalt hoe hard hij nadenkt: - **Beginner** speelt in wezen willekeurig en zal je de winst overhandigen. - De middelste niveaus voegen heuristieken toe: pak een directe winst als die bestaat, en vermijd het weggeven van een stuk waarmee de tegenstander kan winnen, met voorkeur voor het stuk dat de minste toekomstige dreigingen bewapent. - **Meester en Grootmeester** draaien een begrensde negamax-zoektocht — echte spelboom-zoektocht — maar met een hard **knooppuntbudget**, zodat een zet nooit de hoofdthread van de telefoon kan laten hangen. Vroeg in het spel, waar perfect zoeken onhaalbaar is, valt het terug op snelle heuristieken; laat in het spel, waar de boom klein genoeg is, zoekt het echt. Twee dingen die het waard zijn om hiervan te stelen. Ten eerste zou een taalmodel hier *slechter* zijn — langzamer, duurder, niet-deterministisch en verslaanbaar — dan vijftig regels negamax. Stem de tool af op het probleem. Ten tweede is het knooppuntbudget de echte engineering: op een mobiel apparaat is "correct maar hangt af en toe vier seconden" een mislukte functie. Het zoeken begrenzen zodat een zet altijd snel is, ook al is die af en toe suboptimaal, is het verschil tussen een speeltje en een product. Weten *wanneer* je naar een LLM moet grijpen is hetzelfde oordeel dat ik toepas op elke automatisering — het is de kern van [hoe ik bepaal of een AI-build de moeite waard is](/ai-agent-roi-how-i-decide-whether-automation-worth-building/). ## Hoe ik Claude daadwerkelijk draai: parallelle agents in worktrees Nu het deel dat ik privé houd op mijn grotere producten, maar je hier volledig kan laten zien. Ik bouw niet met één Claude-sessie tegelijk. Ik draai er **meerdere parallel**, elk in zijn eigen git worktree op zijn eigen branch. Eén agent voegt internationalisatie toe, een ander bouwt het dagelijkse-puzzel-systeem, een ander doet kleurenblindmodus, weer een ander sluit geluid aan — elk geïsoleerd in zijn eigen werkkopie zodat ze elkaar niet kunnen overschrijven, en elk wordt teruggevoegd wanneer het groen is. De git-geschiedenis van Quads is een muur van `Merge branch 'worktree-agent-…'`-commits, wat precies is hoe die workflow er van buitenaf uitziet. De reden dat worktrees ertoe doen is eenvoudig: parallelle agents die dezelfde werkmap bewerken lopen elkaar meteen voor de voeten. Geef elk een geïsoleerde checkout en je kunt werkelijk vier functies tegelijk in aanbouw hebben, en ze dan samenvoegen zoals elke andere branch. Het is de enige verandering met de hoogste hefboomwerking in hoe ik werk — ik ging van één gesprek, één functie, naar een kleine vloot. Wil je de discipline achter de prompts waarop die agents draaien, dan is het dezelfde die ik beschrijf in [hoe je systeemprompts voor AI-agents schrijft die niet falen in productie](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/): de hefboom zit in heldere, actuele specificaties, niet in slimme formuleringen. ## De valkuil die me een uur kostte (zodat het jou er geen kost) Elk project leert je één domme, dure les. Bij Quads was het deze: **de previewtool toont niet altijd de branch waarvan je denkt dat hij hem toont.** Wanneer je meerdere agents in meerdere worktrees draait en hun werk previewt, kan de preview vanuit een *andere* map starten dan die waar je huidige sessie in zit — dus je maakt een screenshot van de app, ziet geen van je wijzigingen, en begint een "ontbrekende" UI te debuggen die nooit ontbrak. De functie was prima; de preview wees naar de verkeerde checkout. Ik verloor echte tijd hieraan voordat ik doorhad wat er gebeurde, en ik schreef het op in de eigen notities van het project zodat de toekomstige ik (en elke agent aan wie ik de repo overhandig) het previewdoel controleert *voordat* er spookbugs worden gedebugd. De verwante valkuil: het configuratiebestand dat die previews definieert wordt gedeeld over parallelle sessies, dus twee agents die het tegelijk bewerken kunnen stilletjes elkaars invoer overschrijven. Als je een vloot gaat draaien, behandel gedeelde configuratie dan als een betwiste bron — het bijt je precies één keer, en daarna nooit meer als je de les opschrijft. Die gewoonte — elke moeizaam verworven valkuil vastleggen in een duurzaam bestand dat de volgende sessie zal lezen — is de stille ruggengraat van bouwen met AI op elke schaal. Context verdampt tussen sessies; opgeschreven lessen niet. ## De offline-first trucs waar ik trots op ben Omdat Quads geen backend heeft, hadden een paar problemen slimme, serverloze antwoorden nodig: - **De dagelijkse puzzel** wordt deterministisch gekozen op basis van de lokale dag van het jaar, zodat elke speler wereldwijd dezelfde puzzel krijgt zonder enige servercoördinatie. (Bonusles: ik lanceerde, en repareerde toen meteen, een zomertijd-één-verschil-fout in die datumrekenkunde. Datums zijn altijd lastiger dan ze eruitzien.) - **"Daag een vriend uit"** codeert een puzzel in een korte tekstcode — zoiets als `QC1-01-03-3` — bewaakt door een checksum zodat een typfout geen geldige-maar-verkeerde uitdaging kan opleveren. Je vriend typt hem in hun eigen kopie van de app en speelt precies dezelfde stelling, volledig offline. Geen accounts, geen matchmaking, geen server. - **Rijke linkvoorbeelden** zijn de ene plek waar ik wél een klein beetje servercode gebruikte. Wanneer je een uitdagingslink deelt, rendert een enkele Cloudflare Pages Function per-code Open Graph-tags zodat de link mooi uitvouwt in iMessage of WhatsApp. Sociale crawlers draaien geen JavaScript, dus een client-gerenderd voorbeeld zou er voor elke link identiek uitzien — één kleine function lost dat op zonder een echte backend nodig te hebben. Geen van deze is lastig zodra je ze doorziet, maar elk ervan is een plek waar het luie antwoord is "start een server en een database," en het betere antwoord is "doe het slimme offline ding." Een backend volledig vermijden is waarom één persoon dit kon lanceren en onderhouden. ## Van hackathon tot storevermelding De laatste etappe — het deel dat niemand je vertelt over een "project van 2 uur" — is alles tussen "het werkt op mijn telefoon" en "vreemden kunnen het downloaden." Internationalisatie over acht talen in één keer. Storeteksten die nooit de gemerkte naam gebruiken. App-store buildgereedschap, versiebeheer, en de platformspecifieke rechtenopschoning die voorkomt dat een storebeoordeling je terugstuurt. Dit is onglamoureus, en het is waar veel zijprojecten stilletjes sterven. Het met Claude doen maakte de checklist niet korter, maar het maakte elk item goedkoop genoeg dat ik het daadwerkelijk afmaakte. Dat is het echte verhaal van Quads: niet dat AI een bordspel schreef — genoeg mensen kunnen er een prototypen — maar dat het de kosten van de *laatste loodjes* genoeg verlaagde dat een hackathon-grap een gelanceerd product werd. Als je een klein idee hebt waar je op zit te broeden, dan is dat mijn hele pleidooi. Begin met de versie van 2 uur. Je zult verbaasd zijn hoe dichtbij de finishlijn is gekomen. En als je wilt zien hoe ver deze zelfde werkwijze op de schaal reikt, ik nam hem helemaal mee tot een volledige multi-tenant SaaS — [hoe ik Courtlines, een platform voor clubbeheer, met Claude bouwde](/how-i-built-courtlines-a-club-management-saas-with-claude/). Speel Quads op [playquads.com](https://playquads.com). ## Veelgestelde vragen ### Wat is Quads? Quads is een mobiel bordspel voor iOS en Android — een strakke herimplementatie van het klassieke abstracte strategiespel Quarto. Je speelt op een 4×4-bord met 16 unieke stukken, en de draai is dat je tegenstander het stuk kiest dat je moet plaatsen. Het is gratis te spelen met modi voor solo, doorgeef-en-speel, een dagelijkse puzzel, en asynchrone uitdagingen. Vind het op [playquads.com](https://playquads.com). ### Heeft Claude het hele spel geschreven? Claude schreef de grote meerderheid van de code, werkend vanuit het ontwerp en de beslissingen die ik bezit. Ik draaide meerdere Claude-sessies parallel, elk in zijn eigen git worktree, die verschillende functies bouwden die ik samenvoegde. De spellogica, de AI-tegenstander, internationalisatie, geluiden en het puzzelsysteem werden grotendeels op deze manier gebouwd en door mij beoordeeld. ### Wordt de AI-tegenstander in het spel aangedreven door een LLM? Nee — en dat bewust. De tegenstander gebruikt klassieke game-AI: heuristieken op lagere moeilijkheidsgraden en een begrensde negamax-zoektocht in de hoogste niveaus, met een hard knooppuntbudget zodat een zet het apparaat nooit laat hangen. Een taalmodel zou langzamer, duurder en zwakker zijn voor deze taak. Het juiste soort AI kiezen voor het probleem doet er meer toe dan altijd naar het grootste model grijpen. ### Hoe lang duurde het om Quads te bouwen? Het eerste speelbare prototype kwam voort uit een hackathon van 2 uur met een vriend tijdens een reis naar Colombia. Dat prototype omzetten in een gepolijste, lanceerbare app in beide app stores — met internationalisatie, een echte AI-tegenstander, offline uitdagingen en storenaleving — kostte aanzienlijk langer, maar elke afzonderlijke stap was goedkoop genoeg met AI dat het project daadwerkelijk de finishlijn bereikte. ### Wat is de grootste les van het bouwen van Quads met Claude? Twee dingen. Ten eerste, draai agents in geïsoleerde git worktrees zodat je meerdere functies parallel kunt bouwen zonder dat ze elkaar overschrijven. Ten tweede, schrijf elke valkuil op in een duurzaam bestand dat de volgende sessie zal lezen — context verdampt tussen sessies, maar opgeschreven lessen stapelen zich op. Voor het grotere plaatje van deze werkwijze, zie [hoe ik Courtlines met Claude bouwde](/how-i-built-courtlines-a-club-management-saas-with-claude/). --- ## Hoe schrijf je systeem-prompts voor AI-agenten die niet falen in productie Source: https://alejandrorioja.com/nl/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/ Published: 2026-07-11 Tags: AI Agents TL;DR: Een productie systeem-prompt heeft vijf lagen: identiteit (wie de agent is en wat hij niet kan doen), context (wat hij weet over de omgeving), taak (hoe succes er stap voor stap uitziet), uitvoerformaat (de meest onderschatte laag) en randgevallen (wat te doen als invoer faalt). De meeste prompts falen omdat ze lagen 4 en 5 overslaan. Schrijf het uitvoerformaat eerst — het dwingt je precies te zijn over wat je echt wilt. ## Inhoudsopgave _Bijgewerkt juli 2026._ **TL;DR:** Een productie systeem-prompt heeft vijf lagen: identiteit (wie de agent is en wat hij niet kan doen), context (wat hij weet over de omgeving), taak (hoe succes er stap voor stap uitziet), uitvoerformaat (de meest onderschatte laag) en randgevallen (wat te doen als invoer faalt). De meeste prompts falen omdat ze lagen 4 en 5 overslaan. Schrijf het uitvoerformaat eerst — het dwingt je precies te zijn over wat je echt wilt. **[Operatorperspectief]** Ik beheer meer dan 30 AI-agenten in productie voor mijn consultingmerk en Pickleland, een pickleballfaciliteit in Pflugerville, TX. Ik heb meer systeem-prompts herschreven dan ik er geschreven heb — meestal omdat de eerste versie goed leek te werken in tests en dan stil achteruitging in productie. Dit is wat ik heb geleerd over het schrijven van prompts die stand houden. ## Het systeem-prompt probleem dat niemand toegeeft De meeste systeem-prompts voor agenten worden in ongeveer 20 minuten geschreven, getest met twee of drie voorbeelden en dan nooit meer aangeraakt. Het model gaat live. Een tijdlang werkt het. Dan verandert er iets — de invoer wordt rommelig, het model wordt bijgewerkt, een nieuw randgeval verschijnt — en de agent begint slechte output te produceren. Still. Op schaal. Het probleem is niet dat de oorspronkelijke prompt slecht was. Het is dat de meeste prompts geschreven worden om het gelukkige pad te demonstreren. Ze zijn ontworpen voor de invoer die je in gedachten had toen je de agent bouwde, niet voor de volledige verdeling van invoer die de agent daadwerkelijk zal zien. ## De vijf lagen van een productie systeem-prompt Ik denk aan elke systeem-prompt die ik schrijf in vijf lagen. Ze hoeven niet in deze volgorde te verschijnen — maar ze moeten allemaal aanwezig zijn. ### Laag 1: Identiteit Identiteit vertelt het model wie het is en wat zijn operationele beperkingen zijn. Niet een rollenspelfiguur — een functionele definitie van wat deze agent doet en niet doet. Een sterke identiteitslaag beantwoordt drie vragen: - Waarvoor is deze agent verantwoordelijk? - Waarvoor is hij expliciet NIET verantwoordelijk (en moet hij escaleren of weigeren)? - Welke normen handhaaft hij? Het expliciete buiten-bereik is het deel dat de meeste operators overslaan. Zonder het zal het model proberen nuttig te zijn buiten zijn terrein — en dat is waar het misgaat. ### Laag 2: Context Context is wat de agent weet over zijn omgeving dat niet in het bericht van de gebruiker staat. Dit omvat de huidige datum en tijd (dynamisch injecteren — vertrouw nooit het interne tijdsbesef van het model), relevante toestand van externe systemen en bedrijfsregels die niet voor de hand liggen vanuit de taakomschrijving. De meeste agenten die ik bekijk zijn contextarm. Neem niets aan. Injecteer het. ### Laag 3: Taak De taaklaag beschrijft wat de agent stap voor stap doet. Niet "klanten helpen" — de werkelijke beslissingsstroom. Schrijf het als een stroomdiagram, niet als een directief. Stroomdiagrammen zijn robuuster omdat ze de behoefte van het model verminderen om te infereren wat je wilt in ambigue gevallen. ### Laag 4: Uitvoerformaat Dit is de meest onderschatte laag, en degene die het meest verantwoordelijk is voor stille fouten. Als je het uitvoerformaat niet precies specificeert, produceert het model output die correct lijkt voor een menselijke lezer maar inconsistent genoeg is om de downstream verwerking te breken. Schrijf het uitvoerformaat eerst. Voor gestructureerde output specificeer je het exacte schema. Voor proza-output specificeer je structuur, lengte en toonbeperkingen. Voor hoge-risico agenten gebruik ik de gestructureerde output van [Claude](/recommends/claude) met een gedefinieerd JSON-schema. ### Laag 5: Randgevallen De randgevallenlaag beantwoordt: wat doet de agent als de invoer ambigu, onvolledig, in de verkeerde taal, vijandig of duidelijk onjuist is? Geef het model voor elk randgeval een expliciet antwoordpad. ## Hoe ik systeem-prompts in de loop van de tijd onderhoud Een productie systeem-prompt is een levend document: 1. **Wekelijkse steekproef.** Ik bekijk vijf tot tien willekeurige outputs van elke hoge-risico agent ten opzichte van de verwachte output. 2. **Revisie na modelupdate.** Elke keer dat de onderliggende modelversie verandert, voer ik de agent uit tegen de volledige gouden set van mijn [evaluatiekader](/how-i-measure-whether-an-ai-agent-is-actually-working/). 3. **Randgevallenlog.** Ik houd een doorlopend log bij van invoer die de agent slecht heeft afgehandeld. Wanneer drie of meer items een patroon delen, voeg ik een expliciete regel toe. 4. **Prompt-versiebeheer.** Elke significante wijziging krijgt een versiecommentaar. ## Veelgestelde vragen ### Hoe lang moet een productie systeem-prompt zijn? Lang genoeg om alle vijf lagen te dekken. Kort genoeg zodat je het in twee minuten kunt lezen en afwijking kunt herkennen. Voor de meeste van mijn agenten is dat 200-600 woorden. ### Wanneer moet ik een complexe taak opsplitsen in meerdere agenten in plaats van één lang prompt? Wanneer de taak twee of meer duidelijk verschillende modi heeft die verschillende context, verschillende uitvoerformaten of verschillende foutafhandeling vereisen. Zie [event-gestuurde vs. geplande agenten](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) voor het patroon. ### Wat is de meest voorkomende reden waarom een prompt die in tests werkte, faalt in productie? De testinvoer was niet representatief voor de productieverdeling. Bouw een testset op basis van echt productieverkeer, niet op basis van bedachte invoer. --- ## AI-Agent ROI: Hoe Ik Beslis of een Automatisering de Moeite Waard Is Source: https://alejandrorioja.com/nl/ai-agent-roi-how-i-decide-whether-automation-worth-building/ Published: 2026-07-09 Tags: AI Agents, Operations TL;DR: Voordat ik een AI-agent bouw, voer ik een vierdelige ROI-controle uit: handmatige kosten kwantificeren, bouwkosten schatten, uitvoeringskosten projecteren en een onderhoudsbelasting toevoegen. Het resultaat is een terugverdientijd. Als die meer dan zes maanden bedraagt voor een niet-strategische taak, schrap ik het. De meeste agentideeën falen deze test — en dat is het punt. De verkeerde automatisering bouwen is erger dan helemaal niets bouwen. ## Inhoudsopgave _Bijgewerkt juli 2026._ **TL;DR:** Voordat ik een AI-agent bouw, voer ik een vierdelige ROI-controle uit: handmatige kosten kwantificeren, bouwkosten schatten, uitvoeringskosten projecteren en een onderhoudsbelasting toevoegen. Het resultaat is een terugverdientijd. Als die meer dan zes maanden bedraagt voor een niet-strategische taak, schrap ik het. De meeste agentideeën falen deze test — en dat is het punt. **[Operatorsperspectief]** Ik beheer meer dan 30 agents in productie voor een consultingmerk en Pickleland, een pickleballlocatie in Pflugerville, TX. Ik heb minstens evenveel agents geschrapt als ik heb gelanceerd. De geschrapte waren geen slechte ideeën — het waren goede ideeën die de wiskundige toets niet doorstonden. Dit framework is wat ik uitvoer voordat ik één regel agentcode schrijf. ## De vraag die niemand als eerste stelt Iedereen vraagt in 2026: "Hoe automatiseer ik dit?" De betere vraag is: "Moet ik dit automatiseren, en wanneer verdient het zich terug?" Een AI-agent is niet gratis. Het kost tijd om te bouwen, geld om te draaien en voortdurende aandacht om te onderhouden. Als de automatisering die kosten niet sneller terugverdient dan het handmatige alternatief, heb je je operatie complexer en duurder gemaakt — niet efficiënter. ## Stap 1: De handmatige uitgangssituatie kwantificeren Het eerste getal is hoeveel het huidige proces per jaar kost. ``` handmatige_kosten_per_jaar = (tijd_per_instantie × uurtarief × frequentie_per_jaar) + foutenkosten_per_jaar ``` **Tijd per instantie** is de werkelijke kloktijd die iemand besteedt — niet de kalendertijd van begin tot einde, die wachttijden omvat. **Uurtarief** zijn de volledige kosten van wie het werk doet. Als het je eigen tijd is, gebruik dan je doel-consultancy- of opportuniteitstarief, niet nul. **Frequentie per jaar** is hoe vaak deze taak daadwerkelijk wordt uitgevoerd. **Foutenkosten** is de factor die de meeste mensen vergeten. Praktijkvoorbeeld van Pickleland: het handmatig verzenden van Facebook-evenementpromoties kostte 45 minuten per week. Tegen mijn opportuniteitstarief is dat $45/week of $2.340/jaar. Dat is de uitgangssituatie. ## Stap 2: Bouwkosten eerlijk schatten Bouwkosten worden bijna altijd onderschat. ``` bouwkosten = (ontwikkelingsuren × uurtarief) + toolsetupkosten + test_en_iteratieuren × uurtarief + integratie_debuguren × uurtarief ``` Voor de Pickleland-evenementpromotor: ik schatte 6 uur om te bouwen, 3 uur om te testen en af te stemmen, 2 uur integratiedebuggen. Tegen mijn tarief zijn dat $990 aan bouwkosten. ## Stap 3: Uitvoeringskosten projecteren ``` uitvoeringskosten_per_jaar = (api_aanroepen_per_jaar × kosten_per_aanroep) + infrastructuurkosten_per_jaar + menselijke_beoordelingsuren × uurtarief ``` **API-aanroepen** zijn de Claude/LLM-aanroepen plus eventuele API's van derden. **Infrastructuur** op Cloudflare Workers + Queues is vaak onder de $5/maand voor matig volume. **Menselijke beoordeling** is de kostenfactor die mensen het meest vergeten. Voor de Pickleland-promotor: ~1.000 Claude API-aanroepen/jaar. Menselijke beoordeling bedraagt ~$800/jaar. Totale uitvoeringskosten: ~$810/jaar. ## Stap 4: De onderhoudsbelasting toepassen Dit is de meest onderschatte factor in elke agent-ROI-berekening. Agents breken. Ik pas een vast tarief van 20% van de bouwkosten per jaar toe als onderhoudsbelasting. ``` onderhoudskosten_per_jaar = bouwkosten × onderhoudspercentage ``` Voor de Pickleland-promotor: $990 × 20% = $198/jaar. ## De terugverdienformule ``` netto_jaarlijkse_besparingen = handmatige_kosten_per_jaar − uitvoeringskosten_per_jaar − onderhoudskosten_per_jaar terugverdien_maanden = (bouwkosten ÷ netto_jaarlijkse_besparingen) × 12 ``` Voor de Pickleland-evenementpromotor: - Handmatige kosten: $2.340/jaar - Uitvoeringskosten: $810/jaar - Onderhoud: $198/jaar - Netto jaarlijkse besparingen: $1.332/jaar - Bouwkosten: $990 - **Terugverdientijd: 8,9 maanden** Dat is grensgevall. Mijn drempel voor niet-strategische automatiseringen is zes maanden. ## Mijn terugverdiendrempels - **Minder dan 3 maanden:** Onmiddellijk bouwen. Deze zijn zeldzaam. - **3–6 maanden:** Duidelijk ja. Dit zijn de automatiseringen die zich opstapelen. - **6–12 maanden:** Bouwen als strategisch belangrijk. Anders schrappen. - **Meer dan 12 maanden:** Bijna altijd schrappen. ## Wanneer NIET automatiseren De duurste fout die ik teams zie maken is het automatiseren van onstabiele processen. Vraag voor automatisering: is dit proces ten minste drie maanden stabiel geweest? De tweede fout is het automatiseren van laagfrequente taken met hoge inzetten. Ten derde: automatiseer niet om een gesprek te vermijden. ## De agentstack die deze automatiseringen uitvoert De meeste automatiseringen die ik in productie uitvoer, zijn op Cloudflare Workers + Queues, met [Claude](/recommends/claude) als LLM. ## FAQ ### Welk uurtarief moet ik voor mijn eigen tijd gebruiken? Gebruik je opportuniteitskosten. Gebruik niet nul. ### Hoe schat ik Claude API-kosten voordat ik iets heb gebouwd? Gebruik het Claude token-telendpoint met een representatief sample van echte invoer. ### Wat telt als "strategische" automatisering? Een strategische automatisering (1) bedient klanten direct op een manier die retentie of conversie beïnvloedt, (2) maakt een operatieschaal mogelijk die je handmatig niet zou kunnen bereiken, of (3) produceert data die betere beslissingen stuurt. ### Moet ik de tijd tellen die ik besteed aan het monitoren van de agent? Ja. Monitortijd is een echte doorlopende kostenpost. ### Wat als de taak iets is dat ik gewoon haat te doen? Een taak haten heeft reële kosten. Ik accepteer een langere terugverdientijd voor taken die ik echt verafschuw, maar het is geen blanco cheque. --- ## Founder-led sales: hoe je de juiste koper vindt en bereikt voordat je een team opschaalt Source: https://alejandrorioja.com/nl/founder-led-sales-how-to-reach-decision-makers/ Published: 2026-07-09 Tags: Entrepreneurship, Growth, Marketing TL;DR: Voordat je een salesteam aanneemt, moet je bewijzen dat je kunt verkopen. Founder-led sales komt neer op drie dingen: bepaal wie de ene persoon is die echt ja kan zeggen, doe genoeg onderzoek om een antwoord te verdienen, en stem je kanalen op elkaar af — e-mail voor de vraag, telefoon voor de tijdgevoelige follow-up, LinkedIn voor de warme introductie. De meeste deals lopen niet vast omdat de pitch zwak was, maar omdat hij in de verkeerde inbox belandde. Omzeil dat en je boekt gesprekken die een betaalde verkoper niet zou krijgen. ## Inhoudsopgave _Gepubliceerd juli 2026._ **TL;DR:** Voordat je een salesteam aanneemt, moet je bewijzen dat je kunt verkopen. Founder-led sales komt neer op drie dingen: bepaal wie de ene persoon is die echt ja kan zeggen, doe genoeg onderzoek om een antwoord te verdienen, en stem je kanalen op elkaar af — e-mail voor de vraag, telefoon voor de tijdgevoelige follow-up, LinkedIn voor de warme introductie. De meeste deals lopen niet vast omdat de pitch zwak was, maar omdat hij in de verkeerde inbox belandde. Omzeil dat en je boekt gesprekken die een betaalde verkoper niet zou krijgen. **[Blik van een operator]** Elke oprichter die ik een echt bedrijf heb zien bouwen, verkocht de eerste deals zelf — meestal eerst slecht, daarna goed. Er is geen shortcut omheen. Je kunt geen salesbeweging overdragen die je nooit zelf hebt gedaan, want je weet nog niet waar je koper echt op reageert. Dit is het proces dat ik gebruik en waarin ik oprichters coach: hoe je de juiste persoon vindt, net genoeg onderzoek doet om een antwoord te verdienen, en die persoon bereikt zonder vreemden lastig te vallen of een scraping-tool te kopen. ## Waarom oprichters eerst zelf moeten verkopen Je kunt een beweging niet delegeren die je nooit zelf hebt gedaan. Als je een verkoper aanneemt voordat je zelf een handvol deals hebt gesloten, schaal je geen proces op — je besteedt het ontdekken ervan uit, en betaalt een salaris om te leren wat je gratis had kunnen leren. Founder-led sales is geen fase die je verdraagt tot je je een verkoper kunt veroorloven. Het is hoe je de exacte woorden leert die je koper gebruikt, het bezwaar dat negen van de tien deals de nek omdraait, en de ene zin die iemand geïnteresseerd doet leunen. Die kennis wordt later het script, het draaiboek en de lat waarlangs je aanneemt. Sla het over en je eerste salesaanname erft een gok. Het goede nieuws: als oprichter heb je een oneerlijk voordeel dat een verkoper nooit zal hebben. Jij hebt het ding gebouwd. Je kunt elke vraag beantwoorden, de roadmap tijdens een gesprek bijbuigen, en spreken met een geloofwaardigheid die geen vreemde met een quota kan faken. Jouw taak is om vaak genoeg voor de juiste persoon te komen zodat dat voordeel gaat tellen. ## Stap 1: Bepaal wie de ene persoon is die ja kan zeggen De meest voorkomende reden dat outreach mislukt, is dat hij de verkeerde rol bereikt. Je bericht wordt niet afgewezen — het komt terecht bij iemand die nooit de bevoegdheid had om ernaar te handelen, en het sterft in stilte. In de meeste bedrijven zitten er drie soorten mensen tussen jou en een deal: - **De ambassadeur** — voelt de pijn die jouw product oplost en wil dat opgelost hebben. Vaak niet senior, maar wel de persoon die jouw zaak intern zal dragen. - **De economische koper** — beheert het budget en kan de uitgave goedkeuren. Dit is degene die uiteindelijk ja zegt. - **De blokkeerder / poortwachter** — inkoop, een directiesecretaresse, IT, of een sceptische luitenant wiens taak het is om ruis te filteren. Niet je vijand, maar ook niet je doelwit. Voordat je iemand benadert, beslis op wie je mikt en waarom. Voor een eerste gesprek wil je meestal de ambassadeur of de economische koper — nooit een willekeurige medewerker wiens naam je vond omdat hij makkelijk te vinden was. De verkeerde persoon bereiken verspilt niet alleen het bericht; het kan de account verbranden, want nu is jouw naam verbonden aan een verkeerd gerichte koude pitch. Als je niet kunt verwoorden waarom een specifieke persoon het juiste contact is, ben je nog niet klaar om te benaderen. ## Stap 2: Doe genoeg onderzoek om een antwoord te verdienen Contactonderzoek is niet "een e-mailadres vinden." Het is genoeg context verzamelen dat je bericht alleen aan die ene persoon geschreven had kunnen zijn. Dat is wat een antwoord verdient in een inbox die vijftig pitches per week krijgt. Voordat je iets opstelt, weet: 1. **De trigger** — waarom nu? Een financieringsronde, een nieuwe aanname in een relevante rol, een productlancering, een publieke klacht, een vacature die een hiaat blootlegt. Een reden waarom de timing logisch is voor *hen*. 2. **De specifieke pijn** — niet "bedrijven zoals dat van jou worstelen met X," maar bewijs dat *dit* bedrijf dat doet. 3. **Het verbindende weefsel** — een gedeelde connectie, een klant in hun vakgebied, iets dat je opmerkte dat een sjabloon niet kon faken. Openbare bronnen leveren je het meeste hiervan zonder enige speciale tools: de eigen site en carrièrepagina van het bedrijf, LinkedIn, recente pers, podcastoptredens, kwartaalcijfergesprekken voor beursgenoteerde bedrijven, en communities waar je koper echt rondhangt. Als je de markt goed hebt gevalideerd, deed je een deel van dit werk al — zie [Hoe je een bedrijfsidee valideert voordat je het bouwt](/how-to-validate-a-business-idea/) voor het vraag- en concurrentieonderzoek dat tegelijk als sales-intel dient. De test of je genoeg hebt gedaan: zou je de eerste twee zinnen van het bericht zo kunnen schrijven dat ze *geen enkele zin* hebben als ze naar een ander bedrijf werden gestuurd? Zo ja, dan ben je klaar. Als je opener voor honderd bedrijven zou werken, blijf onderzoeken. ## Stap 3: Stem je kanalen op elkaar af — e-mail, telefoon, LinkedIn Er is geen enkel beste kanaal. Er is een beste kanaal voor elk moment. De fout is er één kiezen en erop blijven hameren. De vaardigheid is ze zo op elkaar afstemmen dat elk de taak doet waar het echt goed in is. | Kanaal | Beste toepassing | Risico bij verkeerd gebruik | | --- | --- | --- | | E-mail | De primaire vraag, de gedetailleerde follow-up, alles wat de koper intern moet doorsturen | Meteen genegeerd als het als een sjabloon leest | | Telefoon | Tijdgevoelige follow-up, het inplannen van een geboekte-maar-afdrijvende deal, een warme doorverwijzing waarvan je te horen kreeg te bellen | Voelt opdringerig zonder voorafgaande context of reden | | LinkedIn | Zachte eerste aanraking, een koud contact opwarmen, zichtbaar blijven tussen e-mails door | Druk, traag, makkelijk om op elke andere pitch te lijken | | Warme introductie | Alles, wanneer je er een kunt krijgen | De geloofwaardigheid van de doorverwijzer staat op het spel — verspil die niet | Een sequentie die in de praktijk werkt: open met een korte, specifieke e-mail die aansluit op de trigger die je vond. Als er geen antwoord komt, voeg waarde toe op LinkedIn — een oprechte reactie, een nuttige bron, een connectieverzoek met context — zodat je naam geen koude verrassing is. Escaleer alleen naar een telefoontje wanneer er een echte reden is: een deadline, een doorverwijzing, een deal die stil viel na interesse. Een telefoontje uit het niets, naar iemand die je naam nog nooit heeft gehoord, is de snelste manier om als spam te worden opgeborgen. En geef altijd de voorkeur aan de warme introductie wanneer je er een kunt verdienen. Eén introductie van iemand die de koper vertrouwt, presteert beter dan twintig perfect opgestelde koude e-mails. Steek echte moeite in het in kaart brengen van wie in je netwerk welke deur kan openen voordat je koud gaat. ## Stap 4: Schrijf het bericht dat antwoord krijgt Zodra je het recht hebt verdiend om te benaderen, houd het bericht kort en maak het makkelijk om ja te zeggen. Lange pitches van vreemden worden niet gelezen; ze worden gearchiveerd. Een goede koude e-mail doet vier dingen in minder dan 90 woorden: 1. **Noemt de trigger** — bewijst dat je oplet en dat dit geen massamail is. 2. **Benoemt de relevante pijn** — één zin, geformuleerd als de hunne, niet de jouwe. 3. **Doet één kleine vraag** — een gesprek van 15 minuten, niet "laten we een partnerschap verkennen." 4. **Geeft een makkelijke uitweg** — "Als jij dit niet bent, kun je me dan doorverwijzen naar wie het onder zich heeft?" Hier is de vorm: > "Hoi Priya — ik zag dat jullie net twee vacatures hebben geopend in het RevOps-team, wat meestal betekent dat rapportage sneller pijnlijk wordt dan personeel het kan oplossen. Wij helpen Series-B-teams de tijd voor handmatige rapportage met zo'n 60% terug te brengen zonder hun stack eruit te rukken. Zijn 15 minuten volgende week het waard om te kijken of het relevant is? En als dit niet jouw gebied is, zou ik dankbaar zijn voor een verwijzing naar wie het onder zich heeft." Dat is specifiek, respectvol met hun tijd, en triviaal makkelijk te beantwoorden — zelfs de "nee" is nuttig, want die stuurt je door naar de juiste persoon. Dezelfde discipline geldt over alle kanalen; als je de diepere mechaniek wilt van outreach op schaal zonder gemarkeerd of genegeerd te worden, heb ik dat uiteengezet in [Een succesvolle outreachstrategie opbouwen](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/). ## Stap 5: Bereid je voor alsof het gesprek het enige is dat je krijgt Toegang geeft je de opening. Voorbereiding verdient de volgende stap. Oprichters vechten routineus weken voor een gesprek, en lopen dan naar binnen zonder de wereld van de koper doordacht te hebben — en de deal sterft niet aan gebrek aan interesse maar aan gebrek aan gereedheid. Voor elk gesprek moet je koud kunnen beantwoorden: - Hoe ziet de dag van deze persoon eruit, en waar past mijn product daarin? - Wat is het ene resultaat waar ze om geven en dat ik kan beïnvloeden? - Wat zijn de twee bezwaren die ze zullen opwerpen, en wat is mijn eerlijke antwoord? - Wat is de kleinste volgende stap die ik kan vragen als ze geïnteresseerd zijn maar nog niet klaar? Jij hebt het product gebouwd, dus de demo is makkelijk. Het moeilijke deel is de prioriteiten van de koper in je hoofd houden in plaats van de jouwe. De oprichters die outreach in omzet omzetten, zijn degenen die binnenkomen alsof ze het bedrijf al begrijpen — want ze deden het werk in Stap 2. ## Wanneer je niet moet benaderen Agressieve outreach verbrandt meer pijplijn dan het bouwt. Sla de koude aanraking over — of vertraag — wanneer: - Je niet kunt benoemen waarom deze specifieke persoon het juiste contact is. - Je al meer dan twee keer hebt opgevolgd zonder reactie. (Ga verder; de markt is groot.) - Je opener verstuurd naar honderd andere bedrijven zou werken. - Je zou bellen buiten normale kantooruren of zonder voorafgaande context. - De enige reden dat je deze persoon koos, is dat hun contactgegevens makkelijk te vinden waren. Goede outreach voelt als een goed getimede, relevante notitie van iemand die zijn huiswerk deed. Slechte outreach voelt als spam met betere targeting. Het verschil zit volledig in het onderzoek en de terughoudendheid. ## De founder-led sales-stack De tools en gewoontes waarop ik hiervoor leun, waarvan geen enkele een salesteam vereist: - **Onderzoek:** de eigen site en carrièrepagina van het bedrijf, LinkedIn, recente pers, en de communities waar je kopers echt praten - **CRM:** alles wat je daadwerkelijk zult bijwerken — een simpel Notion-bord of Airtable verslaat een enterprise-CRM dat je negeert - **Sequencing:** een lichtgewicht tracker voor wie in welke fase zit en wat de volgende aanraking is, zodat niets afdrijft - **E-mail:** een echt, opgewarmd verzendadres en platte-tekstberichten — geen afbeeldingen, geen tracking pixels, niets dat "campagne" schreeuwt - **Agenda:** een boekingslink zodat een "ja" met één klik in een gesprek verandert in plaats van vijf antwoordmails ## De conclusie van de operator Je hebt geen salesteam nodig om te beginnen met verkopen. Je moet precies weten wie ja kan zeggen, genoeg onderzoek doen zodat je bericht alleen aan hen geschreven had kunnen zijn, en je kanalen zo op elkaar afstemmen dat elk zijn werk doet. E-mail draagt de vraag, LinkedIn warmt de grond op, de telefoon dicht een tijdgevoelig gat, en een warme introductie verslaat ze allemaal. Doe de reps lang genoeg zelf om te leren wat echt landt — en dan, en pas dan, geef je dat zwaarbevochten draaiboek aan je eerste aanname. --- **Gerelateerd:** [Een succesvolle outreachstrategie opbouwen](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/) · [Hoe je een bedrijfsidee valideert](/how-to-validate-a-business-idea/) · [Gids voor growth-marketingstrategieën](/growth-marketing-strategies-guide/) --- ## Hoe je een solopreneur-bedrijf opbouwt: de gids voor 2026 Source: https://alejandrorioja.com/nl/how-to-build-a-solopreneur-business/ Published: 2026-07-07 Tags: Entrepreneurship, Growth TL;DR: Kies één bedrijfsmodel (content, diensten, SaaS of digitale producten), bouw een publiek op rondom één niche en voeg daarna pas secundaire inkomstenstromen toe zodra het primaire model converteert. De valkuil is alle vier tegelijkertijd proberen — kies het model dat aansluit bij wat je al weet, niet wat het meest passief klinkt. ## Inhoudsopgave _Bijgewerkt juli 2026._ **TL;DR:** Kies één bedrijfsmodel (content, diensten, SaaS of digitale producten), bouw een publiek op rondom één niche en voeg daarna pas secundaire inkomstenstromen toe zodra het primaire model converteert. De valkuil is alle vier tegelijkertijd proberen — kies het model dat aansluit bij wat je al weet, niet wat het meest passief klinkt. **[Mening van de operator]** Ik heb deze site gerund, cursussen verkocht en affiliate-inkomsten beheerd voor jaren zonder fulltime medewerker. Niets van dit alles begon met een groot plan — het begon met één ding dat werkte, en daarna bewuste uitbreiding. Deze gids is wat ik had willen lezen voordat ik alles tegelijk probeerde te doen. ## Wat een solopreneur-bedrijf echt is Een solopreneur runt een bedrijf alleen — geen medeoprichters, geen medewerkers, misschien contractors wanneer het volume dat vereist. Het doel is een bedrijf dat draait op expertise en systemen, niet op headcount. Dit verschilt van freelancen. Een freelancer verkoopt tijd. Een solopreneur bouwt systemen die inkomsten genereren zonder dat zijn tijd nodig is voor elke verdiende euro. ## De 4 solopreneur-bedrijfsmodellen Elk eenpersoonsbedrijf past ruwweg in een van deze: 1. **Contentbedrijf.** Je publiceert (blog, nieuwsbrief, YouTube, podcast) en monetariseert via advertenties, affiliate-inkomsten, sponsoring en eigen producten. Laagste drempel, langste opstartperiode. 2. **Servicebedrijf.** Je levert een specifiek resultaat aan klanten — consultancy, fractionele rollen, done-for-you diensten. Snelste weg naar €10.000/maand, minst schaalbaar. 3. **Digitale producten.** Cursussen, templates, ebooks, tools. Hoog leverage eenmaal gebouwd, moeilijk traffic te genereren zonder bestaand publiek. 4. **Micro-SaaS.** Een klein softwareproduct dat één specifiek probleem oplost. Hoogste plafond, hoogste technische lat. Het juiste model hangt af van wat je al hebt: vaardigheden, een publiek of kapitaal. ## Stap 1: Kies je niche met echte diepgang Brede niches (marketing, financiën, gezondheid) hebben traffic maar genadeloze concurrentie. Smalle niches (AI-tools voor e-commerce ondernemers, persoonlijke financiën voor nieuwe verpleegkundigen) converteren beter en ranken sneller. De test die ik gebruik: kan ik 50 echt nuttige stukken content over dit onderwerp schrijven zonder door mijn ideeën heen te raken? Zo ja, dan heeft de niche diepgang. Als ik moeite heb om 20 te noemen, is het te smal of weet ik het niet goed genoeg. Je niche moet zich bevinden op het snijvlak van: - Iets wat je kent uit ervaring, niet alleen uit onderzoek - Een publiek met geld of tijd om te besteden - Een probleem dat terugkeert, geen eenmalige oplossing ## Stap 2: Bouw je publiek op voordat je het nodig hebt De grootste fout die ik zie: een product lanceren voor een publiek van nul. Publiek voor product is de regel. Dit werkt echt: 1. **Kies één distributiekanaal en ga er diep in.** Blog + SEO is langzaam maar duurzaam. Een nieuwsbrief is snel te monetariseren. Korte video heeft een hoog plafond maar is algoritme-afhankelijk. Verdeel je aandacht in het eerste jaar niet over vier platforms. 2. **Publiceer consistent voordat je iets te verkopen hebt.** Het publiek dat je opbouwt terwijl je niets te verkopen hebt, vertrouwt je wanneer je dat eindelijk doet. 3. **Bouw vanaf dag één een e-maillijst op.** Sociale media volgers zijn gepacht land. Je e-maillijst is van jou. Ik gebruik [ConvertKit](/recommends/convertkit) — het verwerkt reeksen en uitzendingen zonder in de weg te staan. Een handig referentiepunt: 1.000 echte fans (e-mailabonnees die elke e-mail openen) is genoeg om €100.000/jaar te genereren uit digitale producten. ## Stap 3: Optimaliseer eerst je primaire inkomstenstroom Zodra je een publiek hebt (of een klant van een dienst), zet alles in op de primaire inkomstenstroom voordat je secundaire toevoegt. **Voor contentbedrijven:** affiliate-inkomsten zijn de snelste eerste euro. Je schrijft over tools die je gebruikt, linkt via je aanbevelingspagina en verdient een percentage. Geen product om te bouwen, geen klantenondersteuning. Het plafond is reëel — een website met veel traffic in een lucratieve niche kan €5.000–€30.000/maand verdienen — maar het is het beste bootstrap-mechanisme dat ik heb gevonden. **Voor servicebedrijven:** reken meer aan dan comfortabel voelt. Onderprijzen is de meest voorkomende solopreneur-fout. Als je een sluitingspercentage van 100% hebt, ben je te goedkoop. **Voor digitale producten:** houd de scope strak. Een gefocuste cursus van €97 presteert beter in conversie- en voltooiingspercentage dan een uitgebreide cursus van €497. **Voor Micro-SaaS:** bouw voor pijn die je persoonlijk ervaart. Het empathievoordeel is reëel wanneer je je eigen doelklant bent. ## Stap 4: Stapel secundaire inkomstenstromen Zodra je primaire model converteert, voeg inkomstenstromen toe die geen proportionele tijd vereisen: - **Affiliate-inkomsten** — zelfs servicebedrijven en SaaS-operators kunnen affiliate-inkomsten verdienen uit hun content - **Digitale producten** — zelfs als je primair een servicebedrijf bent, kan een cursus of templateset verdienen terwijl je slaapt - **Sponsoring** — zodra je publiek boven de ~5.000 betrokken abonnees uitkomt - **Licentieverlening** — als je een systeem of tool hebt gebouwd, geef het in licentie aan anderen in aangrenzende niches Stapelen is een resultaat, geen strategie. Laat eerst één stroom werken. ## De solopreneur tech-stack Ik run deze hele operatie op zes tools: | Tool | Wat het doet | |---|---| | [Claude](/recommends/claude) | Eerste concepten voor content, e-mails en code | | [ConvertKit](/recommends/convertkit) | E-maillijst, automatiseringen en uitzendingen | | [Notion](/recommends/notion) | Redactionele kalender, klantdocumenten en SOP's | | [Canva](/recommends/canva) | Sociale media-afbeeldingen en thumbnail-ontwerp | | [Airtable](/recommends/airtable) | Affiliate tracking, CRM, content database | | [SEMrush](/recommends/semrush) | Zoekwoordonderzoek en ranglijsttracking | Totale maandelijkse kosten: onder de €300. Een team dat deze stack zou vervangen, zou €15.000+ per maand aan salarissen kosten. ## De 3 fouten die solopreneur-bedrijven doden 1. **Vroegtijdig opschalen.** Aannemen voordat het bedrijfsmodel is bewezen, verbrandt resources en voegt managementoverhead toe voordat je herhaalbare inkomsten hebt. 2. **Te vroeg diversifiëren.** Vier half werkende inkomstenstromen verdienen minder dan één volledig geoptimaliseerde. Ga in het eerste jaar dieper, niet breder. 3. **Bouwen zonder distributie.** Het beste product zonder publiek verslaat geen middelmatig product met een grote betrokken lijst. Distributie is de slotgracht. ## De conclusie van de operator Een solopreneur-bedrijf is een bewuste keuze om teamcomplexiteit in te ruilen voor eigendom en marge. De bedrijven die ik consistent heb zien werken, delen hetzelfde patroon: één model, één niche, één distributiekanaal, lang genoeg vastgehouden om samen te werken. Kies het model dat aansluit bij je bestaande vaardigheden. Bouw het publiek op voordat je het nodig hebt. Voeg inkomstenstromen pas toe nadat de primaire converteert. De rest is uitvoering. --- **Gerelateerd:** [Hoe je een bedrijfsidee valideert](/how-to-validate-a-business-idea/) · [Hoe je een nieuwsbrief monetariseert](/how-to-monetize-a-newsletter/) · [Hoe je een persoonlijk merk opbouwt](/how-to-build-a-personal-brand/) --- ## Hoe je je kleine onderneming automatiseert met AI-agents: een praktische gids Source: https://alejandrorioja.com/nl/how-to-automate-your-small-business-with-ai-agents/ Published: 2026-07-04 Tags: AI Agents, Entrepreneurship, Operations TL;DR: Het automatiseren van een kleine onderneming met AI-agents gaat niet over het vervangen van mensen — het gaat over het delegeren van repetitief, regelgebaseerd werk zodat je je tijd kunt besteden aan beslissingen die alleen jij kunt nemen. Begin met één taak, log alles, houd mensen in de loop voor alles wat rechtstreeks geld of klanten raakt, en breid van daaruit uit. De stack die ik gebruik in twee bedrijven kost minder dan $100 per maand in totaal. ## Inhoudsopgave _Bijgewerkt juli 2026._ **TL;DR:** Het automatiseren van een kleine onderneming met AI-agents gaat niet over het vervangen van mensen — het gaat over het delegeren van repetitief, regelgebaseerd werk zodat je je tijd kunt besteden aan beslissingen die alleen jij kunt nemen. Begin met één taak, log alles, houd mensen in de loop voor alles wat rechtstreeks geld of klanten raakt, en breid van daaruit uit. De stack die ik gebruik in twee bedrijven kost minder dan $100 per maand in totaal. **Operatorsnotitie:** Ik run twee bedrijven — een negen-baan indoor pickleball-faciliteit in Pflugerville, TX (Pickleland) en een consultancymerk. Samen heb ik meer dan 30 AI-agents in productie die alles afhandelen, van reacties op sociale media-opmerkingen tot evenementpromotie, nieuwsbriefconcepten en boekingsopvolgingen. Dit is de onverbloemde gids over wat echt werkt, wat tijd verspilt en hoe je begint zonder een ontwikkelaar in te huren. De eerlijke framing: AI-agents voor kleine ondernemingen zijn geen magie. Ze vervangen niet het harde werk van klantrelaties, productkwaliteit of strategisch oordeel. Wat ze doen, is de administratieve sleur elimineren die elke operator twee tot drie uur per dag kost — het sorteren van de inbox, kopieer-plak-rapporten, sociale reacties, dataformattering. Dat is genoeg om het verschil te maken. ## De 4 soorten werk die zich goed automatiseren Voordat je iets bouwt, breng je je werklast in kaart in vier categorieën. Slechts één daarvan is geschikt voor AI-agents. ### 1. Regelgebaseerd, repetitief, tekst in / tekst uit Dit is het optimale punt. Een klantenmail classificeren, een reactie op een sociale media-opmerking opstellen, een week reserveringen samenvatten in een lijst, een CSV omzetten naar een rapport. De input is tekst; de output is tekst; de regels zijn consistent. Deze taken automatiseren zich met één prompt en een dunne wrapper rond de API. **Voorbeelden van Pickleland:** - Inkomende baanvraag-e-mails classificeren (vraag / klacht / boeking / overig) - Facebook-groepsberichten opstellen voor aankomende evenementen - Wekelijkse bezettingsoverzichten genereren vanuit het boekingssysteem ### 2. Meerstaps-pipelines met duidelijke overdrachten Een taak met drie stappen — data ophalen, transformeren, een melding versturen — waarbij elke stap een duidelijke input en output heeft. Dit werkt goed met een lichte orchestratielaag (ik gebruik Cloudflare Workers Queues). De sleutel is dat elke stap onafhankelijk kan mislukken en opnieuw kan worden geprobeerd zonder het hele werk te herhalen. **Voorbeelden van Pickleland:** - Nieuwe boeking → CRM-update → bevestigingsmail → Slack-melding - Formulierinzending → classificatie → gerichte antwoordconcepten → menselijke reviewwachtrij ### 3. Monitoring en waarschuwingen Agents die een conditie in de gaten houden en je waarschuwen als die optreedt. Dit zijn enkele van de AI-automatiseringen met de beste ROI, omdat ze de cognitieve last van het handmatig controleren van dashboards vervangen. Ze zijn ook van de eenvoudigste: de logica is gewoon "Is X boven de drempel? Zo ja, waarschuw." **Voorbeelden van mijn consultancymerk:** - Google Analytics-anomaliemeldingen (verkeersval, piek) - Boekingsannuleringspercentage boven de wekelijkse basiswaarde - Nieuwe recensie gepubliceerd — markeren voor menselijke reactie ### 4. Eerste inhoudsconcepten (niet het eindproduct) AI-agents kunnen sociale berichten, e-mailnieuwsbrieven, blogschema's en productbeschrijvingen van nuttige kwaliteit opstellen. Het addertje: ze kunnen je redactioneel oordeel niet vervangen. Elk concept doorloopt een menselijke reviewstap. De ROI komt van beginnen op 70% in plaats van een leeg scherm. **Wat NIET goed automatiseert:** klantrelatiebeheer, prijsbeslissingen, verkoopgesprekken, werving en alles waarbij de verkeerde output echte kosten heeft voor een echte persoon. Houd mensen bij die taken. ## De stack die ik echt gebruik Je hebt geen enterprise-software nodig voor dit. Dit is wat mijn automatiseringen aandrijft: 1. **[Claude](/recommends/claude)** — de modellaag voor alle AI-taken. Ik gebruik de API direct, geen GUI. De kwaliteit per dollar is de beste die ik heb getest, en [promptcaching](/prompt-caching-cut-your-claude-costs-without-switching-models/) verlaagt de kosten verder wanneer systeemprompts herhalen. 2. **Cloudflare Workers** — waar de agents leven. Serverloos, wereldwijd gedistribueerd, en de gratis laag dekt de meeste werklasten van kleine bedrijven. De `scheduled`-handler voert cron-taken uit; de `fetch`-handler ontvangt webhooks voor event-getriggerde flows. 3. **Airtable** — de dataruggegraat. Elke agent leest en schrijft naar Airtable-tabellen. Hier leven taakstatus, reviewwachtrijen en operationele gegevens. Niet-ontwikkelaars kunnen de data bewerken zonder code aan te raken. 4. **Kit (voorheen ConvertKit)** — e-mail- en nieuwsbriefautomatisering. Mijn nieuwsbriefconceptagent schrijft naar een Kit-concept; ik beoordeel en verzend. Totale maandelijkse kosten voor 30+ agents in twee bedrijven: minder dan $100. De grootste post is het Claude API-gebruik. Al het andere is gratis laag of bijna gratis. ## Echte voorbeelden: Pickleland-automatiseringen ### De evenementpromotor Elke zondag controleert een geplande agent het boekingssysteem op evenementen in de komende vier dagen. Hij koppelt elk evenement aan de relevante lokale Facebook-groepen en stelt een passend promobericht op voor elk ervan. De concepten gaan naar een Airtable-reviewtabel. Ik besteed vijf minuten aan beoordelen en klikken op "Goedkeuren" — de agent doet de 40 minuten aan opstellen. Niets wordt automatisch geplaatst zonder mijn goedkeuring. Dit is het [geplande agentpatroon](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) — het loopt op een schema, doet batchwerk en presenteert concepten voor menselijke beoordeling. ### De sociale opmerkingsclassificator Wanneer een nieuwe opmerking binnenkomt op een gemonitord Facebook-bericht, wordt een webhook geactiveerd en classificeert de agent de intentie: vraag, klacht, compliment of spam. Voor vragen en klachten boven een betrouwbaarheidsdrempel stelt hij een antwoord op en markeert het voor beoordeling. Complimenten worden gelogd. Spam wordt onderdrukt. Een ronde van 30 seconden van opmerking tot concept. Zonder de agent was elke opmerking een handmatige contextwissel; nu duurt de wachtrij van vooraf opgestelde antwoorden vijf minuten in plaats van dertig. Dit is het [event-getriggerde agentpatroon](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) — geactiveerd door webhook, moet snel reageren. ### Het wekelijkse operationele overzicht Elke maandagochtend haalt een agent de boekingsgegevens van de vorige week op, het annuleringspercentage, de bezetting per baantype en eventuele gemelde anomalieën. Hij formatteert een samenvatting van vijf punten en deponeert deze in een Notion-pagina. Ik lees het met mijn koffie en heb de operationele context die ik voor de week nodig heb in twee minuten in plaats van twintig. ## Waar te beginnen: 4 stappen ### Stap 1: Kies de repetitieve taak met de meeste wrijving die je elke week doet Niet de meest glamoureuze, niet de meest strategische — degene waar je het meest over klaagt. Het wekelijkse rapport dat je uit drie bronnen kopieert en plakt. De sociale reacties waar je een uur aan besteedt. De opvolgingsmails die je één voor één verstuurt. Dat is je eerste agent. ### Stap 2: Breng de taak in kaart in inputs en outputs Schrijf op: - Wat de taak activeert (een klok, een event, een formulierinzending) - Welke inputs het nodig heeft (databronnen, tekst, context) - Wat de output is (een concept, een melding, een databaserij) - Wat de menselijke reviewstap is (elke eerste agent zou er een moeten hebben) Als je het niet duidelijk kunt in kaart brengen, is de taak niet goed genoeg gedefinieerd om te automatiseren. Verduidelijk het proces eerst handmatig. ### Stap 3: Bouw de kleinst mogelijke versie Geen systeem. Één prompt, één API-aanroep, één output. Een TypeScript-functie die de input neemt, Claude aanroept en het concept teruggeeft. Geen database, geen webhook, geen wachtrij — alleen de kernlogica. Voer het vijf keer handmatig uit. Houdt de outputkwaliteit stand? Zo ja, heb je een werkende agent. Voeg dan de infrastructuur toe. ```typescript // De eenvoudigste eerste agent: concept evenementpromo async function draftEventPromo(event: PadklelandEvent, env: Env): Promise { const msg = await env.ANTHROPIC.messages.create({ model: "claude-opus-4-8", max_tokens: 400, system: `You write Facebook event promo posts for Pickleland, an indoor pickleball facility in Pflugerville, TX. Tone: friendly, local, community-focused. Max 150 words.`, messages: [ { role: "user", content: `Write a promo post for this event: ${JSON.stringify(event)}`, }, ], }); return (msg.content[0] as { text: string }).text; } ``` ### Stap 4: Voeg observability toe voordat je meer functies toevoegt Log elke uitvoering met een trace-ID. Log de input, de output en het tijdstempel. Je hebt geen geavanceerd hulpmiddel nodig — gestructureerd JSON naar stdout is voldoende om te beginnen. De reden: je eerste agent zal op manieren falen die je niet had voorzien. Als dat gebeurt, moet je kunnen zien wat er is misgegaan zonder de toestand uit het geheugen te reconstrueren. Dit is de gewoonte die operators die hun agentstack opschalen onderscheidt van operators die opgeven na één slechte ervaring. Ik ga er dieper op in bij [hoe je een AI-agent in productie debugt](/how-to-debug-an-ai-agent-in-production/). ## Veelgemaakte fouten (en hoe je ze vermijdt) **Automatiseren voordat je het proces begrijpt.** Als je de taak zelf niet consistent kunt uitvoeren, zal een AI-agent het gewoon inconsistent op grote schaal doen. Documenteer het proces eerst handmatig, dan automatiseer. **De menselijke reviewstap te vroeg verwijderen.** Begin elke agent met een human-in-the-loop review. Laat het twee weken draaien, controleer elke output en bouw vertrouwen op voordat je iets volledig geautomatiseerd laat lopen. De uitzondering zijn laagrisico, gemakkelijk omkeerbare acties (zoals een concept naar een map schrijven). **Het hele systeem bouwen voordat de kern is gevalideerd.** Bouw eerst de eenvoudigste mogelijke versie. Als de kernkwaliteit er niet is met één prompt, zal meer infrastructuur het niet oplossen. **Kosten negeren.** AI API-kosten schalen met gebruik. Ken je kosten per uitvoering voordat je op volume inzet. De [Haiku vs Sonnet kostenberekening](/ai-agent-cost-math-when-haiku-beats-sonnet/) doet ertoe als je duizenden uitvoeringen per week doet. **Fouten behandelen als catastrofes.** Agents falen. Prompts regresseren. API's gaan offline. Bouw retry-logica, bouw [evaluatieharnesses](/the-eval-harness-i-use-to-ship-ai-agents/) en behandel fouten als data, niet als rampen. ## De mindsetverschuiving die alles verandert Het knelpunt in een kleine onderneming is bijna nooit geld — het is de tijd en aandacht van de eigenaar. Elk uur dat je besteedt aan taken die een agent kan afhandelen, is een uur dat je niet hebt besteed aan klanten, product of strategie. Het kader dat ik gebruik: als een taak kan worden beschreven als een herhaalbaar proces met duidelijke inputs en outputs, is het een kandidaat voor een agent. Alles wat oordeel, relatie of creativiteit vereist, blijft bij mij. De agent handelt het eerste af zodat ik me op het tweede kan concentreren. Beginnen met AI-agents vereist geen technische medeoprichter, een zescijferig softwarebudget of maanden bouwen. Het vereist het kiezen van een taak met veel wrijving, het bouwen van de kleinste versie die werkt en het leren van de output. De meeste operators vinden hun eerste werkende agent in een weekend. Daarna duurt de tweede een middag. ## FAQ ### Hoeveel kost het uitvoeren van AI-agents voor een kleine onderneming? Mijn stack voert 30+ agents uit voor minder dan $100/maand. De grootste kostenpost is het AI API-gebruik (Claude). Cloudflare Workers is gratis tot 100.000 verzoeken/dag en $5/maand daarna. Airtable heeft een gratis laag die de meeste databeloften van kleine bedrijven dekt. Kosten schalen met gebruik — een enkele agent die een paar keer per week draait is verwaarloosbaar. ### Heb ik een ontwikkelaar nodig om AI-agents te bouwen? Voor de basispatronen — een geplande cron, een webhook-handler, een eenvoudig prompt — red je het met een beetje JavaScript en de bereidheid om documentatie te lezen. Voor complexere pipelines, orchestratie en productieklare observability maakt een ontwikkelaar het werk sneller. Mijn cursus ([AI-agents voor beginners](/ai-agents-for-beginners-cowork-codex-guide/)) leert de no-code en low-code paden voor operators. ### Wat is de beste eerste AI-agent voor een kleine onderneming? Het wekelijkse operationele overzicht. Het draait op een schema, heeft duidelijke inputs (je databronnen), produceert een consistente output (een geformatteerde samenvatting) en heeft nul neerwaarts risico — als het concept fout is, lees je het gewoon niet. Het bouwt je intuïtie over wat agents wel en niet kunnen zonder risico voor klanten of operaties. ### Welk AI-model gebruik ik voor bedrijfsautomatisering? Ik gebruik Claude voor bijna al mijn agentwerk. De API-kwaliteit, betrouwbaarheid en operatorvriendelijke prijsstelling (met name met [promptcaching](/prompt-caching-cut-your-claude-costs-without-switching-models/)) maken het de juiste keuze voor productiegebruik. Voor goedkope, hoogvolume classificatietaken is Claude Haiku 4.5 snel en goedkoop. Voor opstellen en genuanceerde taken Claude Sonnet of Opus. ### Hoe voorkom ik dat AI-agents fouten maken die mijn bedrijf schaden? Drie praktijken: houd mensen in de loop voor alles wat klanten of geld rechtstreeks raakt; log elke uitvoering zodat je kunt traceren wat er mis is gegaan; en bouw een [evaluatieharness](/the-eval-harness-i-use-to-ship-ai-agents/) zodat wijzigingen in je prompts de productie niet stilletjes breken. Begin met laagrisico interne taken en breid alleen uit nadat je vertrouwen hebt in de outputkwaliteit. --- ## Hoe je een persoonlijk merk online opbouwt: Het praktijkhandboek 2026 Source: https://alejandrorioja.com/nl/how-to-build-a-personal-brand/ Published: 2026-07-02 Tags: Entrepreneurship, Growth TL;DR: Een persoonlijk merk wordt gebouwd door een specifiek publiek te kiezen, consequent nuttige content te publiceren op één kanaal en een duidelijk standpunt te hebben — niet door je LinkedIn-bio te optimaliseren. Versmall je niche, schrijf vanuit echte ervaring, bouw een e-maillijst als enig eigen kanaal en herhaal totdat de juiste mensen je niet meer kunnen negeren. ## Inhoudsopgave _Bijgewerkt juli 2026._ **TL;DR:** Een persoonlijk merk wordt gebouwd door een specifiek publiek te kiezen, consequent nuttige content te publiceren op één kanaal en een duidelijk standpunt te hebben — niet door je LinkedIn-bio te optimaliseren. Versmall je niche, schrijf vanuit echte ervaring, bouw een e-maillijst als enig eigen kanaal en herhaal totdat de juiste mensen je niet meer kunnen negeren. **[Praktijknoot]** Ik heb in het openbaar gebouwd via meerdere bedrijven — Pickleland, AI-agenten consultancy, deze site — en het patroon dat ik steeds zie is hetzelfde: de mensen die herkenbare persoonlijke merken bouwen, zijn niet de meest getalenteerde. Ze zijn het meest specifiek en het meest consistent. Hier is het framework dat ik gebruik en aanbeveel. ## Wat een persoonlijk merk werkelijk is (en wat niet) Een persoonlijk merk is het antwoord op één vraag: *Wat zeggen mensen over jou als je niet in de kamer bent?* Het is niet je logo. Het is niet je kleurenpalet. Het is niet hoeveel volgers je hebt. Een persoonlijk merk is de mentale snelkoppeling die mensen vormen wanneer ze je naam horen — het specifieke probleem waarvan ze denken dat jij het kunt oplossen, het perspectief dat ze van je verwachten. De fout die de meeste mensen maken: ze proberen een merk te bouwen voordat ze een standpunt hebben ontwikkeld. Een merk is wat zich opbouwt door echte dingen te doen en specifiek te zijn over wat je hebt geleerd — niet iets wat je van tevoren fabriceert. Wat je van begin af aan kunt beheersen: 1. Met wie je praat 2. Welk probleem je voor hen oplost 3. Waar ze je vinden 4. Hoe consequent je aanwezig bent Wat zich in de loop van de tijd opbouwt: - Een reputatie voor een specifiek soort expertise - Een publiek dat je oordeel vertrouwt - Inkomende kansen die je niet hoefde na te jagen ## Stap 1: Kies de smalste niche waarmee je kunt leven De meest voorkomende fout bij persoonlijk merkopbouw is te breed zijn. "Marketingexpert." "Bedrijfsadviseur." "Tech-ondernemer." Dit zijn betekenisloze labels in een wereld waar iedereen ze heeft. Hoe smaller je gaat, hoe sneller je een reputatie opbouwt. Test je niche met dit filter: - **Specifiek genoeg om vindbaar te zijn.** Kan iemand je niche googelen en een echte community eromheen vinden? - **Specifiek genoeg om aanbevelbaar te zijn.** Als iemand een persoon ontmoet met precies jouw probleem, denken ze dan eerst aan jou? - **Breed genoeg om 2+ jaar content te produceren.** Gebruik een zoekwoordtool zoals [Semrush](/recommends/semrush) om te controleren of je niche wordt gezocht. ## Stap 2: Kies één primair kanaal Proberen overal tegelijk te zijn is een gegarandeerde manier om overal middelmatig te zijn. Kies aan het begin één kanaal en ga de diepte in. - **Geschreven content (blog/nieuwsbrief):** Het beste voor analytische, praktijkgerichte doelgroepen. Renteert in de loop van de tijd via SEO. - **LinkedIn:** Het beste voor B2B- en professionele doelgroepen. - **YouTube / video:** Het beste voor onderwerpen die profiteren van visuele demonstratie. - **X / Twitter:** Het beste voor ideeën die verspreiden. ## Stap 3: Vind je standpunt Content zonder standpunt is ruis. Wat persoonlijke merken onderscheidt die worden geciteerd, aanbevolen en gezocht, is een onderscheidend perspectief — een mening over hoe de wereld werkt, geïnformeerd door echte ervaring. Een sterk POV heeft deze eigenschappen: - Het is gebaseerd op iets wat je echt hebt gedaan, niet alleen gelezen - Het daagt minstens één conventionele aanname van je publiek uit - Het is specifiek genoeg dat sommige mensen het er niet mee eens zullen zijn ## Stap 4: Bouw een eigen publiek op Elk platform waarop je bouwt kan zijn algoritme wijzigen, je account verbannen of sluiten. Het enige distributiekanaal dat je echt bezit, is je e-maillijst. Begin er vanaf dag één mee te bouwen. Voor e-mail gebruik ik [ConvertKit](/recommends/convertkit) — speciaal gebouwd voor creator-nieuwsbrieven. De snelste manier om een e-maillijst te laten groeien: 1. **Maak een oprecht nuttige lead magnet.** Een checklist, sjabloon of korte gids die een specifiek probleem oplost. 2. **Voeg de opt-in boven de vouw toe op elke contentpagina.** 3. **Schrijf een welkomstsequentie van 3 e-mails.** 4. **Vermeld de lijst in elk stuk content.** ## Stap 5: Publiceer consequent — de samengestelde rente-wiskunde Als je één lang stuk per week publiceert: - **Weken 1–8:** Bijna niemand leest het. Dat is normaal. - **Maanden 3–4:** Sommige stukken beginnen organisch verkeer te krijgen. - **Maanden 6–9:** Zoekverkeer accumuleert zich. Inkomende verzoeken beginnen te verschijnen. - **Jaar 2:** Je hebt 100 stukken content. Je naam verschijnt in zoekopdrachten en AI-antwoorden. Mijn regel: commit je voor 6 maanden voordat je beoordeelt of het werkt. ## Hoe ik denk over visueel merk Het minimale levensvatbare visuele merk: - Een professionele profielfoto waarop je gezicht duidelijk zichtbaar is - Een consistente profielfoto op alle platforms - Een eenvoudige website met een duidelijke tagline en e-mail opt-in [Canva](/recommends/canva) is prima voor social graphics en eenvoudig design. ## Veelgemaakte fouten 1. **Proberen iedereen aan te spreken.** Als je voor "ondernemers" schrijft, schrijf je voor niemand. 2. **Publiceren zonder distributie.** Een bericht schrijven en op verkeer wachten is geen strategie. 3. **Je focus elk kwartaal wijzigen.** De grootste killer van persoonlijk merkmomentum. 4. **IJdelheidscijfers meten.** Meet de grootte van je lijst en je conversieratio, niet je likes. 5. **Wachten tot je "expert genoeg" bent.** Je hoeft niet de wereldwijde autoriteit op je onderwerp te zijn. ## De persoonlijk merk-stack - **E-mailplatform:** [ConvertKit](/recommends/convertkit) - **SEO-onderzoek:** [Semrush](/recommends/semrush) - **Content creatie:** [Claude](/recommends/claude) - **Design:** [Canva](/recommends/canva) ## FAQ ### Hoe lang duurt het om een persoonlijk merk op te bouwen? Realistisch gezien 12–24 maanden consistent publiceren voordat je betekenisvolle inkomende kansen hebt. ### Moet ik op elk sociaal platform aanwezig zijn? Nee. Diepgang op één platform overtreft oppervlakkige aanwezigheid op vijf. ### Wat is belangrijker: contentkwaliteit of publicatiefrequentie? Beide, maar niet gelijkelijk. Kwaliteit stelt de bodem. Frequentie bepaalt of je de herhalingen krijgt die nodig zijn om te verbeteren. ### Moet ik mijn echte naam of een merknaam gebruiken? Gebruik je echte naam. Persoonlijke merken die aan een echte persoon zijn gekoppeld, overleven algoritmewijzigingen beter. ### Hoe monetariseer ik een persoonlijk merk? De vier betrouwbare wegen: (1) cursussen / digitale producten, (2) consultancy en advies, (3) affiliate-partnerschappen, en (4) gesponsorde content. --- **Gerelateerd:** [Hoe je een bedrijfsidee valideert voordat je het bouwt](/how-to-validate-a-business-idea/) · [Hoe je een e-maillijst van nul opbouwt](/how-to-build-an-email-list/) · [Hoe je een nieuwsbrief monetariseer](/how-to-monetize-a-newsletter/) --- ## Hoe je geheugen toevoegt aan een AI-agent: statuspersistentiepatronen voor productie Source: https://alejandrorioja.com/nl/how-to-add-memory-to-an-ai-agent/ Published: 2026-06-30 Tags: AI Agents TL;DR: Staatloze agents — degenen die alles vergeten wanneer de Worker stopt — zijn prima voor eenmalige taken. Op het moment dat een agent moet onthouden wat er gisteren is gebeurd, een terugkerende klant moet herkennen, of moet voortbouwen op eerdere output, heb je geheugen nodig. Er zijn drie patronen: werkgeheugen (context in vlucht, leeft in KV voor de duur van een run), episodisch geheugen (wat er is gebeurd en wanneer, een opvraagbaar logboek) en semantisch geheugen (wat je weet, opgehaald via vectorzoekopdrachten of gestructureerde gegevens). Koppel het juiste patroon aan de juiste taak. ## Inhoudsopgave _Bijgewerkt juni 2026._ **TL;DR:** Staatloze agents — degenen die alles vergeten wanneer de Worker stopt — zijn prima voor eenmalige taken. Op het moment dat een agent moet onthouden wat er gisteren is gebeurd, een terugkerende klant moet herkennen, of moet voortbouwen op eerdere output, heb je geheugen nodig. Er zijn drie patronen: werkgeheugen (context in vlucht, leeft in KV voor de duur van een run), episodisch geheugen (wat er is gebeurd en wanneer, een opvraagbaar logboek) en semantisch geheugen (wat je weet, opgehaald via vectorzoekopdrachten of gestructureerde gegevens). Koppel het juiste patroon aan de juiste taak. **[Operator-perspectief]** Ik ben meer dan eens tegen de staatloze muur opgelopen. De social reply-agent die zichzelf bleef voorstellen aan klanten met wie hij al 20 keer had gepraat. De dagelijkse briefing-agent die hetzelfde probleem vier dagen achter elkaar meldde omdat hij geen herinnering had aan het melden ervan gisteren. Het toevoegen van het juiste soort geheugen heeft beide opgelost. Dit is wat ik gebruik. ## Waarom staatloze agents blijven falen Een staatloze agent begint elke run alleen met wat je hem expliciet doorgeeft: de systeemprompt, het gebruikersbericht en welke gegevens je op het moment van aanroep ophaalt. Hij heeft geen bewustzijn van eerdere runs, eerdere gebruikers of eerdere beslissingen. Voor een eenmalige classificatietaak — een reactie lezen, een categorie teruggeven — is staatloze correct. Het is snel, goedkoop en voorspelbaar. Het faaloppervlak verschijnt zodra je continuïteit nodig hebt: - Een klantgerichte agent die de geschiedenis van de klant niet herkent - Een contentagent die een artikel aanbeveelt dat hij vorige week al aanbeveelde - Een moderatieagent die een opgelost geval blijft escaleren - Een dagelijkse briefing die dezelfde verouderde melding voor onbepaalde tijd toont Dit zijn allemaal symptomen van hetzelfde probleem: de agent heeft geen manier om context over runs heen te dragen. ## Drie soorten geheugen Het kader dat ik nuttig vind in productie: 1. **Werkgeheugen** — wat de agent _nu_ weet, tijdens een enkele run. Bewaard in KV of in het geheugen voor de levensduur van de aanroep. 2. **Episodisch geheugen** — wat er is gebeurd en wanneer. Een gestructureerd logboek dat de agent aan het begin van elke run leest om zich te oriënteren. 3. **Semantisch geheugen** — wat het weet over de wereld, klanten of een kennisbank. Opgehaald via gestructureerde query's of vectorzoekopdrachten wanneer relevant. Je hebt niet altijd alle drie nodig. De meeste agents die ik run hebben werkgeheugen + episodisch nodig. Semantisch geheugen is het moeilijkst te bouwen en verdient zijn plek pas wanneer de kennisbank te groot is om in het contextvenster te passen. ## Werkgeheugen: context in vlucht Werkgeheugen is een status die leeft gedurende de duur van één agent-run. De eenvoudigste vorm zijn variabelen in de functiescope. De interessantere vorm is een gedeelde KV-sleutel die subtaken binnen dezelfde run lezen en schrijven. Mijn social reply-agent gebruikt werkgeheugen om context te accumuleren terwijl hij een batch reacties in één wachtrij-bericht verwerkt. Hij leest aan het begin de recente gespreksgeschiedenis voor elke klant uit KV, voegt nieuwe context toe tijdens de verwerking en schrijft aan het einde terug. ```typescript // workers/social-reply.ts async function processComment( comment: SocialCommentEvent, env: Env ): Promise { // Recente geschiedenis van deze klant laden uit KV (werkgeheugen) const historyKey = `customer:${comment.userId}:history`; const rawHistory = await env.AGENT_KV.get(historyKey); const history: ConversationTurn[] = rawHistory ? JSON.parse(rawHistory) : []; // Een contextbewuste systeemprompt opbouwen vanuit de geschiedenis const systemPrompt = buildSystemPrompt(history); const response = await anthropic.messages.create({ model: "claude-opus-4-8", max_tokens: 512, system: systemPrompt, messages: [{ role: "user", content: comment.text }], }); const reply = response.content[0].type === "text" ? response.content[0].text : ""; // Geschiedenis bijwerken — de laatste 10 beurten bewaren, TTL 30 dagen const updatedHistory: ConversationTurn[] = [ ...history.slice(-9), { role: "assistant", content: reply, timestamp: comment.timestamp }, ]; await env.AGENT_KV.put(historyKey, JSON.stringify(updatedHistory), { expirationTtl: 60 * 60 * 24 * 30, }); await postReply(comment, reply, env); } ``` Twee dingen om op te merken. De geschiedenis is beperkt tot 10 beurten — gebruik een schuifvenster, laat het niet onbeperkt groeien. En de TTL is 30 dagen: als een klant een maand zwijgt, verloopt de geschiedenis en begint de agent opnieuw. Beide zijn opzettelijk. ## Episodisch geheugen: wat er is gebeurd en wanneer Episodisch geheugen is het logboek van de agent. Een gestructureerd overzicht van vroegere runs dat de agent aan het begin van elke nieuwe run leest om herhaling te vermijden. Mijn dagelijkse briefing-agent toonde elke dag dezelfde verouderde meldingen omdat elke run geen bewustzijn had van wat al was gemeld. De oplossing: een gestructureerd logboek van vroegere meldingen dat de agent leest vóór het genereren van de briefing. ```typescript // workers/daily-brief.ts interface AlertLogEntry { id: string; surfacedAt: string; // ISO-tijdstempel resolvedAt?: string; summary: string; } async function buildDailyBrief(env: Env): Promise { const [emails, calendar, tasks] = await Promise.all([ fetchOvernightEmails(env), fetchTodayCalendar(env), fetchTopTasks(env), ]); // Episodisch geheugen laden: wat al is gemeld const rawLog = await env.AGENT_KV.get("brief:alert-log"); const alertLog: AlertLogEntry[] = rawLog ? JSON.parse(rawLog) : []; // Filteren op alleen recente, onopgeloste meldingen const sevenDaysAgo = new Date( Date.now() - 7 * 24 * 60 * 60 * 1000 ).toISOString(); const recentAlerts = alertLog.filter( (e) => e.surfacedAt > sevenDaysAgo && !e.resolvedAt ); const brief = await synthesizeBrief( { emails, calendar, tasks, recentAlerts }, env ); // Het logboek bijwerken met nieuwe meldingen die in deze run zijn gevlagd const newAlerts: AlertLogEntry[] = brief.newAlerts.map((a) => ({ id: crypto.randomUUID(), surfacedAt: new Date().toISOString(), summary: a, })); const updatedLog = [...alertLog, ...newAlerts].slice(-100); // de laatste 100 bewaren await env.AGENT_KV.put("brief:alert-log", JSON.stringify(updatedLog)); await writeToWorkspace(brief.content, env); } ``` De agent weet nu wat hij al heeft gezegd. Dubbele meldingen blijven buiten de briefing totdat het onderliggende probleem verandert. Wanneer ik een melding als opgelost markeer, verdwijnt deze van de actieve lijst. Dit patroon generaliseert: elke agent die beslissingen, vlaggen of aanbevelingen produceert, heeft baat bij een logboek. Het logboek is goedkoop (een paar KB in KV), de opbrengst is hoog (geen redundante output meer). ## Semantisch geheugen: wat je weet Semantisch geheugen is de kennisbank. Het beantwoordt "wat weet je over X?" op het moment van de query, in plaats van alles vooraf in de systeemprompt te proppen. De eenvoudigste vorm is een gestructureerde zoekopdracht in KV of een database. Mijn Pickleland-boekingsagent raadpleegt klantprofielen en baanvoorkeuren voordat hij bevestigingen opstelt: ```typescript // workers/booking-agent.ts interface CustomerProfile { userId: string; preferredCourts: string[]; experienceLevel: "beginner" | "intermediate" | "advanced"; specialNotes: string; } async function draftConfirmation( booking: BookingEvent, env: Env ): Promise { // Klantprofiel ophalen uit KV (semantisch geheugen — feitelijke kennis) const profileKey = `customer:${booking.userId}:profile`; const rawProfile = await env.AGENT_KV.get(profileKey); const profile: CustomerProfile | null = rawProfile ? JSON.parse(rawProfile) : null; const systemPrompt = profile ? `Je stelt gepersonaliseerde boekingsbevestigingen op. Deze klant geeft de voorkeur aan ${profile.preferredCourts.join(", ")}, is een ${profile.experienceLevel}-speler. ${profile.specialNotes}` : "Je stelt boekingsbevestigingen op voor een pickleballfaciliteit."; const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 256, system: systemPrompt, messages: [ { role: "user", content: `Stel een bevestiging op voor: ${JSON.stringify(booking)}`, }, ], }); return response.content[0].type === "text" ? response.content[0].text : ""; } ``` Voor grotere kennisbanken — productdocumentatie, een support-kennisbank, alles wat te groot is om in een contextvenster te passen — heb je een vectoropslag nodig. De workflow is: de query insluiten, de k meest relevante chunks ophalen, ze in de context injecteren. Cloudflare Vectorize handelt dit native af als je al op Workers zit. Voor grotere indexen heb ik Upstash Vector gebruikt. De keuze hangt af van de schaal, niet van het principe. De eerlijke noot over semantisch geheugen: het is de moeilijkste van de drie om te bouwen en te onderhouden. De index moet actueel blijven. De kwaliteit van het ophalen varieert. Begin met gestructureerde zoekopdrachten — KV, een tabel in D1 — en grijp pas naar vectorzoekopdrachten wanneer de gestructureerde aanpak het kennisoppervlak dat je nodig hebt niet kan dekken. ## Het geheugen-beslissingsraamwerk Voordat je geheugen aan een agent toevoegt, beantwoord drie vragen: 1. **Moet de agent onthouden tussen runs?** Als elke aanroep echt onafhankelijk is — een vertaling, een classificatie, een eenmalige generatie — sla dan geheugen over. Staatloos is eenvoudiger en goedkoper. 2. **Herhaalt de agent zichzelf of handelt hij blind voor zijn eigen geschiedenis?** Zo ja, voeg dan eerst episodisch geheugen toe. Het is de oplossing met de minste moeite en dekt de meeste klachten over "de agent blijft X doen". 3. **Behandelt de agent elke gebruiker of entiteit identiek wanneer dat niet zou moeten?** Zo ja, voeg werkgeheugen toe (klantgeschiedenis, gebruikersprofiel) of semantisch geheugen (een zoek- of ophaal-systeem). De fout die ik het vaakst zie: iemand voegt een enorme kennisbank (semantisch geheugen) toe aan een agent die eigenlijk faalde omdat hij geen episodisch geheugen had — geen logboek van wat hij al had gedaan. De complexiteit past niet bij het probleem. ## Wat ik echt gebruik in productie Bij 30+ agents: - **Alle** hebben minstens werkgeheugen — een of andere vorm van status binnen een run, al is het alleen het contextvenster zelf. - **Ongeveer de helft** heeft episodisch geheugen — een logboek van vroegere runs, beslissingen of vlaggen. Dit is bijna altijd de moeite waard om toe te voegen. - **Drie of vier** hebben echt semantisch geheugen ondersteund door een vectoropslag. Dit zijn de agents die vragen beantwoorden over een grote, dynamische kennisbank. Cloudflare KV is mijn standaard opslag voor werk- en episodisch geheugen. Het is snel, goedkoop en native geïntegreerd in Workers — geen extra client, geen aparte credential. De beperking: KV is uiteindelijk consistent en niet geweldig voor schrijfacties met hoge frequentie. Voor agents die meerdere keren per seconde status schrijven, gebruik ik in plaats daarvan Durable Objects of een D1-database. Voor semantisch geheugen ondersteund door vectoren gebruik ik Cloudflare Vectorize voor kleine tot middelgrote indexen (minder dan ~100K vectoren) en Upstash Vector voor alles wat groter is. Beide hebben eersteklas JavaScript-clients. ## De conclusie van de operator Voeg geheugen toe aan een agent alleen wanneer staatloos gedrag echte problemen veroorzaakt — herhaalde output, blinde vlekken in de klantgeschiedenis, onwetendheid over vroegere beslissingen. Kies dan de juiste laag: werkgeheugen voor context tijdens de run, episodisch voor wat er historisch is gebeurd, semantisch voor wat je weet. Begin met episodisch als je het niet zeker weet — het repareert het meest voorkomende faalpatroon met de minste complexiteit. Grijp niet naar een vectordatabase totdat je gestructureerde zoekopdrachten hebt uitgeput. Het beste geheugensysteem is het eenvoudigste dat de agent correct laat gedragen. --- **Gerelateerd:** [De agent-stack die ik gebruik voor 30+ productie-agents](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) · [Gebeurtenisgestuurde vs. geplande agents](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) · [Hoe ik meet of een AI-agent echt werkt](/how-i-measure-whether-an-ai-agent-is-actually-working/) **Hulp nodig bij het ontwerpen van agentgeheugen voor jouw gebruik?** [Neem contact op](/contact/) — ik ontwerp productie-agentsystemen voor operatorteams. --- ## E-maillijst opbouwen vanaf nul: Het 2026 Playbook Source: https://alejandrorioja.com/nl/how-to-build-an-email-list/ Published: 2026-06-27 Tags: Entrepreneurship, Growth TL;DR: Een e-maillijst is het enige distributiekanaal dat je echt bezit. Begin met een lead magnet die een specifiek probleem oplost, plaats je opt-in boven de vouw en stuur een welkomstreeks van 3 e-mails zodra iemand zich inschrijft. Kwaliteit wint altijd van kwantiteit — 1.000 betrokken abonnees presteren beter dan 10.000 koude. ## Inhoudsopgave _Bijgewerkt juni 2026._ **TL;DR:** Een e-maillijst is het enige distributiekanaal dat je echt bezit. Begin met een lead magnet die een specifiek probleem oplost, plaats je opt-in boven de vouw en stuur een welkomstreeks van 3 e-mails zodra iemand zich inschrijft. Kwaliteit wint altijd van kwantiteit — 1.000 betrokken abonnees presteren beter dan 10.000 koude. **[Operatorperspectief]** Elk bedrijf waarbij ik betrokken was en dat een duurzame inkomstenmachine opbouwde, had één ding gemeen: een lijst. Geen volgers. Geen impressies. Een lijst van mensen die vroegen van jou te horen. Dit is precies hoe je er een opbouwt vanaf nul. ## Het enige bezit dat je echt eigendom hebt Elk ander distributiekanaal kan verdwijnen. Een Google-algoritme-update wist zoekrankings. Een beleidswijziging van een platform vernietigt je Facebook-bereik. Een advertentieaccount wordt zonder waarschuwing opgeschort. Je e-maillijst is de uitzondering. Als je een e-maillijst bezit, beheer jij de levering. Geen algoritme beslist wie je content ziet. Geen platformkosten worden elke keer berekend als je je doelgroep wilt bereiken. Daarom is het opbouwen van een e-maillijst het eerste dat ik elke oprichter vertel — vóór SEO, vóór betaalde advertenties, vóór sociale media. ## Stap 1: Kies een e-mailplatform Voordat je één adres verzamelt, heb je een platform nodig om op te slaan en te verzenden. Gebruik geen Gmail. Gebruik je zakelijke e-mail niet. Gebruik een speciaal gebouwd hulpmiddel met de juiste compliance- en bezorgingsinfrastructuur. Mijn twee keuzes voor 2026: **[ConvertKit](/recommends/convertkit)** — Beste keuze voor makers en solo-operators. Het systeem voor het taggen en segmenteren van abonnees is werkelijk uitstekend. Gratis tot 1.000 abonnees. **[Moosend](/recommends/moosend)** — Beste keuze voor kleine bedrijven die automatisering willen zonder de ConvertKit-prijs. Solide drag-and-drop-builder en consistent goede bezorgbaarheid. Als je vanaf nul begint, hebben beide gratis niveaus die je eerste paar honderd abonnees dekken. Stel DKIM-, SPF- en DMARC-authenticatie in op je domein voordat je iets verzendt — dit is vereist door Gmail en Yahoo since 2024 voor verzenders met hoog volume, en het beschermt je verzendersreputatie vanaf dag één. ## Stap 2: Een lead magnet maken die de download waard is Een lead magnet is wat je aanbiedt in ruil voor iemands e-mailadres. De fout die de meeste mensen maken: iets generisch aanbieden. "Abonneer je op onze nieuwsbrief" is geen lead magnet. Het is een vertrouwensverzoek zonder iets terug. Je lead magnet moet een specifiek probleem oplossen voor een specifiek persoon. Hoe specifieker, hoe beter het converteert. **Formats die werken in 2026:** 1. **Cheat sheets en sjablonen** — Een eenpagina-resource die iemand onmiddellijk kan gebruiken. Hoe meer plug-and-play, hoe beter. 2. **Mini-cursussen (3–5 e-mails)** — Een korte reeks die één vaardigheid leert, automatisch afgeleverd. Bouwt de lijst en de relatie tegelijkertijd op. 3. **Calculator of spreadsheet** — Hoge ervaren waarde. Een tool voor marktgrootte, een prijsmodel, een budgetsjabloon. Deze converteren omdat ze echt werk besparen. 4. **Exclusieve data of onderzoek** — Originele enquêteresultaten of een benchmarkrapport. Moeilijk te repliceren, hoge geloofwaardigheid. 5. **Swipe files** — Verzamelingen van echte voorbeelden (advertentieteksten, onderwerpregels, landingspagina-koppen). Praktijkmensen betalen hiervoor. 6. **Webinar of trainingsreplay** — Hergebruik een bestaande opname als opt-in. Duurt 20 minuten om in te stellen. Een niet-onderhandelbare: de lead magnet moet direct gerelateerd zijn aan waarover je e-mails stuurt. Een Facebook-advertentiesjabloon die abonnees vastlegt voor een B2B SaaS-nieuwsbrief is een lijstkwaliteitsramp in wachting. ## Stap 3: Plaats opt-in formulieren waar ze werken Formulierplaatsing drijft meer conversie dan tekst. Plaats opt-in formulieren waar aandacht al aanwezig is: 1. **Boven de vouw op je startpagina** — Niet in de voettekst. Niet in de zijbalk. Boven de vouw, met een duidelijke beschrijving van wat ze zullen ontvangen. 2. **Einde van elk blogbericht** — Iemand die je hele bericht heeft gelezen, is vooraf gekwalificeerd. Vang ze terwijl ze nog betrokken zijn. 3. **Exit-intent popup** — Wordt geactiveerd wanneer een bezoeker een tabblad wil sluiten. Controversieel, maar werkt. 4. **Speciale landingspagina** — Een zelfstandige pagina zonder navigatie. Hier stuur je betaald verkeer naartoe. 5. **Inhoudsupgrades** — Een resource die een specifiek bericht verbetert. Een marktgrootte-spreadsheet in een TAM/SAM/SOM-gids converteert 3–5 keer beter dan een generiek aanbod op dezelfde pagina. Teksttip: begin met het resultaat, niet met het format. "Ontvang de 5-pagina-gids" is zwakker dan "Ken je marktomvang zoals een VC dat doet." ## Stap 4: Schrijf een welkomstreeks Het moment dat iemand zich inschrijft, heb je hun maximale aandacht. Verspil het niet met stilte. Stuur minimaal 3 e-mails: **E-mail 1 (onmiddellijk):** Lever de lead magnet af. Bevestig waarvoor ze zich hebben aangemeld. Stel verwachtingen in voor wat er komt. **E-mail 2 (dag 2):** Je beste stuk content — een bericht, een casestudy, een framework. Geen pitch. Alleen bewijs dat inschrijven de moeite waard was. **E-mail 3 (dag 4–5):** Je oorsprongsverhaal en standpunt. Waarom geef je om dit onderwerp? Wat geloof jij dat de meeste mensen in jouw vakgebied niet geloven? Hier wordt vertrouwen opgebouwd. Handhaaf daarna een consistent tempo. Wekelijks is de standaard. Tweewekelijks werkt als je wekelijks de kwaliteit niet kunt volhouden. De grootste fout is één keer e-mailen bij de lancering en dan drie maanden verdwijnen. ## Stap 5: Stuur verkeer naar je opt-in Een formulier zonder verkeer converteert niemand. De meest betrouwbare groeikanalen: **Organisch zoeken** — Blogberichten die scoren voor de problemen die jouw lead magnet oplost. Iemand die naar jouw onderwerp zoekt en je bericht vindt, is vooraf gekwalificeerd voor je aanbod. Dit is het goedkoopste kanaal met het hoogste retentiepercentage. **Sociale media (organisch)** — LinkedIn-berichten, Twitter/X-threads of korte video's die mensen naar je opt-in-pagina leiden. Elk bericht moet een teaser zijn, niet het hele verhaal. **Nieuwsbrief-swaps en co-promoties** — Zoek nieuwsbrieven in aangrenzende ruimten en wissel vermeldingen uit. Jij promoot hun lijst; zij promoten die van jou. Dit is een van de snelste manieren om te groeien van 500 naar 5.000 abonnees. **Podcastgastoptredens** — Onderschat. Een aflevering van 30 minuten die naar 2.000 niche-luisteraars wordt gestuurd, kan 50–100 diep geïnteresseerde abonnees toevoegen die meer kans hebben om elke e-mail die je stuurt te openen. **Betaalde advertenties** — Adverteer niet voor een niet-gevalideerd aanbod. Zorg eerst dat je opt-in-pagina organisch converteert, schakel dan op met betaald verkeer. ## Stap 6: Houd je lijst schoon Een e-maillijst verslechtert. Mensen wisselen van baan, e-mailadres, interesses. Als je je lijst niet opschoont, lijdt je bezorgbaarheid — wat betekent dat ook betrokken abonnees je e-mails niet meer zien. Best practices: - **Heractiveringsmailing elke 6 maanden** — Stuur een e-mail naar iedereen die meer dan 90 dagen niets heeft geopend. Geef ze een reden om te blijven. Als ze niet betrokken zijn, verwijder ze. - **Verwijder harde bounces onmiddellijk** — Een hoog bouncepercentage vertelt postvak-providers dat je lijst vuil is. - **Segmenteer op betrokkenheid** — Tag actieve en koude abonnees afzonderlijk. Stuur tijdgevoelige campagnes alleen naar je actieve segment. Abonnees verwijderen voelt als iets verliezen. In de praktijk beschermt het de abonnees die je wilt houden. ## Eerlijke kanttekeningen **Opbouwen kost tijd.** Beginnend bij nul met alleen organische methoden, verwacht 3–6 maanden om 1.000 abonnees te bereiken. Iedereen die duizenden in weken belooft, verkoopt ijdelheidsmetrics of koude, niet-betrokken contacten die je niet wilt. **Niche is belangrijk.** B2B-doelgroepen reageren op gegevens en casestudies. Consumentendoelgroepen reageren op kortingen en entertainment. De lead magnet en het inhoudsritme moeten bij de doelgroep passen. **Lead magnets verouderen.** Wat vandaag goed converteert, kan over 18 maanden verouderd zijn als concurrenten het format kopiëren. Plan je lead magnet jaarlijks te vernieuwen. ## Realistische benchmarks | Maatstaf | Branchegemiddelde | Goed | |--------|-----------------|------| | Popup opt-in percentage | 2–4% | 5–8% | | Landingspagina opt-in percentage | 20–30% | 40–60% | | Openpercentage welkomstsmail | 50–60% | 70%+ | | Voortdurend openpercentage | 20–25% | 35–45% | | Doorklikpercentage | 2–3% | 5–10% | Optimaliseer deze cijfers niet in de eerste 90 dagen. Bouw de infrastructuur, voer de lead magnet uit, stuur consistent. Herhaal dan. ## Bijgewerkt voor juni 2026 **AI-gegenereerde lead magnets** — Tools zoals Claude kunnen in minuten een 10-pagina PDF-gids, een swipe file of een sjabloon opstellen. De drempel voor het maken van een hoogwaardige lead magnet is bijna nul. De differentiator is nu de specificiteit van de belofte en de relevantie voor je doelgroep. **Gmail- en Yahoo-authenticatie** — Vanaf 2024 zijn DKIM, SPF en DMARC vereist voor verzenders die dagelijks meer dan 1.000 adressen e-mailen. Zowel [ConvertKit](/recommends/convertkit) als [Moosend](/recommends/moosend) begeleiden je tijdens het onboardingproces door de installatie. Doe het voordat je het nodig hebt. **AI-zoekverkeer** — Een goed gestructureerde opt-in-pagina met een duidelijke TL;DR en een direct antwoord op een zoekopdracht kan verschijnen in ChatGPT, Perplexity en Google AI Overviews. Ik heb gezien hoe opt-in-landingspagina's consistent verkeer genereren vanuit AI-zoeken zonder enig SEO-werk — omdat de pagina direct een specifieke vraag beantwoordt. ## Veelgestelde vragen **Hoeveel abonnees heb ik nodig om te monetariseren?** Er is geen universeel getal. Ik heb nieuwsbrieven met 500 diep betrokken abonnees in een niche met hoge intentie zien presteren boven lijsten van 20.000 generieke contacten. De vraag is of je abonnees een probleem hebben en of ze jou vertrouwen om het op te lossen. **Moet ik een e-maillijst kopen?** Nee. Gekochte lijsten hebben verschrikkelijke betrokkenheid, laten je markeren als spam en kunnen je account opschorten. Er is geen snelkoppeling. **Hoe vaak moet ik e-mails sturen?** Zo vaak als mogelijk terwijl je kwaliteit behoudt. Wekelijks houdt je top-of-mind. De grootste fout is maandenlang stilzwijgend zijn en dan terugkomen met een pitch. **Dubbele opt-in of enkelvoudige?** Dubbele opt-in in de meeste gevallen. Bevestiging verkleint de lijstomvang maar verbetert de betrokkenheid en bezorgbaarheid dramatisch. De uitzondering is wanneer je hoogintentioneel, geverifieerd verkeer stuurt vanuit een specifieke bron. **Wat is het beste e-mailplatform voor beginners?** [ConvertKit](/recommends/convertkit) voor makers die een persoonlijk merk of contentbedrijf bouwen. [Moosend](/recommends/moosend) voor kleine bedrijven die betaalbaarheid en automatisering willen. Beide zijn veel beter dan proberen Gmail te gebruiken. ## Waar ik dit hierna naartoe zou nemen De e-maillijst leeft niet in isolatie. Je best presterende berichten zouden een inhoudsupgrade moeten hebben. Je e-mails zouden moeten linken naar diepgaande gidsen. Je lead magnet zou precies het probleem moeten oplossen dat je pagina's met het meeste verkeer aanpakken. Die lus — verkeer → opt-in → nurturing → vertrouwen → aanbod — is de basis van elk duurzaam online bedrijf waarbij ik betrokken ben geweest. Als je wilt bespreken hoe je dit kunt inrichten voor jouw specifieke situatie, is de [contactpagina](/contact) de juiste plek om te beginnen. --- ## Hoe je een nieuwsbrief monetariseert: 5 inkomstenmodellen die echt werken Source: https://alejandrorioja.com/nl/how-to-monetize-a-newsletter/ Published: 2026-06-25 Tags: Entrepreneurship, Growth TL;DR: De meeste nieuwsbrieven mislukken bij monetarisering omdat ze het verkeerde model najagen voor hun lijstgrootte. De vijf modellen die werken: betaalde abonnementen (het beste voor niche-autoriteit), sponsoring (het beste na 5.000+ abonnees), affiliate-aanbevelingen (minste weerstand bij elke omvang), cursus- en productfunnels (hoogste inkomensplafond) en service-upsells (snelste weg naar echt geld). Begin met één. Voeg een tweede toe pas als het eerste werkt. ## Table of contents _Bijgewerkt in juni 2026._ **TL;DR:** De meeste nieuwsbrieven mislukken bij monetarisering omdat ze het verkeerde model najagen voor hun lijstgrootte. De vijf modellen die werken: betaalde abonnementen (het beste voor niche-autoriteit), sponsoring (het beste na 5.000+ abonnees), affiliate-aanbevelingen (minste weerstand bij elke omvang), cursus- en productfunnels (hoogste inkomensplafond) en service-upsells (snelste weg naar echt geld). Begin met één. Voeg een tweede toe pas als het eerste werkt. **[Perspectief van de operator]** Ik run een nieuwsbrief al voordat het in de mode was om het een "nieuwsbriefbedrijf" te noemen. De eerlijke versie van de reis: ik probeerde alles tegelijk te doen, verdiende bijna niets, bracht het terug naar één model en begon te verdienen. Dit is wat ik heb geleerd en wat ik nu consistent zie werken bij de operators met wie ik samenwerk. ## Waarom de meeste nieuwsbrieven nooit een euro verdienen Het monetariseringsprobleem is gewoonlijk een sequentieringsprobleem. Mensen lanceren een nieuwsbrief, laten die langzaam groeien en proberen dan alle inkomstenstromen tegelijk toe te voegen — een betaalde laag hier, een sponsorslot daar, een affiliate-link in elk nummer. Het resultaat is een nieuwsbrief die aanvoelt als een winkelcentrum: alles is te koop, niets voelt oprecht aan en lezers haken af. Nieuwsbrieven die consistent verdienen, doen eerst één ding goed. Ze bewijzen dat één model werkt voor hun specifieke publiek. Dan — en pas dan — voegen ze een tweede toe. De grootte van je lijst bepaalt ook welke modellen haalbaar zijn. Een lijst van 500 abonnees is het verkeerde instrument voor het zoeken naar sponsors. Een lijst van 50.000 abonnees laat aanzienlijk geld liggen als het alleen affiliate-links gebruikt. Het model moet passen bij de lijst. ## Model 1: Betaalde abonnementen **Het beste voor:** Niche-autoriteitsnieuwsbrieven met een gedefinieerd professioneel of sterk geïnteresseerd publiek. Betaalde abonnementen zijn de puurste vorm van nieuwsbriefmonetarisering: lezers betalen direct voor de inhoud. Platforms zoals Beehiiv en Substack maken het eenvoudig om dit aan een gratis lijst toe te voegen. Wat het laat werken: - Een specifieke, hoogwaardige niche waar informatie schaars is of tijd bespaart (financiële analyse, branche-intelligentie, tactieken op operatorniveau) - Een duidelijk antwoord op "wat krijgt een abonnee door te betalen dat hij niet gratis krijgt?" - Een gratis laag die oprecht waardevol is — niet een verdunde versie, maar een voorproefje van de aanpak van de betaalde laag Wat het om zeep helpt: - Algemene onderwerpen met weinig urgentie ("marketingtips", "persoonlijke ontwikkeling") - Betaald lanceren voordat je bewijs hebt dat gratis abonnees je inhoud consistent lezen Realistische inkomsten: €5–€20/maand per abonnee. Bij 5% conversie uit een lijst van 2.000 personen zijn dat 100 betalende abonnees à €10/maand = €1.000 MRR. Klein, maar reëel, en het accumuleert. ## Model 2: Sponsoring en native advertising **Het beste voor:** Nieuwsbrieven met 5.000+ abonnees en een gedefinieerde doelgroepdemografie. Sponsoring is het meest zichtbare model — een nummersslot verkocht aan een merk dat relevant is voor je publiek. Als het werkt, werkt het goed: €100–€500+ CPM (kosten per duizend abonnees) is typisch voor een niche B2B- of hoog-inkomenspubliek. De eerlijke beperking: sponsors willen schaal en specificiteit. "Ik heb 1.000 abonnees die geïnteresseerd zijn in marketing" sluit geen deals. "Ik heb 6.000 abonnees die marketingmanagers zijn bij bedrijven met 10–500 medewerkers, met een openingspercentage van 52%" wel. Hoe je er komt: 1. **Definieer je publiek** in demografische termen, niet in interessetermen 2. **Bereik 5.000 abonnees** als minimale geloofwaardigheidsvloer voor het benaderen van sponsors 3. **Bewijs engagement** — openingspercentages boven 40% zijn het echte onderscheidende kenmerk 4. **Bouw een mediapakket** — een eenzijdige PDF met abonneeaantal, openingspercentage, publieksprofiel en sponsorpakketten 5. **Begin met inbound** — meld je aan bij sponsormarktplaatsen voordat je een outbound verkoopproces opbouwt CPM-realiteitscheck: als je lijst converteert bij 45% openingspercentage en je verkoopt één sponsorslot per nummer bij €200 CPM, genereert een lijst van 5.000 abonnees €1.000 per gesponsord nummer. Bij vier nummers per maand is dat €4.000/maand van één sponsorslot. Met twee slots €8.000/maand. De wiskunde werkt — op schaal. ## Model 3: Affiliate-aanbevelingen **Het beste voor:** Elke lijstgrootte, elke niche waar je oprecht tools en diensten gebruikt. Affiliate-marketing is het model met de minste weerstand om te beginnen: je beveelt producten aan die je echt gebruikt, lezers klikken en je verdient commissie op aankopen. Geen sponsorrelaties te beheren, geen product te bouwen, geen betaalde laag te onderhouden. De sleutelbepaling is vertrouwen. Affiliate-aanbevelingen converteren alleen als de aanbeveling oprecht nuttig en geloofwaardig is. Een sectie "beste keuzes" vol met producten die je nooit hebt gebruikt, zal ondermaats presteren — of erger, de lijst beschadigen. Wat werkt: - Tools aanbevelen die je in je eigen stack gebruikt (voor mij: [ConvertKit](/recommends/convertkit) voor e-mailbeheer, [Semrush](/recommends/semrush) voor SEO en contentonderzoek) - Contextuele plaatsing — de tool vermelden waar het relevant is voor de inhoud, niet in een vast blok "sponsor van dit nummer" dat lezers leren over te slaan - Een echte mening geven: wat je leuk vindt, wat niet en voor wie het niet geschikt is Inkomensplafond: affiliate-commissies variëren — SaaS-tools betalen doorgaans 20–40% terugkerend op geconverteerde abonnees, wat goed accumuleert. Een lijst van 1.000 abonnees waarbij 2% van de lezers converteert op een SaaS van €50/maand bij 30% commissie = €300/maand terugkerend, groeiend met elke nieuwe aanmelding die blijft. ## Model 4: Cursus- en digitale productfunnel **Het beste voor:** Operators met onderwijsautoriteit in een specifiek domein. De nieuwsbrief is de top van de funnel; de cursus of het digitale product is het conversiegebeurtenis. Lezers die je genoeg vertrouwen om elk nummer te openen, zijn de best gekwalificeerde leads voor een betaald product dat hen iets leert dat jij weet. Dit is het model met het hoogste inkomensplafond bij zelfs een bescheiden lijst. Een cursus van €497 verkocht aan 2% van een lijst van 5.000 personen is €49.700 per lancering. Bij drie lanceringen per jaar met lijstgroei accumuleert dit agressief. Wat het vereist: - Echte onderwijsautoriteit in een specifiek domein — niet alleen "ik ken marketing" maar "ik heb drie B2B-bedrijven laten groeien met dit specifieke groeispeelboek" - Inhoud die week na week autoriteit toont (niet alleen gecureerde links — je originele frameworks en casestudies) - Een lanceringsvolgorde waarvoor de lijst is voorbereid — geen koude "koop mijn cursus"-e-mail van een lijst die alleen inhoud ontvangt Dit is het model waarop ik in mijn eigen werk het meest leun. De nieuwsbrief bouwt het vertrouwen op; de cursus converteert het. ## Model 5: Service-upsells **Het beste voor:** Nieuwsbrieven in een vroeg stadium waarbij de operator consultancy, coaching of done-for-you-diensten aanbiedt. Dit model is de snelste weg naar echte inkomsten bij kleine lijstgroottes, en het is het meest onderbenut. De nieuwsbrief positioneert jou als expert; de service is de expert aan het werk. Als 500 mensen je nieuwsbrief over growth marketing lezen en je publiceert één nummer per maand dat je denken laat zien, zullen 1–2 van die 500 lezers periodiek hun hand opsteken en vragen of je consultancy doet. Als je dat niet aanbiedt, heb je inkomsten laten liggen. Hoe het expliciet te maken: - Voeg een regel toe aan de voettekst van je nieuwsbrief: "Ik werk per kwartaal met een klein aantal klanten aan [specifiek resultaat]. Antwoord op deze e-mail als je dat wilt verkennen." - Vermeld klantresultaten (geanonimiseerd) in relevante nummers — niet als opschepperij, maar als bewijs dat de frameworks in de praktijk werken - Houd de capaciteit bewust beperkt — schaarste is hier niet gefabriceerd, het is reëel; je hebt maar een bepaalde hoeveelheid tijd Inkomenswerkelijkheid: één consultancyklant à €5.000/maand en een nieuwsbrief van 200 personen heeft betere economie dan 50.000 abonnees die €0,01/abonnee verdienen aan verspreide affiliate-inkomsten. Wacht niet op schaal om hier te beginnen. ## Hoe je het juiste model kiest Het beslissingsframework: | Lijstgrootte | Beste startmodel | Tweede model toe te voegen | |-------------|-----------------|--------------------------| | 0–1.000 | Service-upsells | Affiliate-aanbevelingen | | 1.000–5.000 | Affiliate + cursus wachtlijst | Betaalde abonnementen | | 5.000–20.000 | Sponsoring | Cursuslanering | | 20.000+ | Sponsoring + cursus | Betaalde laag | Eén beperking die op geen enkele grootte verandert: kies er eerst één. Modelverspreiding vernietigt conversie op alle modellen tegelijkertijd. ## De stack van de nieuwsbriefoperator Tools die ik gebruik en aanbeveel voor het opbouwen van een nieuwsbriefbedrijf: - **E-mailplatform:** [ConvertKit](/recommends/convertkit) — abonneetagging, segmentatie en automatiseringsreeksen die kopers van lezers scheiden - **SEO- en onderwerponderzoek:** [Semrush](/recommends/semrush) — identificeer waarnaar je doelgroep zoekt voordat je erover schrijft - **Ontwerp:** [Canva](/recommends/canva) — mediapakket, cursusomslag-assets en sociale inhoud zonder ontwerper - **Betalingen:** Stripe — voor betaalde abonnementslagen of cursus-checkouts ## De conclusie van de operator Een nieuwsbrief is het contentasset met de hoogste hefboom dat je in 2026 kunt bouwen: aandacht in de e-mailinbox is schaars en waardevol op een manier die sociale feeds niet zijn. Maar het asset converteert alleen naar inkomsten als je een model kiest dat past bij de grootte van je lijst, het uitvoert met oprechte aanbevelingen en echte autoriteit, en de drang weerstaat om je over elke monetarisatiemethode tegelijk te verspreiden. Begin met het model dat past bij waar je vandaag staat. Als het werkt — consistent, met cumulatieve resultaten — voeg de volgende toe. --- **Gerelateerd:** [Hoe een bedrijfsidee te valideren voordat je het bouwt](/how-to-validate-a-business-idea/) · [Growth marketing-strategiegids](/growth-marketing-strategies-guide/) · [6 beste e-mailmarketingdiensten voor kleine bedrijven](/6-best-email-marketing-services-for-small-business/) --- ## Hoe Bouw Je Je Eerste MCP-Server: Een Praktische Gids Source: https://alejandrorioja.com/nl/how-to-build-your-first-mcp-server/ Published: 2026-06-23 Tags: AI Agents TL;DR: MCP (Model Context Protocol) is hoe je Claude gestructureerde toegang geeft tot externe tools en data — databases, bestanden, API's — zonder het contextvenster te overbelasten. De server is eenvoudiger dan het lijkt: installeer de SDK, definieer je tools als JSON schema, implementeer de handlers, verbind via stdio. In minder dan 30 minuten kan Claude je aangepaste tools aanroepen. ## Inhoudsopgave _Bijgewerkt juni 2026._ **TL;DR:** MCP (Model Context Protocol) is hoe je [Claude](/recommends/claude) gestructureerde toegang geeft tot externe tools en data — databases, bestanden, API's — zonder het contextvenster te overbelasten. De server is eenvoudiger dan het lijkt: installeer de SDK, definieer je tools als JSON schema, implementeer de handlers, verbind via stdio. In minder dan 30 minuten kan Claude je aangepaste tools aanroepen. **[Operatorperspectief]** Ik verbind regelmatig nieuwe tools met mijn agents, en MCP is nu de standaardweg om dat netjes te doen. Zodra de server is gebouwd, kan elke compatibele client — Claude Desktop, Claude Code, elke app die de Anthropic SDK gebruikt — deze gebruiken zonder wijzigingen in de aanroepende code. Dat is de waarde: eenmalig bouwen, overal hergebruiken. ## Wat MCP eigenlijk is Het **Model Context Protocol** is een open protocol dat standaardiseert hoe AI-modellen verbinding maken met externe context en tools. Denk eraan als een USB-C-standaard voor AI-integraties: vóór dit protocol moest elke app die Claude een database wilde laten lezen of een API wilde laten aanroepen zijn eigen oplossing bedenken. Daarna bouw je één MCP-server en elke conforme host kan deze gebruiken. MCP definieert drie dingen die een server kan aanbieden: - **Tools** — functies die Claude kan aanroepen (een bestand lezen, een DB bevragen, een Slack-bericht sturen) - **Resources** — data die Claude kan lezen (documenten, databaserijen, bestandsbomen) - **Prompts** — herbruikbare prompttemplates die de host kan injecteren Voor de meeste operatorgebruiksscenario's bouw je **toolservers**. Resources en prompts komen later, zodra de basis werkt. De architectuur is client-server, waarbij de client (Claude Desktop, Claude Code, je aangepaste app) alles beheert. De server is passief — hij luistert alleen naar toolaanroepverzoeken en geeft resultaten terug. ## De drie onderdelen van elke MCP-server Elke MCP-server die je bouwt heeft dezelfde structuur: 1. **Het serverobject** — declareert de naam, versie en mogelijkheden van je server (tools, resources, prompts) 2. **Tooldefinities** — een lijst van tools met namen, beschrijvingen en JSON-schema's voor hun invoer 3. **Verzoekhandlers** — de functies die worden uitgevoerd wanneer Claude een tool aanroept Dat is het. Geen database, geen HTTP-stack, geen auth-laag nodig om te starten. De minimale server heeft minder dan 30 regels TypeScript. ## Vereisten (2 minuten) - **Node.js 18+** — controleer met `node --version` - **TypeScript 5+** (hieronder opgenomen als dev-afhankelijkheid) - Een MCP-client om te testen — Claude Desktop is gratis en de eenvoudigste manier om je server in actie te zien Er is geen Anthropic API-sleutel nodig om een MCP-server uit te voeren. De API-sleutel bevindt zich in de client (Claude Desktop), niet in je server. ## Stap 1: Het project instellen (3 minuten) ```bash mkdir my-mcp-server && cd my-mcp-server npm init -y npm install @modelcontextprotocol/sdk npm install -D typescript tsx @types/node ``` Voeg toe aan `package.json`: ```json { "type": "module", "scripts": { "build": "tsc", "dev": "tsx src/index.ts" } } ``` Maak `tsconfig.json`: ```json { "compilerOptions": { "target": "ES2022", "module": "Node16", "moduleResolution": "Node16", "outDir": "./build", "strict": true }, "include": ["src/**/*"] } ``` ## Stap 2: De minimale server schrijven (5 minuten) Maak `src/index.ts`: ```typescript import { Server } from "@modelcontextprotocol/sdk/server/index.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; import { CallToolRequestSchema, ListToolsRequestSchema, } from "@modelcontextprotocol/sdk/types.js"; const server = new Server( { name: "my-mcp-server", version: "1.0.0" }, { capabilities: { tools: {} } } ); // Declareer welke tools deze server aanbiedt server.setRequestHandler(ListToolsRequestSchema, async () => ({ tools: [ { name: "get_word_count", description: "Telt de woorden in een blok tekst.", inputSchema: { type: "object", properties: { text: { type: "string", description: "De tekst om woorden in te tellen", }, }, required: ["text"], }, }, ], })); // Verwerk toolaanroepen van de client server.setRequestHandler(CallToolRequestSchema, async (request) => { const { name, arguments: args } = request.params; if (name === "get_word_count") { const { text } = args as { text: string }; const count = text.trim().split(/\s+/).filter(Boolean).length; return { content: [{ type: "text", text: `Woordtelling: ${count}` }], }; } throw new Error(`Onbekende tool: ${name}`); }); // Verbind via stdio — zo communiceert Claude Desktop met de server const transport = new StdioServerTransport(); await server.connect(transport); ``` Dit is de volledige server. Het registreert één tool (`get_word_count`) en implementeert deze. De structuur is wat telt. ## Stap 3: Bouwen en registreren in Claude Desktop (5 minuten) Compileer TypeScript: ```bash npm run build ``` Registreer het nu in het configuratiebestand van Claude Desktop. Op **macOS**: `~/Library/Application Support/Claude/claude_desktop_config.json` Op **Windows**: `%APPDATA%\Claude\claude_desktop_config.json` Als het bestand niet bestaat, maak het aan: ```json { "mcpServers": { "my-mcp-server": { "command": "node", "args": ["/absoluut/pad/naar/my-mcp-server/build/index.js"] } } } ``` Gebruik het absolute pad. Herstart Claude Desktop na het opslaan. Je ziet een hamerpictogram (🔨) in het berichtinvoerveld — dat betekent dat Claude je tools heeft ontdekt. ## Stap 4: Een nuttige tool bouwen Woorden tellen is ter illustratie. Hier is een nuttigere tool: bestanden lezen uit een projectmap, wat ik gebruik voor context-injectie-agents die codebases, changelogs of configuratiebestanden samenvatten. ```typescript import { readFileSync, readdirSync } from "fs"; import { join, extname } from "path"; const ALLOWED_EXTENSIONS = [".md", ".txt", ".ts", ".json", ".yaml"]; const PROJECT_DIR = process.env.PROJECT_DIR ?? process.cwd(); ``` De logica is hetzelfde: definieer tools met precieze JSON-schema's, implementeer de handlers, valideer invoer om path traversal te voorkomen en geef tekst terug aan de client. ## De fouten die ik maakte (zodat jij ze niet maakt) **Het pad moet absoluut zijn.** Relatieve paden in de Claude Desktop-configuratie worden niet opgelost zoals verwacht. Gebruik altijd het volledige pad `/home/gebruiker/...`. **Stdio betekent geen `console.log` in je server.** Claude Desktop communiceert met je server via stdin/stdout. Een `console.log` voor foutopsporing corrumpeert de JSON-RPC-stroom. Log naar stderr: ```typescript process.stderr.write(`Debug: ${message}\n`); ``` **Herstart Claude Desktop na elke configuratiewijziging.** MCP-servers worden bij het opstarten geladen. Een bewerkt configuratiebestand doet niets totdat je de app sluit en opnieuw opent. **Toolbeschrijvingen zijn het product.** Claude beslist of het je tool aanroept op basis van het veld `description`. Een vage beschrijving betekent dat Claude niet weet wanneer het te gebruiken. Een precieze beschrijving betekent dat Claude het op het juiste moment gebruikt. Investeer meer tijd in beschrijvingen dan in implementatie. ## Hoe ik MCP-servers in productie gebruik Het stdio-patroon werkt uitstekend voor Claude Desktop en Claude Code (lokaal). Voor productie-agents — de [30+ die ik op Cloudflare Workers uitvoer](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) — gebruik ik de tool-use API van de Anthropic SDK direct, omdat ik de flexibiliteit nodig heb om per stap naar [Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet) te routeren. De patronen die ik daadwerkelijk gebruik: 1. **Lokale dev-tooling** — MCP-servers voor Claude Code die projectspecifieke tools blootstellen 2. **Context-injectie** — MCP-servers die relevante docs vooraf laden zonder handmatig kopiëren 3. **Prototype-naar-API-brug** — ik bouw eerst MCP (sneller om te itereren), dan migreer ik de logica naar SDK tool-use voor productie ## Wat hierna te bouwen Zodra de serverstructuur duidelijk is, zijn de nuttige tools degene die toegang hebben tot de externe context van Claude: - **Databaselezer** — voert een alleen-lezen SQL-query uit en geeft resultaten terug als JSON - **Slack-lezer** — haalt de laatste N berichten van een kanaal op - **GitHub-lezer** — lijst open PR's, leest een bestand bij een specifieke commit - **Interne API-wrapper** — roept je eigen REST API aan met ingebouwde auth-headers ## Veelgestelde vragen ### Heb ik een Anthropic API-sleutel nodig om een MCP-server te bouwen? Nee. Je MCP-server roept de Anthropic API niet aan. Het reageert alleen op toolaanroepverzoeken van de client. De API-sleutel bevindt zich in de client, niet in de server. ### Kan mijn MCP-server externe API's aanroepen? Ja — de handler is gewoon asynchrone TypeScript-code. Haal een weer-API op, bevraag een database, schrijf naar een bestand. De server geeft niet om wat de handler intern doet. ### Wat is het verschil tussen stdio- en HTTP-transport? Stdio is voor lokale servers — dezelfde machine als Claude Desktop of Claude Code. HTTP met SSE is voor externe servers die je als webservice kunt deployen. Begin met stdio; het is eenvoudiger te debuggen. ### Hoe weet Claude wanneer het mijn tool moet aanroepen? Claude beslist op basis van het veld `description` van de tool en de conversatiecontext. Als Claude je tool blijft negeren, verfijn de beschrijving. --- ## Hoe je een bedrijfsidee valideert voordat je het bouwt Source: https://alejandrorioja.com/nl/how-to-validate-a-business-idea/ Published: 2026-06-20 Tags: Entrepreneurship, Growth TL;DR: De meeste bedrijfsideeën mislukken niet door slechte uitvoering, maar omdat validatie wordt overgeslagen. De snelste weg: bevestig dat het probleem bestaat via zoekvolume en bewijs in forums, analyseer concurrenten om te bewijzen dat iemand al geld verdient, bouw de kleinst mogelijke rooktest en krijg een commitment — een aanbetaling, een inschrijving op de wachtlijst, een intentieverklaring — voordat je iets bouwt. Als je niet één persoon kunt laten committeren, is het idee nog niet klaar. ## Table of contents _Bijgewerkt in juni 2026._ **TL;DR:** De meeste bedrijfsideeën mislukken niet door slechte uitvoering, maar omdat validatie wordt overgeslagen. De snelste weg: bevestig dat het probleem bestaat via zoekvolume en bewijs in forums, analyseer concurrenten om te bewijzen dat iemand al geld verdient, bouw de kleinst mogelijke rooktest en krijg een commitment — een aanbetaling, een inschrijving op de wachtlijst, een intentieverklaring — voordat je iets bouwt. Als je niet één persoon kunt laten committeren, is het idee nog niet klaar. **[Standpunt van de operator]** Ik heb dit patroon tientallen keren gezien bij oprichters met wie ik heb gewerkt en in mijn eigen projecten: het idee klinkt overtuigend, de oprichter is gepassioneerd, de uitvoering is solide — en dan lanceren ze in stilte. Niet omdat ze het verkeerde hebben gebouwd, maar omdat ze de ene stap hebben overgeslagen die dat voor zes maanden werk had kunnen vertellen. Hier is het validatieraamwerk dat ik gebruik en aanbeveel. ## Waarom de meeste validatiepogingen mislukken Het voor de hand liggende faalpatroon is helemaal geen validatie — eerst bouwen, later vragen stellen. Maar de subtielere val is validatietheater: enquêtes uitvoeren, met vrienden praten, vage reacties verzamelen als "geweldig idee!" en dat een signaal noemen. Enquêtes liegen. Mensen zijn beleefd. Op de vraag "Zou jij hier 50 dollar voor betalen?" in een hypothetische context is het antwoord bijna altijd ja. Het enige signaal dat telt is commitment: iemand die je daadwerkelijk geld, tijd of een schriftelijke intentieverklaring geeft. Al het andere is ruisonderdrukking, geen validatie. ## Stap 1: Bevestig dat het probleem daadwerkelijk op grote schaal bestaat Voordat je je oplossing valideert, valideer dat het probleem echt is en gezocht wordt. **Zoekvraag is de snelste proxy.** Typ je probleem in Google. Kijk naar de autocomplete-suggesties, de sectie "Mensen vragen ook" en de best gerangschikte pagina's. Als er geen resultaten zijn, zoekt niemand — en een bedrijf dat een probleem oplost dat niemand zoekt, besteedt al zijn energie aan educatie in plaats van conversie. Gebruik een zoekwoordtool zoals [Semrush](/recommends/semrush) om het werkelijke maandelijkse zoekvolume te controleren. Een probleem met 1.000–10.000 maandelijkse zoekopdrachten in je doelmarkt is levensvatbaar. Een probleem met 20 zoekopdrachten per maand is een nicheproduct met een distributioprobleem. **Forumbewijzen zijn een kwalitatieve laag bovenop.** Zoek op Reddit, Quora, niche Facebook-groepen en Discord-communities naar je probleem. Klagen mensen er actief over? Zoeken ze naar oplossingen? Workarounds? Echte frustratie is goud — het betekent dat de pijn sterk genoeg is om mensen te motiveren om publiekelijk om hulp te vragen. Als je geen 20 forumthreads kunt vinden van echte mensen die het probleem beschrijven, wees dan sceptisch. ## Stap 2: Analyseer concurrenten — bewijs dat er al geld bestaat Een veelvoorkomend oprichtersinstinct: "er is geen concurrentie, dus ik domineer de markt." Dit is bijna altijd fout. Geen concurrentie betekent meestal geen markt. Concurrentie is het bewijs dat er klanten zijn die willen betalen. Zoek op Google naar je oplossingscategorie. Wie rankt er? Wat beloven hun landingspagina's? Wat rekenen ze? Lees hun getuigenissen en beoordelingen — vooral de negatieve. Negatieve beoordelingen zijn een productroadmap: ze laten je precies zien wat de markt wil maar niet krijgt. Als je 3–5 gevestigde concurrenten vindt met echte producten en echte klanten, is dat een gezond teken. Als je nul vindt, zoek dan dieper voordat je concludeert dat de markt niet bestaat — of behandel het als een rode vlag. **Belangrijke vragen om te beantwoorden:** 1. Wie zijn de top 3–5 spelers? 2. Wat rekenen ze? 3. Wat bekritiseren beoordelaars? 4. Is er een positioneringsgat dat ik kan innemen? ## Stap 3: Bouw de kleinst mogelijke rooktest Zodra je weet dat het probleem bestaat en er geld in de markt zit, bouw het minimale artefact dat nodig is om te testen of *jouw* versie tractie krijgt. Dit is geen volledig product. Het is een signaalvastlegmechanisme. **Optie A: Landingspagina met e-mailregistratie.** Een eenpagina-website die het probleem en de oplossing beschrijft, met een "Meld je aan voor de wachtlijst" of "Krijg vroege toegang" CTA. Het conversiepercentage vertelt je of je positionering aanslaat. Tools zoals Webflow, Carrd of zelfs een openbare Notion-pagina werken prima — maak het niet te ingewikkeld. **Optie B: Voorverkoop.** Een echte betaalstroom met echt geld. Dit is het signaal van de hoogste kwaliteit. Als iemand je geld geeft voor iets dat nog niet bestaat, geloven ze in de oplossing. Zelfs een terugbetaalbare aanbetaling werkt. **Optie C: Conciërge MVP.** Doe het handmatig voordat je het automatiseert. Consulting in plaats van een SaaS. Een aangepaste spreadsheet in plaats van een softwaretool. Een handmatig gecureerde nieuwsbrief in plaats van een AI-gegenereerde. Je bedient een handvol klanten met brute kracht, leert precies wat ze waarderen en bouwt vervolgens het product daaromheen. ## Stap 4: Krijg een commitment voordat je bouwt Dit is de poort die echte validatie van wishful thinking scheidt. Definieer wat "commitment" betekent voor jouw idee voordat je de rooktest uitvoert: - **SaaS / software:** Een voorverkoop tegen een kortingsprijs, of een ondertekende intentieverklaring - **Content / media:** E-mailabonnees die hebben geklikt om zich aan te sluiten (niet alleen volgers) - **Diensten / consulting:** Een betaald ontdekkingsgesprek of een ondertekend voorstel - **Fysiek product:** Een aanbetaling of een Kickstarter/voorbestelling Als je niet ten minste één persoon kunt laten committeren — zelfs met korting, zelfs met geld-terug-garantie — is het idee nog niet klaar. Dat is geen mislukking; dat is het systeem dat werkt. Het heeft je maanden aan bouwtijd bespaard. ## Stap 5: Stel een slaag/zakdrempel in voordat je begint De val is dit: je voert je rooktest uit, krijgt laauwe resultaten en overtuigt jezelf om toch door te gaan. "De landingspaginatekst was niet goed." "Ik heb het niet genoeg gepromoot." "Het heeft gewoon meer tijd nodig." Stop. Voordat je de test uitvoert, schrijf de drempel op: > "Als ik in 14 dagen 50 wachtlijstregistraties krijg met € 0 aan betaalde advertenties, bouw ik het. Als ik de 50 niet haal, bouw ik het niet — ik verander de positionering of schrap het idee." Schrijf het op. Vertel het een vriend. Maak het openbaar als je kunt. Houd je er dan aan. Het getal is willekeurig; wat telt is dat je van tevoren beslist en de doelpalen niet verplaatst als de data koud binnenkomt. ## Veelgemaakte validatiefouten 1. **Mensen vragen of ze het zouden kopen.** Ze zeggen bijna altijd ja om beleefd te zijn. De enige vraag die telt: "Koop jij het nu?" 2. **Valideren met vrienden en familie.** Ze moedigen je aan. Ze zijn niet je klant. 3. **Je eigen probleem oplossen zonder te controleren of anderen het ook hebben.** Jouw probleem kan uniek voor jou zijn. Controleer de forums. 4. **Enquêtereacties validatie noemen.** Een enquête kan ideeën genereren. Het kan de vraag niet valideren. Alleen geld of echte commitment kan dat. 5. **Wachten op perfecte informatie.** Validatie gaat over het verkrijgen van genoeg signaal om de volgende stap te zetten, niet over het volledig elimineren van onzekerheid. ## Wat "ga"-signalen betekenen Je zoekt naar een combinatie van: 1. Zoekvolume boven 1.000 maandelijkse zoekopdrachten voor het kernprobleemzoekwoord 2. Concurrentieactiviteit — 3+ echte spelers die echt geld vragen 3. Minimaal 20 forum- of communitythreads die actieve frustratie met het probleem tonen 4. Een rooktest-conversiepercentage van meer dan 5% op gericht verkeer 5. Minimaal één persoon committeert — betaalt, ondertekent of betaalt een aanbetaling — zonder dat je hoeft te smeken Haal alle vijf en je hebt een levensvatbare richting. Haal twee of drie en je hebt een signaal dat de moeite waard is om te verfijnen. Haal nul en je hebt een fundamenteel ander idee of publiek nodig. ## De validatiestack De tools die ik gebruik en aanbeveel voor dit proces: - **Zoekvraag:** [Semrush](/recommends/semrush) — zoekwoordvolume, concurrentieanalyse en contenthiaten op één plek - **Forumonderzoek:** Reddit, Quora, niche Facebook-groepen, Discord-communities - **Landingspagina:** Carrd (gratis, snel) of Webflow voor meer ontwerpcontrole - **E-mailregistratie / wachtlijst:** Kit (ConvertKit) om de lijst te bouwen terwijl je valideert - **Betalingen:** Stripe — link direct naar een betaalpagina voordat je het product bouwt - **Analytics:** Google Analytics op je rooktestpagina om echt gedrag bij te houden ## De conclusie van de operator Het duurste wat je kunt bouwen is een product dat niemand wil. Validatie gaat niet over het elimineren van risico — het gaat over snel falen op papier in plaats van langzaam falen in productie. Voer de rooktest uit, krijg een commitment, stel de drempel in voordat je begint en eerbiedig het resultaat. Als het signaal er is, zul je het weten. Als het er niet is, weet je dat ook. --- **Gerelateerd:** [Hoe je een winstgevend bedrijf opbouwt](/how-to-build-profitable-business/) · [Gids voor groeimariketingstrategieën](/growth-marketing-strategies-guide/) · [Hoe je ondernemer wordt](/how-to-become-an-entrepreneur/) --- ## Prompt caching met de Claude API: verlaag je invoerkosten zonder van model te wisselen Source: https://alejandrorioja.com/nl/prompt-caching-cut-your-claude-costs-without-switching-models/ Published: 2026-06-18 Updated: 2026-06-18 Tags: AI Agents, Operations TL;DR: Prompt caching verlaagt de kosten van grote, stabiele invoer — je systeemprompt, tooldefinities, few-shot-voorbeelden — tot ongeveer 10% van het normale invoertarief bij herhaalde verzoeken. Het mechanisme is een prefix-match: plaats een cache_control-marker aan het eind van je stabiele content en houd alles wat verandert daarna. De fout die je cache-hitratio om zeep helpt, is een timestamp of UUID in de prefix laten sluipen. ## Table of contents _Bijgewerkt juni 2026._ **TL;DR:** Prompt caching verlaagt de kosten van grote, stabiele invoer — je systeemprompt, tooldefinities, few-shot-voorbeelden — tot ongeveer 10% van het normale invoertarief bij herhaalde verzoeken. Het mechanisme is een prefix-match: plaats een `cache_control`-marker aan het eind van je stabiele content en houd alles wat verandert daarna. De fout die je cache-hitratio om zeep helpt, is een timestamp of UUID in de prefix laten sluipen. **[Operator's read]** Ik draai 100+ agents over mijn consultancymerk en Pickleland. De grootste kostenpost is niet de modelklasse — het is hoe vaak ik dezelfde systeemprompt van 4.000 tokens bij elk verzoek opnieuw verstuur. Prompt caching bracht die kosten op agents met hoge frequentie terug tot bijna nul, zonder het model of de uitvoerkwaliteit aan te raken. Hier lees je precies hoe het werkt en waar de valkuilen zitten. ## Wat prompt caching werkelijk doet Elke aanroep naar de [Claude](/recommends/claude) API verstuurt tokens. Zonder caching wordt elk token in je verzoek — systeemprompt, tooldefinities, few-shot-voorbeelden en het gebruikersbericht — afgerekend tegen het normale invoertarief. Met caching wordt na het eerste verzoek een prefix van die tokens opgeslagen op de servers van Anthropic. Bij volgende verzoeken die diezelfde exacte prefix delen, betaal je een cache-*read*-prijs in plaats van ze opnieuw vanaf nul te verwerken. Het kostenverschil is reëel: - **Cache write:** ~1,25× het basisinvoertarief (TTL van 5 minuten) of ~2× (TTL van 1 uur) - **Cache read:** ~0,1× het basisinvoertarief - **Break-even:** 2 verzoeken bij een TTL van 5 minuten, 3 verzoeken bij een TTL van 1 uur Zodra je voorbij het break-evenpunt bent — wat snel gebeurt bij elke agent die meer dan een paar keer per dag draait — levert elke extra cache-hit een korting van ~90% op die tokens op. ## Het prefix-match-principe Dit is de ene regel waaruit al het andere volgt: **de cachesleutel is een prefix-match van je gerenderde prompt**. De servers van Anthropic slaan de gerenderde content op vanaf het begin van je prompt tot aan de `cache_control`-marker. Voor een cache-hit bij het volgende verzoek moet elk token vanaf het begin van de prompt tot aan die marker identiek zijn — byte voor byte. De rendervolgorde voor prefix-matching is: tools → system → messages. Je tools-array wordt dus eerst gehasht, daarna het system-blok, en vervolgens de messages op volgorde. Wat dit in de praktijk betekent: stabiele content moet als eerste komen. Als je systeemprompt naar iets dynamisch verwijst — een huidige datum, een gebruikers-ID, een trace-ID van een verzoek — en dat *vóór* de `cache_control`-marker staat, mist de cache bij elk verzoek omdat de prefix steeds verandert. ## Waar je een cache-marker op zet De doelwitten met de meeste hefboom zijn: **1. Je systeemprompt** Systeemprompts zijn meestal het grootste stabiele blok. Een gedetailleerde agent-persona, een lijst met gedragsregels, een set instructies voor het uitvoerformaat — dit alles is identiek bij elke aanroep van dezelfde agent. Markeer het: ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic(); const response = await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1024, system: [ { type: "text", text: `You are a content operations agent for alejandrorioja.com. Your job is to draft blog posts in Alejandro's voice: direct, practitioner, first-person, numbered lists, honest caveats. No hedging. No filler. Every section must earn its place. [... 2000 more tokens of stable instructions ...]`, cache_control: { type: "ephemeral" }, }, ], messages: [ { role: "user", content: "Draft a post about prompt caching.", }, ], }); ``` De `cache_control: { type: "ephemeral" }` op het system-blok vertelt Claude om alles tot en met dat blok te cachen. De `messages`-array is veranderlijk — anders bij elk verzoek — en blijft buiten de cachegrens. **2. Tooldefinities** Als je agent tools gebruikt, kunnen die definities aanzienlijk zijn. Een goed gedocumenteerd toolschema met beschrijving, parameternamen en enum-waarden kan oplopen tot 500–1.000 tokens per tool. Met 5 tools is dat tot 5.000 tokens die je bij elke aanroep opnieuw moet betalen om te verwerken: ```typescript const response = await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1024, tools: [ { name: "search_airtable", description: "Search the Airtable content queue...", input_schema: { type: "object", properties: { query: { type: "string" } } }, }, // ... more tools ... { name: "post_to_kit", description: "Schedule a broadcast via the Kit API...", input_schema: { /* ... */ }, // Mark the last tool to cache the entire tools array } as Anthropic.Tool & { cache_control: { type: "ephemeral" } }, ], system: "...", messages: [...], }); ``` Markeer de *laatste* tool in de array. De prefix-match dekt vanaf dat punt de volledige tools-array. **3. Few-shot-voorbeelden in messages** Als je statische few-shot-voorbeelden als vroege berichten in de `messages`-array meegeeft, kunnen die ook gecachet worden. Structureer ze als de eerste N berichten en markeer de laatste voorbeeldbeurt: ```typescript const messages: Anthropic.MessageParam[] = [ { role: "user", content: [ { type: "text", text: "Here are examples of posts in my voice:\n\n[Example 1...]\n\n[Example 2...]", cache_control: { type: "ephemeral" }, } as Anthropic.TextBlockParam & { cache_control: { type: "ephemeral" } }, ], }, { role: "assistant", content: "Understood. I'll follow that voice.", }, // The actual user turn follows — this is volatile, no cache marker { role: "user", content: actualUserRequest, }, ]; ``` ## Wat je NIET moet cachen (stille cache-brekers) Dit zijn de dingen die er stabiel uitzien maar dat niet zijn — en ze helpen je hitratio stilletjes om zeep. De API waarschuwt je niet. Je ziet gewoon `cache_creation_input_tokens` bij elk verzoek en vraagt je af waarom. **Timestamps in de systeemprompt.** De allergrootste klassieker: ```typescript // This invalidates the cache on every request const system = `You are an agent. Current time: ${new Date().toISOString()}`; ``` Verplaats timestamps naar het gebruikersbericht, waar ze thuishoren: ```typescript // Stable system prompt — cacheable const system = `You are an agent. Use the current time provided by the user.`; // Volatile user message — not cached const userMessage = `Current time: ${new Date().toISOString()}. Run the daily brief.`; ``` **Willekeurige UUID's en trace-ID's.** Hetzelfde probleem. Als je een trace-ID in het system-blok injecteert voor logging, krijgt elk verzoek een verse prefix. **Niet-deterministische JSON-serialisatie.** Als je een object in de systeemprompt serialiseert en de volgorde van de sleutels niet gegarandeerd is, kan de gerenderde string verschillen, zelfs als de onderliggende data hetzelfde is. Serialiseer met een stabiele sleutelvolgorde of gebruik een template-string. **Dynamische few-shot-selectie.** Als je few-shot-voorbeelden kiest op basis van de huidige query en ze in de gecachete prefix plaatst, heb je de "stabiele" prefix query-afhankelijk gemaakt. Kies óf voor vaste voorbeelden voor de cachelaag, óf verplaats dynamische voorbeelden naar de niet-gecachete berichtbeurt. ## Je cache-hitratio verifiëren Elke respons bevat usage-metadata. Controleer die: ```typescript const response = await client.messages.create({ /* ... */ }); console.log({ inputTokens: response.usage.input_tokens, cacheRead: response.usage.cache_read_input_tokens, cacheWrite: response.usage.cache_creation_input_tokens, outputTokens: response.usage.output_tokens, }); ``` Bij het eerste verzoek: `cache_creation_input_tokens` is niet nul, `cache_read_input_tokens` is 0. Dat is de write. Bij een cache-hit: `cache_read_input_tokens` is niet nul, `cache_creation_input_tokens` is 0. Dat is de read. Als je bij elk verzoek `cache_creation_input_tokens` ziet, verandert je prefix. Voeg een logregel toe die de eerste 200 tekens van je gerenderde systeemprompt afdrukt vóór elke aanroep — een rondzwervende timestamp valt dan meteen op. ## De TTL van 1 uur: wanneer de extra writekosten de moeite waard zijn De standaard-TTL is 5 minuten. Als je agent met lage frequentie draait — minder dan eens per 5 minuten — betaal je bij de meeste verzoeken writekosten zonder reads te krijgen. ```typescript // Opt into a 1-hour TTL cache_control: { type: "ephemeral", ttl: "1h" } ``` De write van 1 uur kost ~2× het basisinvoertarief in plaats van 1,25×. De rekensom: als je de cache 3 of meer keer per uur raakt, bespaart de TTL van 1 uur geld. Als je agent eens per dag draait (zoals mijn daily brief), helpt zelfs de TTL van 1 uur niet — je betaalt elke keer writekosten. In dat geval is het cachevoordeel bescheiden, tenzij de systeemprompt enorm is. Mijn daily-brief-agent heeft een systeemprompt van 3.000 tokens maar draait eens per dag. Caching helpt niet. Mijn nieuwsbriefagent draait tientallen keren per sessie tijdens het schrijven — caching bespaart aanzienlijk. ## Pre-warming: het eerste verzoek goedkoop maken Als je een bekende verkeerspiek ziet aankomen — een batchtaak, een API-launch — kun je de cache pre-warmen met een goedkoop dummyverzoek: ```typescript // Pre-warm: write the cache at near-zero output cost await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1, // minimal output system: [{ type: "text", text: stableSystemPrompt, cache_control: { type: "ephemeral" } }], messages: [{ role: "user", content: "ping" }], }); // Now the real requests read from cache ``` Dit is vooral nuttig bij batchverwerking, waarbij je veel parallelle verzoeken opstart en wilt dat elk ervan een warme cache raakt in plaats van te racen om hem te schrijven. ## Prompt caching in agent-loops In een agent-loop met meerdere beurten groeit de gespreksgeschiedenis bij elke beurt. De cache is slim genoeg om hiermee om te gaan: hij gebruikt een lookback-venster van 20 blokken en vindt de langste passende prefix binnen de laatste 20 contentblokken. De praktische implicatie: houd je stabiele content (systeemprompt, tooldefinities) verankerd aan de bovenkant. De groeiende gespreksgeschiedenis aan het eind van de messages-array breekt de prefix-match voor de stabiele blokken niet — die staan vóór de veranderlijke content, en de prefix-match begint bovenaan. In de praktijk structureren mijn agents de beurten zo: ``` System (cached) → Tools (cached) → Few-shot (cached) → Turn 1 → Turn 2 → ... → Current turn ``` De cache dekt alles tot aan de few-shot-marker. De groeiende beurtgeschiedenis daarna wordt elke keer opnieuw verwerkt, maar dat is prima — die tokens zijn sessiespecifiek en klein ten opzichte van de stabiele prefix. ## Hoe het op de rekening uitpakt Neem een agent met hoge frequentie: 100 aanroepen per dag, systeemprompt van 4.000 tokens, Sonnet-tarief. Zonder caching: - 100 × 4.000 tokens × $3/1M = **$1,20/dag** Met caching (TTL van 5 min, uitgaande van 50 aanroepen/uur tijdens de piek): - 1 write per 5 minuten × $3,75/1M × 4.000 tokens = ~$0,02/dag aan writes - ~98 reads/dag × $0,30/1M × 4.000 tokens = **$0,12/dag aan reads** Dat is ongeveer een reductie van 90% op die invoertokens. Op schaal — 1.000 aanroepen per dag — loopt het verschil verder op. En dit komt bovenop eventuele besparingen door modelroutering uit de [Haiku-vs-Sonnet-rekensom](/ai-agent-cost-math-when-haiku-beats-sonnet): caching werkt op elke klasse. ## De bottom line voor de operator Prompt caching is de makkelijkste kostenoptimalisatie in de Claude API: één extra veld op de contentblokken die je toch al schrijft. De beperking is discipline rond prefix-stabiliteit — niets dynamisch vóór de cache-marker. Als je je systeemprompt, tools en eventuele statische voorbeelden vrij kunt houden van veranderlijke content, betaal je ~10% van de normale invoerkosten bij elke cache-hit. Voor agents met hoge frequentie en grote, stabiele prompts is dit een grotere hefboom dan wisselen van modelklasse. --- **Gerelateerd:** [AI-agentkostenberekening: wanneer Haiku Sonnet verslaat](/ai-agent-cost-math-when-haiku-beats-sonnet/) · [Event-getriggerde versus geplande agents](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) · [De 5 AI-tools die ik echt gebruik om mijn bedrijf te runnen](/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/) --- ## Claude Fable 5 eerste indrukken: de kijk van een operator Source: https://alejandrorioja.com/nl/claude-fable-5-first-impressions/ Published: 2026-06-12 Updated: 2026-06-12 Tags: AI Agents TL;DR: Fable 5 is het meest capabele model van Anthropic en dat merk je bij zware agenttaken met een lange horizon — maar het is niet de standaardupgrade. Het kost meer per token, gebruikt een nieuwe tokenizer die je tokenaantallen met ~30% opblaast, draait altijd-aan thinking die je niet kunt uitzetten, en kan verzoeken weigeren op classifierniveau. Voor de meeste workloads is Opus 4.8 nog steeds de juiste keuze. Grijp naar Fable 5 wanneer de taak echt moeilijk is. ## Inhoudsopgave _Bijgewerkt juni 2026._ **TL;DR:** Fable 5 is het meest capabele model van Anthropic en dat merk je bij zware agenttaken met een lange horizon — maar het is niet de standaardupgrade. Het kost meer per token, gebruikt een nieuwe tokenizer die je tokenaantallen met ~30% opblaast, draait altijd-aan thinking die je niet kunt uitzetten, en kan verzoeken weigeren op classifierniveau. Voor de meeste workloads is Opus 4.8 nog steeds de juiste keuze. Grijp naar Fable 5 wanneer de taak echt moeilijk is. **[Operator-perspectief]** Ik draai 30+ agents in productie verspreid over een consultancymerk en een pickleballfaciliteit, dus een nieuw vlaggenschipmodel is voor mij geen benchmark — het is een kostenpost en een migratie. Hier is wat er veranderde toen ik Fable 5 daadwerkelijk in een paar ervan inbouwde, en waar ik Opus 4.8 liet staan. ## Wat Fable 5 eigenlijk is [Claude](/recommends/claude) Fable 5 is het meest capabele model dat Anthropic op grote schaal heeft uitgebracht. Het is gericht op het veeleisende eind van het spectrum: diep redeneren en agentwerk met een lange horizon — de runs waarin een agent een plan moet vasthouden over tientallen tool calls zonder de draad kwijt te raken. Het API-oppervlak is vrijwel identiek aan Opus 4.7/4.8, wat het makkelijk maakte om te testen. Standaard een contextvenster van 1M tokens, tot 128K outputtokens per verzoek. Als je iets hebt gebouwd op de recente Opus-lijn, is de vorm van het verzoek vertrouwd. De verschillen zitten in de details, en in de details zitten het geld en de verrassingen. Eén opmerking over de naamgeving, zodat je niet in de war raakt: **Mythos 5** is hetzelfde model — dezelfde mogelijkheden, dezelfde prijsstelling, hetzelfde gedrag — alleen beschikbaar via het Project Glasswing-programma van Anthropic. Zit je niet in dat programma, dan is het model dat je wilt `claude-fable-5`. Alles hieronder geldt voor beide. ## Waar het echt beter is Ik gooide eerst mijn zwaarste agenttaak ertegenaan: een research-en-synthese-run in meerdere stappen die een stapel bronnen leest, claims kruislings controleert en een onderbouwde briefing schrijft. Dit is het soort werk waarbij zwakkere modellen afdwalen — ze raken het spoor bijster welke claim van welke bron kwam, zo'n tien tool calls verderop. Fable 5 hield de draad vast. De synthese was strakker, de bronvermeldingen bleven aan de juiste claims gekoppeld, en het ving twee tegenstrijdigheden tussen bronnen op die mijn Opus 4.8-versie stilletjes had weggemiddeld. Bij lang, gestructureerd redeneren is het een echte stap vooruit — geen marginaal benchmarkstapje. Dat is het eerlijke argument ervoor. Als de faalmodus van je agent is "valt uit elkaar bij de moeilijke 10%", dan verkleint Fable 5 die kloof. Als je agent nieuwsbrieven samenvat of socialmediaposts opstelt, zul je het verschil niet voelen — en betaal je voor capaciteit die je niet gebruikt. ## De kostenval waar niemand je voor waarschuwt Hier komt degene die je raakt als je de release notes te snel doorleest. Fable 5 komt met een **nieuwe tokenizer**, en dezelfde inhoud tokeniseert tot grofweg **30% meer tokens** dan op de Opus-lijn. Lees dat nog eens, want het stapelt op met de prijs. Fable 5 is om te beginnen al hoger geprijsd dan het Opus-niveau ($10 per miljoen inputtokens, $50 per miljoen outputtokens). Leg daar nu een tokeninflatie van ~30% bovenop elke prompt en completion. Een ongewijzigde workload — dezelfde prompts, dezelfde outputs — kan na migratie merkbaar meer kosten, voordat je ook maar iets hebt veranderd aan wat de agent doet. Dus hergebruik je oude cijfers niet. Je `max_tokens`-instellingen, je contextvensterbudgetten, je schattingen van kosten per run — die zijn allemaal gemeten op een andere tokenizer. Het goede nieuws: het token-counting-endpoint geeft aantallen terug onder **beide** tokenizers wanneer je `model: "claude-fable-5"` meegeeft, dus je kunt de delta op je echte prompts meten voordat je iets omzet. ```bash # Measure the tokenizer delta on YOUR prompt before migrating. # The response includes input_tokens (new) AND input_tokens_prior_tokenizer (old). curl https://api.anthropic.com/v1/messages/count_tokens \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "claude-fable-5", "messages": [{"role":"user","content":""}] }' ``` Ik draaide dit eerst over mijn zwaarste prompts. De delta was niet uniform — het varieert per inhoud — maar "budgetteer ~30% meer, en tel daar de prijspremie bij op" was het juiste mentale model. ## Thinking staat altijd aan — en je kunt het niet uitzetten Op Fable 5 draait adaptieve thinking altijd. De ene nieuwe breaking change ten opzichte van de Opus-lijn: als je een expliciete `thinking: {type: "disabled"}` stuurt, krijg je een 400. De oplossing is simpel — laat de `thinking`-parameter gewoon helemaal weg — maar als je code had die thinking expliciet uitschakelde voor goedkope, snelle calls, dan geeft die code nu een fout. Je krijgt ook de ruwe gedachtegang niet terug. Fable 5 beschermt die: je ontvangt normale `thinking`-blokken, en je kunt om een leesbare samenvatting vragen met `display: "summarized"`, maar de ongefilterde redenering wordt nooit blootgegeven. Voor de meeste apps is dit geen probleem — lees de samenvatting als je inzicht nodig hebt. Waar het wél uitmaakt, is bij **multi-turn agents**: wanneer je een gesprek voortzet op hetzelfde model, moet je de thinking-blokken **ongewijzigd** terugsturen. Laat je ze weg of bewerk je ze, dan breekt de beurt. Als je agentlussen bouwt, behandel thinking-blokken dan als ondoorzichtige tokens die je woordelijk meedraagt. ## Weigeringen zijn nu een control-flowprobleem Dit is de verandering die het meest invloed heeft op hoe je de code rond het model schrijft. Fable 5 draait safety classifiers op binnenkomende verzoeken, vooral gericht op onderzoeksbiologie en de meeste cybersecurity-inhoud. Wanneer een verzoek wordt afgewezen, krijg je een **geslaagde HTTP 200** met `stop_reason: "refusal"` — geen fout, geen exception. De `content`-array kan leeg zijn. Als je code `response.content[0].text` doet zonder eerst `stop_reason` te controleren, crasht hij op de dag dat een verzoek wordt geweigerd. En aanpalend onschuldig werk — legitieme securitytooling, levenswetenschappelijke taken — kan af en toe een false positive triggeren, dus dit is niet alleen een probleem voor mensen die louche dingen doen. De regel is: **vertak op `stop_reason`, nooit op `stop_details`.** ```typescript const res = await client.messages.create({ model: "claude-fable-5", max_tokens: 1024, messages, }); if (res.stop_reason === "refusal") { // classifiers declined — content is empty or partial. Don't read content[0]. await handleRefusal(res); } else { console.log(res.content[0].text); } ``` Voor productie is er een nettere weg: een server-side `fallbacks`-parameter (in beta) die een geweigerd verzoek automatisch opnieuw probeert op `claude-opus-4-8` binnen dezelfde round trip, met krediet-achtige herprijzing toegepast. Als je agents onbeheerd draait, sluit dat dan aan zodat één enkele false-positive-weigering niet een hele run laat doodlopen. Dit is dezelfde les die ik telkens opnieuw leer over agents die [in productie blijven falen](/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it/): dat het model slimmer wordt, neemt niet de noodzaak weg om zijn randgevallen af te handelen — het verplaatst de randgevallen alleen. ## Nog twee migratiedetails Een paar kleinere dingen die mij tijd kostten, zodat ze jou geen tijd kosten: - **Geen assistant prefill.** Als je output stuurde door de laatste assistantbeurt voor te vullen, dan is dat patroon weg. Gebruik in plaats daarvan structured outputs (`output_config.format`) of instructies in de system prompt. - **30 dagen dataretentie is verplicht.** Fable 5 is niet beschikbaar onder zero-data-retention. Zit je om compliancereden op ZDR, dan valt Fable 5 af en blijft Opus 4.8 je plafond. Controleer dit *voordat* je een migratie plant, niet erna. ## Moet je echt overstappen? Hier is mijn operatorbeslissing nadat ik ermee heb geleefd. **Fable 5 is niet het standaarddoel voor "upgraden naar het nieuwste model" — Opus 4.8 wel.** Dat verrast mensen, maar het is de juiste framing. Opus 4.8 is een model-ID-wissel ten opzichte van 4.7 zonder nieuwe breaking changes, het is goedkoper, en voor de overgrote meerderheid van agentwerk is het qua outputkwaliteit niet te onderscheiden. Fable 5 verdient zijn plek bij de echt moeilijke taken: agents met een lange horizon die coherent moeten blijven over veel stappen, diep multibron-redeneren, de runs waar de fout die je probeert te doden subtiel is. Daarvoor is de capaciteit echt en de premie waard. Voor al het andere — content opstellen, classificatie, routing, samenvatten — betaal je meer tokens tegen een hogere prijs voor kwaliteit die je niet kunt waarnemen. Ik kwam er uiteindelijk op uit beide te draaien. Mijn research-en-synthese-agent verhuisde naar Fable 5. Al het andere bleef op Opus 4.8. Die splitsing is het hele punt: kies het model per taak, niet per mode. Als je een vloot agents draait, geldt dezelfde discipline waar ik over schreef in [mijn 2026 operator-stack](/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/) — stuur het zware werk naar het dure model en stop met te veel betalen voor het makkelijke werk. ## De conclusie van de operator Test Fable 5 op je allerzwaarste taak voordat je iets anders aanraakt — daar betaalt het zich uit, en als het daar de naald niet beweegt, doet het dat nergens. Draai de token-counter tegen je echte prompts zodat de tokenizerinflatie van ~30% en de prijspremie je niet verrassen op de factuur. Voeg een `stop_reason: "refusal"`-check toe (of de server-side fallback naar Opus 4.8) overal waar Fable 5 productie raakt. Route vervolgens bewust: Fable 5 voor de moeilijke 10%, Opus 4.8 voor de rest. Het beste model is niet het meest capabele — het is het model dat past bij de taak. --- ## De ultieme beginnersgids voor AI-agents: Cowork, Codex en de tools die het werk echt doen Source: https://alejandrorioja.com/nl/ai-agents-for-beginners-cowork-codex-guide/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: AI-agents zijn de stap voorbij chatbots: je geeft ze een doel in gewoon Nederlands en zij doen het werk — bestanden lezen, opstellen, organiseren, code schrijven en uitvoeren. Cowork is de instapvriendelijke no-code-route; Codex en Claude Code zijn voor wie met een codebase werkt. De vaardigheid die telt, is een heldere, goed afgebakende instructie schrijven, niet leren programmeren. ## Table of contents _Bijgewerkt juni 2026._ **TL;DR:** AI-agents zijn de stap voorbij chatbots: je geeft ze een doel in gewone taal en zij doen het werk — bestanden lezen, opstellen, organiseren, code schrijven en uitvoeren, en hun eigen resultaat controleren. **Cowork** is de no-code-instapRoute voor niet-technici; **Codex** en **Claude Code** zijn voor wie met een codebase werkt. De enige vaardigheid die telt, is een heldere, goed afgebakende instructie schrijven — niet leren programmeren. **[Noot van de auteur]** Ik beheer dagelijks meer dan 30 gecodeerde agents, maar de meeste mensen hebben geen code nodig om 80% van de waarde te benutten. Ze hebben een heldere instructie nodig en een plek om die uit te voeren. Deze gids is de introductie die ik een slimme vriend zou geven die nog nooit een regel code heeft geschreven. ## Wat een "AI-agent" eigenlijk is Een chatbot beantwoordt een vraag. Een **agent** voert een taak uit. Het verschil is dat een agent acties in een lus kan nemen — een document lezen, beslissen wat er daarna moet gebeuren, een bestand schrijven, een opdracht uitvoeren, het resultaat controleren, herstellen wat kapot is — zonder dat jij elke stap hoeft te sturen. Concreet: je vraagt niet "hoe ruim ik dit spreadsheet op?" Je zegt "hier is het spreadsheet — verwijder duplicaten, herstel de datumnotaties en markeer rijen met ontbrekende e-mailadressen", en de agent doet het en geeft je het opgeruimde bestand terug. Die verschuiving — van *advies* naar *afgerond werk* — is het hele punt. ## De twee gereedschapsfamilies Er zijn twee ingangen tot deze wereld, en je hebt alleen de ingang nodig die bij jouw werk past. ### Deur 1: No-code-agents (begin hier als je niet programmeert) **Claude Cowork** is een werkruimte waar je Claude een doel plus de materialen geeft — bestanden, links, notities — en het het resultaat produceert dat jij beoordeelt en gebruikt: een concept, een samenvatting, een plan, een opgeruimd spreadsheet. Je schrijft instructies, geen code. Denk aan "een zeer capabele assistent die snel leest en nooit moe wordt", niet aan "een programmeertool". Dit is het juiste startpunt voor marketeers, oprichters, operators, schrijvers, analisten — iedereen wiens werk voornamelijk uit documenten, onderzoek en beslissingen bestaat. ### Deur 2: Coding-agents (gebruik deze zodra een codebase betrokken is) **OpenAI Codex** en **Claude Code** zijn agents die leven waar software wordt gebouwd — een terminal, een IDE of de cloud. Je beschrijft een wijziging ("voeg een donkere-modus-schakelaar toe", "herstel deze falende test", "migreer dit bestand naar de nieuwe API") en de agent bewerkt de code, voert het uit en itereert totdat het werkt. Jij blijft alles beoordelen; de agent doet het typen. Je hoeft geen senior engineer te zijn om deze te gebruiken. Veel niet-ontwikkelaars gebruiken coding-agents om kleine websites te lanceren, spreadsheets als scripts te automatiseren en bugs te herstellen in tools die ze niet zelf hebben geschreven. Maar er is een echte leercurve, dus de meeste beginners zijn beter af als ze bij Deur 1 beginnen en door Deur 2 lopen zodra ze een taak tegenkomen die echt code vereist. ## Je eerste succes (doe dit vandaag) Kies een kleine, vervelende taak die je vaak doet. Goede eerste kandidaten: - Een rommelig vergaderverslag omzetten in nette aantekeningen plus een actiepuntenlijst. - Een lang PDF samenvatten in 5 opsommingstekens en 3 vragen die de moeite waard zijn om te stellen. - Een ruwe e-mail herschrijven zodat die helder, warm en korter dan 120 woorden is. Gebruik dan de structuur die agents betrouwbaar maakt in plaats van onvoorspelbaar — **rol → invoer → exacte instructie → beperking → een controle**: > Je bent mijn assistent. Hier is een [vergaderverslag / PDF / concept-e-mail] hieronder geplakt. Doe dit: [zet het om in nette aantekeningen met een vetgedrukte lijst \"Actiepunten\" / vat samen in 5 opsommingstekens + 3 vervolgvragen / herschrijf het zodat het helder, warm en korter dan 120 woorden is]. Bewaar mijn stem. Stel me één vraag als iets onduidelijk is voordat je begint. > > [plak hier je inhoud] Dat is alles. Je hebt zojuist een taak gedelegeerd. De structuur is het hele spel — en het werkt identiek in Cowork, ChatGPT of een coding-agent. ## De vierdelige prompt die agents betrouwbaar maakt Beginners denken dat het geheim een magische zin is. Dat is het niet. Het is specificiteit. Elke betrouwbare agentinstructie heeft vier onderdelen: 1. **Rol** — wie de agent is voor deze taak ("Je bent mijn onderzoeksassistent"). 2. **Context** — de materialen en het *waarom* ("Ik bereid me voor op een verkoopgesprek met een fintech-oprichter"). 3. **Taak** — de exacte, afgebakende actie ("Haal drie recente feiten over financieringsrondes op en stel twee openingsvragen op"). 4. **Beperkingen + een controle** — opmaak, lengte, toon en een instructie om te vragen in plaats van te gokken ("Alleen opsommingstekens, vermeld bronnen, stel me één verduidelijkende vraag als het bedrijf onduidelijk is"). Vaag erin, vaag eruit. Hoe meer een agent kan *doen*, hoe meer jouw helderheid ertoe doet — een chatbot die verkeerd begrijpt verspilt een zin; een agent die verkeerd begrijpt verspilt een middag werk die je ongedaan moet maken. ## Beginnersfouten die je kunt overslaan - **Het als een zoekmachine behandelen.** Stel geen vragen van één regel. Geef het echt werk met echte bestanden. - **De beperking weglaten.** "Schrijf me een plan" geeft je een tekstmuur. "Schrijf me een eenpagina-plan met drie fasen en een verantwoordelijke per taak" geeft je iets bruikbaars. - **Geen controle vragen.** Voeg "stel me één vraag als iets onduidelijk is" toe en je vangt misverstanden *voordat* de agent begint, niet erna. - **Coding-agents onbeheerd laten draaien op belangrijke code.** Controleer de diff. Agents zijn snel en meestal correct, maar "meestal" doet werk in die zin — houd een mens in de lus bij alles wat live gaat. - **Te snel naar Deur 2 springen.** Als je taak documenten en beslissingen betreft, hoef je nooit een terminal te openen. ## Hoe je je eerste tool kiest - **Je werk betreft documenten, onderzoek en schrijven** → begin met **Cowork** (of het chatproduct waarvoor je al betaalt, gebruikt in agentmodus). - **Je wilt software bouwen of herstellen** → **Claude Code** of **OpenAI Codex**. - **Je wilt terugkerend, hands-off werk** (een dagelijks digest, een wekelijks rapport) → ga over naar **[geplande taken](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/)** zodra je de prompt handmatig onder de knie hebt. ## AI-agents voor beginners — FAQ 2026 ### Moet ik kunnen programmeren om AI-agents te gebruiken? Nee. No-code-agents zoals Claude Cowork zijn gebouwd voor niet-technische gebruikers — je schrijft instructies in gewone taal. Coding-agents zoals Codex en Claude Code vergen een leercurve, maar zelfs die worden steeds meer gebruikt door mensen die zichzelf geen programmeurs noemen. Begin zonder code, stap over op code alleen als een taak het vereist. ### Wat is het verschil tussen een chatbot en een AI-agent? Een chatbot beantwoordt vragen; een agent voert taken uit. De agent kan een reeks acties nemen — lezen, beslissen, handelen, controleren, herstellen — in een lus, en levert afgerond werk in plaats van advies. In de praktijk doet hetzelfde product vaak beide; de "agentmodus" is het agentgedrag. ### Is Cowork beter dan Codex? Ze zijn voor verschillende taken, niet beter of slechter. Cowork is een no-code-werkruimte voor documenten, onderzoek en operaties. Codex (en Claude Code) zijn coding-agents voor het bouwen en herstellen van software. Kies degene die bij jouw taak past. ### Hoe krijg ik goede resultaten van een AI-agent? Specificiteit. Gebruik de vierdelige structuur: rol, context, exacte taak en beperkingen plus een controle. Geef het echte materialen, vertel het het gewenste formaat en vraag het ambiguïteiten te melden voordat het begint. Heldere instructies tellen meer dan welke "magische prompt" dan ook. ### Is het veilig om AI-agents zelfstandig te laten draaien? Voor laagrisico, omkeerbare taken (opstellen, samenvatten, organiseren), ja — beoordeel de uitvoer en ga verder. Voor alles wat echte systemen verandert (code uitrollen, berichten versturen, gegevens verwijderen), houd een mens in de lus en beoordeel voordat het handelt. Omkeerbaarheid is de juiste test: hoe makkelijker iets ongedaan te maken is, hoe meer autonomie het veilig kan hebben. **Gerelateerde lectuur:** [Hoe je geciteerd wordt in ChatGPT-antwoorden](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) · [Het llms.txt-draaiboek](https://alejandrorioja.com/llms-txt-playbook/) · [Hoe je geplande Claude-taken gebruikt](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/) --- **Wil je hulp bij het inzetten van agents in je bedrijf?** Ik bouw AI-agentsystemen voor operatorteams — [neem contact op](https://alejandrorioja.com/contact/) of lees meer over [hoe ik hierover nadenk](https://alejandrorioja.com/seo-tips/). --- ## Hoe verdient Anthropic geld? Het bedrijfsmodel van Claude uitgelegd Source: https://alejandrorioja.com/nl/how-does-anthropic-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: Anthropic verkoopt toegang tot zijn Claude AI-modellen via vijf hoofdkanalen: een gebruiksgebaseerde API (je betaalt per token), consumentenabonnementen (Claude Pro en Max), enterprise-plannen (Team- en Enterprise-licenties), Claude Code voor ontwikkelaars en distributie via cloudmarktplaatsen zoals Amazon Bedrock en Google Vertex. De API en het enterprise-segment — niet de consumentenapp — zijn de grootste omzetdrijvers. ## Table of contents _Bijgewerkt juni 2026._ **TL;DR:** Anthropic verkoopt toegang tot zijn Claude AI-modellen via vijf hoofdkanalen: een **gebruiksgebaseerde API** (je betaalt per token), **consumentenabonnementen** (Claude Pro en Max), **enterprise-plannen** (Team- en Enterprise-licenties), **Claude Code** voor ontwikkelaars en **distributie via cloudmarktplaatsen** zoals Amazon Bedrock en Google Vertex AI. De API en het enterprise-segment — niet de consumenten-chatapp — zijn de grootste omzetdrijvers. **[Opmerking van de operator]** Ik bouw dagelijks op de API van Anthropic, dus ik zie het bedrijf van binnenuit. Het belangrijkste om te begrijpen: Anthropic is een B2B-bedrijf met een consumenteningang. De chatapp die je gebruikt is marketing en een omzetlijn; het echte geld zit bij ontwikkelaars en bedrijven die tokens meten via de API en op schaal betalen voor licenties. ## Wat is Anthropic Anthropic is een AI-veiligheids- en onderzoeksbedrijf, opgericht in 2021, dat de **Claude**-familie van grote taalmodellen bouwt. Het verkoopt die modellen — en de tools eromheen — aan consumenten, ontwikkelaars en ondernemingen. Het is een privébedrijf, sterk ondersteund door strategische investeerders waaronder Amazon en Google, die ook als cloud- en distributiepartners optreden. Het product is intelligentie als dienst: je koopt geen software in een doos, je huurt toegang tot een model dat voor jou leest, schrijft, redeneert en handelt. Elk kanaal hieronder is een andere verpakking rond datzelfde kernactivum. ## Hoe verdient Anthropic geld? ### 1. De API (gebruiksgebaseerd, de kernmotor) De basis van het bedrijf. Ontwikkelaars en bedrijven roepen Claude aan via een API en betalen **per token** — ruwweg per stukje tekst in- en uitvoer. De prijzen schalen met de modelcapaciteit: - **Claude Opus** (de meest capabele laag) is het hoogst geprijsd — in de orde van enkele dollars per miljoen invoertokens en meerdere malen dat voor uitvoer. - **Claude Sonnet** (het gebalanceerde werkpaard) zit in het midden. - **Claude Haiku** (de snelle, goedkope laag) is het laagst geprijsd, voor eenvoudige taken met hoog volume. Uitvoertokens kosten meer dan invoertokens, en functies zoals lange context, prompt-caching en batchverwerking hebben hun eigen prijzen. De sleuteldynamiek: **omzet schaalt direct mee met gebruik**. Een startup die Claude inbouwt in zijn product en groeit naar miljoenen gebruikers, genereert elke maand meer API-omzet zonder dat Anthropic een nieuwe deal hoeft te sluiten. Dit gebruiksgebaseerde model is waarom AI-labs spreken van zo snel groeiende 'run-rate revenue' — het groeit mee met de eigen groei van klanten. ### 2. Consumentenabonnementen (Claude Pro en Max) De Claude-apps (web, desktop, mobiel) zijn gratis uit te proberen, met betaalde lagen voor mensen die ze intensief gebruiken: - **Claude Pro** — een vaste maandelijkse vergoeding voor hogere gebruikslimieten, toegang tot de beste modellen en functies zoals grotere context en prioriteitstoegang. - **Claude Max** — een duurdere laag voor power-users die de limieten van Pro bereiken, met aanzienlijk meer gebruiksruimte. Dit is het meest zichtbare deel van Anthropic, maar voor een bedrijf waarvan de klanten voornamelijk andere bedrijven zijn, is het een kleiner aandeel dan de API- en enterprise-lijnen. De strategische waarde ervan ligt evenzeer als trechter en merkoppervlak als als inkomstenbron. ### 3. Enterprise (Team- en Enterprise-licenties) Hier zit een groot deel van het duurzame geld. Bedrijven kopen Claude voor hun medewerkers op basis van **licenties per gebruiker**, met plannen gebouwd voor organisaties: - **Team** — voor kleinere bedrijven: gebundeld gebruik, gecentraliseerde facturering, samenwerkingsfuncties. - **Enterprise** — voor grote organisaties: hogere beveiliging en compliance, single sign-on, grotere contextvensters, beheerdersbediening en gebruiksgaranties. Enterprise-deals zijn terugkerend, breiden zich in de loop van de tijd uit (meer licenties, meer gebruik) en brengen het soort overstapkosten mee dat omzet stabiel maakt. Dit is de klassieke SaaS-beweging bovenop het model. ### 4. Claude Code (ontwikkelaarstools) **Claude Code** is Anthropic's agentische coderingstool — een agent die code schrijft, bewerkt en uitvoert in je terminal, IDE of de cloud. Het wordt gemonetariseerd via dezelfde abonnements- en gebruiksrails (het is opgenomen in de Pro/Max/Team/Enterprise-lagen en telt mee tegen je plan). Strategisch doet het twee dingen: het is een omzetlijn op zichzelf, en het drijft veel hoogwaardig tokengebruik aan, omdat codeeragenten een grote hoeveelheid modelcapaciteit verbruiken. ### 5. Cloudmarktplaatsdistributie (AWS, Google en meer) Anthropic verkoopt Claude niet alleen direct — het distribueert ook via de grote cloudplatforms: - **Amazon Bedrock** en **Claude Platform on AWS** — klanten die al op AWS zitten, hebben toegang tot Claude via de infrastructuur en facturering van Amazon. - **Google Vertex AI** en **Microsoft Foundry** — hetzelfde idee op Google Cloud en het platform van Microsoft. Deze kanalen bereiken bedrijven waar hun clouduitgaven en inkoop al plaatsvinden, wat de drempel voor het adopteren van Claude verlaagt. De omzet wordt gedeeld met het platform, maar het bereik is enorm — en de diepe investeringen van Amazon en Google maken deze partnerschappen strategisch, niet alleen commercieel. ### 6. Het opkomende agentplatform Steeds meer verkoopt Anthropic niet alleen ruwe modeloproepen maar ook **agentinfrastructuur** — beheerde diensten waarbij Anthropic de agentlus uitvoert en de omgeving host waarin agenten taken uitvoeren. Naarmate meer klanten overstappen van 'het model een vraag stellen' naar 'een agent het werk laten doen', wordt deze hogere laag een nieuwe plek om waarde te creëren bovenop de per-token-kern. ## Is Anthropic winstgevend? Anthropic is privé en publiceert geen gecontroleerde jaarrekeningen, maar het publieke beeld is hetzelfde als dat van zijn concurrenten: **de omzet groeit extreem snel**, terwijl het bedrijf enorme bedragen uitgeeft aan rekencapaciteit (training en inferentie van modellen) en onderzoekstalent. Zoals andere frontier-AI-labs bevindt het zich in een fase van zware investeringen waarbij omzetgroei, niet de huidige winst, de kop is. De gok die investeerders maken is dat gebruiksgebaseerde omzet blijft groeien naarmate AI in meer software wordt verweven en uiteindelijk de kosten van rekenkracht overtreft. ## Hoe verhoudt dit zich tot OpenAI De structuren zijn vergelijkbaar — beide monetariseren via consumentenabonnementen, een gebruiksgebaseerde API, enterprise-licenties en ontwikkelaarstools. De verschillen zitten in nadruk en partnerschappen: Anthropic zet sterk in op de ontwikkelaars-/enterprise-API en wordt ondersteund door Amazon en Google; OpenAI heeft een groter consumentenaandeel en een diep Microsoft-partnerschap. Als je de andere kant van de vergelijking wilt zien, lees dan [hoe OpenAI geld verdient](https://alejandrorioja.com/how-does-openai-make-money/). ## Omzetmodel van Anthropic — FAQ 2026 ### Wat is de belangrijkste inkomstenbron van Anthropic? De **gebruiksgebaseerde API** en **enterprise-contracten** zijn de zwaarste drijvers. Ontwikkelaars en bedrijven betalen per token om Claude aan te roepen, en organisaties kopen plannen per gebruiker voor hun teams. Het Claude-consumentenabonnement is het meest zichtbare product maar een kleiner aandeel van de omzet dan de zakelijke lijnen. ### Hoe werkt de API-prijsstelling van Claude? Je betaalt per token — invoer en uitvoer gemeten in tekstbrokken. Meer capabele modellen (Opus) kosten meer per token dan gebalanceerde (Sonnet) of snelle (Haiku) modellen, en uitvoertokens kosten meer dan invoertokens. Functies zoals lange context, prompt-caching en batchverwerking hebben hun eigen prijsstelling. De omzet schaalt direct met hoeveel klanten de modellen gebruiken. ### Is Anthropic beursgenoteerd? Nee. Anthropic is een privébedrijf, ondersteund door strategische investeerders en durfkapitalisten, waaronder Amazon en Google. De aandelen zijn niet beschikbaar op openbare beurzen en er is geen bevestigde beursgang. ### Verdient Anthropic geld met de gratis Claude-app? Niet rechtstreeks van gratis gebruikers — de gratis laag is een trechter. Geld komt wanneer gratis gebruikers upgraden naar **Pro** of **Max**, wanneer teams **enterprise-licenties** kopen en vooral wanneer ontwikkelaars op de **API** bouwen. De taak van de gratis app is bereik en merk; de betaalde lagen en de API zijn waar het converteert. ### Wie zijn de grootste klanten van Anthropic? Voornamelijk andere bedrijven: softwarebedrijven die Claude in hun producten integreren via de API, en ondernemingen die Claude uitrollen naar medewerkers. Cloudmarktplaatsdistributie via AWS, Google en Microsoft trekt ook grote enterprise-klanten aan die via hun bestaande cloudproviders kopen. **Gerelateerde lectuur:** [Hoe verdient OpenAI geld](https://alejandrorioja.com/how-does-openai-make-money/) · [De beginnersgids voor AI-agents](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [Hoe je geciteerd wordt in ChatGPT-antwoorden](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- ## De kortere versie Anthropic verhuurt toegang tot zijn Claude-modellen. Ontwikkelaars betalen per token via de API, consumenten betalen maandelijks voor Pro en Max, bedrijven betalen per licentie voor Team en Enterprise, ingenieurs gebruiken Claude Code op diezelfde plannen, en de cloudgiganten (AWS, Google, Microsoft) verkopen Claude door aan bedrijven via hun marktplaatsen. Het is een B2B-bedrijf met een consumenteningang — en de meter, niet de chatapp, is waar het geld zit. --- ## Hoe verdient OpenAI geld? Het businessmodel van ChatGPT en de API Source: https://alejandrorioja.com/nl/how-does-openai-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: OpenAI verdient geld op vier hoofdmanieren: ChatGPT-abonnementen (Plus, Pro, Team, Enterprise, Edu), een gebruiksgebaseerde API waarbij ontwikkelaars per token betalen, grote bedrijfscontracten en het Microsoft-partnerschap (distributie plus een inkomstendeling). Anders dan de meeste AI-labs is het consumentenabonnementsbedrijf van OpenAI zijn grootste inkomstenbron — de schaal van ChatGPT is de motor. ## Table of contents _Bijgewerkt in juni 2026._ **TL;DR:** OpenAI verdient geld op vier hoofdmanieren: **ChatGPT-abonnementen** (Plus, Pro, Team, Enterprise, Edu), een **gebruiksgebaseerde API** waarbij ontwikkelaars per token betalen, grote **bedrijfscontracten** en het **Microsoft-partnerschap** (distributie plus een inkomstendeling). Anders dan de meeste AI-labs is het consumentenabonnementsbedrijf van OpenAI zijn grootste inkomstenbron — de enorme schaal van ChatGPT is de motor. **[Noot voor operators]** OpenAI is het omgekeerde van een typisch enterprise AI-bedrijf: het bouwde eerst een consumentenfenomeen en daarna een ontwikkelaars- en bedrijvenmodel. De honderden miljoenen gebruikers van ChatGPT zijn zowel het merk als de geldmachine. Iedereen in deze ruimte zou dat niveau van instroom bovenaan de funnel willen hebben. ## Wat is OpenAI? OpenAI is het AI-onderzoeksbedrijf achter **ChatGPT** en de **GPT**-modelfamilie, plus producten zoals het videomodel Sora, beeldgeneratie en de programmeersysteemassistent Codex. Opgericht in 2015, bereikte het brede bekendheid toen ChatGPT eind 2022 werd gelanceerd en een van de snelst groeiende consumentenproducten in de geschiedenis werd. De structuur is ongebruikelijk: het begon als een non-profitorganisatie en bouwde een winstgerichte arm met winstlimiet om het enorme kapitaal op te halen dat het trainen van frontier-modellen vereist. Het is niet beursgenoteerd en heeft een diep, meerjarig partnerschap met **Microsoft** dat rekenkracht, distributie en kapitaal levert. Het product is, zoals bij elk AI-lab, intelligentie als dienst — verkocht via consumenten-, ontwikkelaars- en zakelijke kanalen. ## Hoe verdient OpenAI geld? ### 1. ChatGPT-abonnementen (de grootste inkomstenbron) Dit is wat OpenAI onderscheidt van zijn concurrenten. ChatGPT is gratis te gebruiken, met betaalde niveaus die een deel van zijn enorme gebruikersbasis omzetten in terugkerende inkomsten: - **ChatGPT Plus** — een vast maandelijks bedrag voor toegang tot de beste modellen, hogere limieten en premiumfuncties. Het massamarktniveau. - **ChatGPT Pro** — een hoger geprijsd niveau voor power-users die maximaal gebruik en de meest capabele modelinstellingen willen. - **ChatGPT Team** — plannen per seat voor kleine bedrijven, met gedeelde werkruimten en beheerhulpmiddelen. - **ChatGPT Enterprise** — voor grote organisaties: geavanceerde beveiliging, compliance, SSO, grotere context en gebruiksgaranties. - **ChatGPT Edu** — een versie die is afgestemd op universiteiten en scholen. Omdat ChatGPT honderden miljoenen wekelijkse gebruikers bereikt, levert zelfs een laag enkelvoudig conversiepercentage naar betaalde plannen een enorm abonnementsbedrijf op. Deze consumentenschaal is het bepalende voordeel van OpenAI, en abonnementen zijn naar verluidt de grootste inkomstenbron. ### 2. De API (gebruiksgebaseerd, voor ontwikkelaars) Ontwikkelaars en bedrijven integreren OpenAI's modellen in hun eigen producten en betalen **per token** — per stuk tekst (of afbeelding of audio) dat wordt verwerkt. De prijzen schalen met de modelcapaciteit: de toonaangevende redeneermodellen kosten meer per token dan de kleinere, snellere, goedkopere, en output heeft een hogere prijs dan input. De API maakt van elk bedrijf dat op GPT voortbouwt een gemeten klant wiens rekening groeit met zijn eigen gebruik. Dat is dezelfde samengestelde dynamiek waarop elk AI-lab steunt: een startup die OpenAI integreert en opschaalt naar miljoenen gebruikers, genereert elke maand meer API-inkomsten zonder nieuw contract. ### 3. Bedrijfscontracten Naast de self-service API en Team-plannen sluit OpenAI grote, op maat gemaakte overeenkomsten met grote bedrijven — bulkgebruik, toegewijde capaciteit, aangepaste ondersteuning en beveiligings-/complianceverplichtingen. Deze zijn terugkerend, groeien in de loop van de tijd en worden kleverig zodra een bedrijf kritieke workflows bovenop de modellen bouwt. Dit enterprise-traject staat naast het consumentenbedrijf en is een belangrijk groeigebied. ### 4. Het Microsoft-partnerschap Microsoft is OpenAI's grootste strategische partner. De relatie werkt op meerdere assen: - **Rekenkracht** — Microsofts Azure-cloud levert een groot deel van de infrastructuur waarop OpenAI modellen traint en aanbiedt. - **Distributie** — OpenAI's modellen worden aangeboden via Microsofts platforms (Azure AI-diensten, Copilot-producten), waarmee GPT voor Microsofts gigantische zakelijke klantenbasis wordt geplaatst. - **Inkomstendeling** — De twee bedrijven delen inkomsten op grond van hun commerciële overeenkomst, en Microsoft heeft zwaar geïnvesteerd in OpenAI. Dit partnerschap is deels kapitaal, deels go-to-market: het geeft OpenAI toegang tot bedrijven waar het jaren over zou doen om die rechtstreeks te verkopen. ### 5. Nieuwere en aangrenzende producten OpenAI blijft het oppervlak uitbreiden dat het kan monetariseren: - **Codex** — zijn agentisch programmeerhulpmiddel, gemonetariseerd via abonnementen en API-gebruik (en een motor voor zwaar tokenverbruik). - **Sora** — videogeneratie, aangeboden binnen betaalde niveaus en als een product op zichzelf. - **Beeldgeneratie en andere modaliteiten** — gebundeld in abonnementen en gemeten via de API. - **Een ontwikkelaars-/agentecosysteem** — aangepaste GPTs, een agentplatform en hulpmiddelen waarmee bedrijven kunnen bouwen op OpenAI's modellen. Elk hiervan is een andere verpakking rondom hetzelfde kernnasset, gericht op het vastleggen van meer van wat gebruikers en ontwikkelaars bereid zijn te betalen. ## Is OpenAI winstgevend? OpenAI is privaat en publiceert geen gecontroleerde financiële overzichten. Het breed gerapporteerde beeld: **de inkomsten zijn zeer groot en groeien snel**, maar de kosten ook — het trainen van frontier-modellen en het bedienen van honderden miljoenen gebruikers verbruikt verbijsterende hoeveelheden rekenkracht. Net als zijn concurrenten bevindt OpenAI zich in een fase van intensieve investeringen waarbij de prioriteit groei en capaciteit is, niet kortetermijnwinst. De weddenschap is dat schaal plus toenemende bedrijfsadoptie uiteindelijk de rekenkosten overtreft. ## Vergelijking met Anthropic De bouwstenen zijn vergelijkbaar — consumentenabonnementen, een gebruiksgebaseerde API, bedrijfscontracten, programmeerhulpmiddelen — maar de nadruk verschilt. OpenAI's bepalende voordeel is **consumentenschaal** (ChatGPT) en zijn **Microsoft**-partnerschap; Anthropic zet zwaarder in op de **ontwikkelaars-/enterprise-API** en wordt gesteund door Amazon en Google. Voor de andere kant van de vergelijking, zie [hoe Anthropic geld verdient](https://alejandrorioja.com/how-does-anthropic-make-money/). ## OpenAI-inkomstenmodel — FAQ 2026 ### Wat is OpenAI's grootste inkomstenbron? **ChatGPT-abonnementen.** Omdat ChatGPT honderden miljoenen gebruikers bereikt, vormen de betaalde niveaus (Plus, Pro, Team, Enterprise, Edu) OpenAI's grootste inkomstenlijn — een ongebruikelijk profiel voor een AI-lab, waarvan de meeste meer verdienen via API's en bedrijven dan via consumenten. ### Hoe verdient OpenAI's API geld? Ontwikkelaars betalen **per token** om OpenAI's modellen in hun eigen apps te gebruiken — per stuk tekst, afbeelding of audio dat wordt verwerkt. Capabelere modellen kosten meer per token, en output wordt hoger geprijsd dan input. De inkomsten groeien automatisch naarmate het eigen gebruik van klanten groeit. ### Is OpenAI beursgenoteerd? Kan ik OpenAI-aandelen kopen? Nee. OpenAI is privaat en zijn aandelen zijn niet beschikbaar op openbare beurzen. De meeste mensen kunnen niet rechtstreeks instappen. Microsoft heeft via zijn partnerschap een groot belang, maar dat is niet hetzelfde als een beursnotering van OpenAI. ### Hoe levert het Microsoft-partnerschap OpenAI geld op? Microsoft levert Azure-rekenkracht, distribueert OpenAI's modellen via zijn producten en cloud aan een enorme zakelijke klantenbasis, en de twee bedrijven delen inkomsten op grond van hun commerciële overeenkomst. Microsoft heeft ook zwaar geïnvesteerd in OpenAI. Het is zowel een financieringsbron als een distributiekanaal. ### Verdient OpenAI geld aan gratis ChatGPT-gebruikers? Niet direct — de gratis laag is een funnel. Inkomsten komen binnen wanneer gratis gebruikers upgraden naar **Plus** of **Pro**, wanneer bedrijven **Team**- of **Enterprise**-seats kopen, en wanneer ontwikkelaars op de **API** bouwen. De rol van het gratis product is bereik; de betaalde niveaus en de API zetten dat om. **Gerelateerd leesvoer:** [Hoe verdient Anthropic geld](https://alejandrorioja.com/how-does-anthropic-make-money/) · [Hoe verdient SpaceX geld](https://alejandrorioja.com/how-does-spacex-make-money/) · [De beginnersgids voor AI-agenten](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) --- ## De kortere versie OpenAI zet ChatGPT's enorme gebruikersbasis om in abonnementsinkomsten (Plus, Pro, Team, Enterprise), rekent ontwikkelaars per token via zijn API, sluit grote bedrijfscontracten en steunt op Microsoft voor rekenkracht, distributie en gedeelde inkomsten. Zijn bepalende kenmerk is consumentenschaal — de meeste AI-labs monetariseren eerst ontwikkelaars; OpenAI bouwde eerst een consumentenfenomeen en daarna een bedrijf erachter. --- ## Hoe verdient SpaceX geld? Lanceringen, Starlink en de IPO-vraag Source: https://alejandrorioja.com/nl/how-does-spacex-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business TL;DR: SpaceX verdient op drie manieren geld: lanceerservices (het verkopen van ritten naar een baan om de aarde op herbruikbare Falcon-raketten), Starlink (consument-, zakelijk, maritiem/luchtvaart- en overheids-satellietinternet) en overheidscontracten (NASA-bemanning en -vracht, maanlandingssystemen, nationale veiligheidslanceringen). Starlink is nu de grootste inkomstenbron. SpaceX blijft privé; een IPO van SpaceX zelf is niet op handen, hoewel een toekomstige Starlink-afsplitsing al lang wordt gesuggereerd. ## Table of contents _Bijgewerkt juni 2026._ **TL;DR:** SpaceX verdient op drie manieren geld: **lanceerservices** (het verkopen van ritten naar een baan om de aarde op herbruikbare Falcon-raketten), **Starlink** (consument-, zakelijk, maritiem/luchtvaart- en overheids-satellietinternet) en **overheidscontracten** (NASA-bemanning en -vracht, maanlandingssystemen, nationale veiligheidslanceringen). Starlink is nu de grootste inkomstenbron. SpaceX blijft privé; een IPO van SpaceX zelf is niet op handen, hoewel een toekomstige Starlink-afsplitsing al lang wordt gesuggereerd en herhaaldelijk afgekoeld. **[Lezing van de operator]** SpaceX is het duidelijkste moderne voorbeeld van een bedrijf dat een harde technologische verdedigingsgracht (herbruikbare raketten) heeft gebruikt om daar een software-economisch bedrijf (satellietinternet) bovenop te bouwen. Het lanceringsbedrijf verdient het recht om te bestaan; Starlink is waar het terugkerende, schaalbare geld zit. Dat is het hele verhaal in één zin. ## Wat is SpaceX SpaceX (Space Exploration Technologies Corp.) ontwerpt, bouwt en vliegt raketten en ruimtevaartuigen, en exploiteert het Starlink satellietinternetnetwerk. Opgericht in 2002 met het langetermijndoel de mensheid multiplanetair te maken, werd het de dominante lanceerprovider ter wereld door iets te doen wat niemand anders op grote schaal deed: de eerste trap van een orbitale raket landen en hergebruiken, wat de kosten om de ruimte te bereiken deed instorten. Dat kostenvoordeel is de motor achter alles else. Goedkope, frequente, betrouwbare lanceringen zijn wat een constellatie van meer dan 7.000 satellieten economisch mogelijk maakt — en de constellatie is wat een hobbelig, projectgebaseerd lanceringsbedrijf omzet in een bedrijf met terugkerende inkomsten. ## Hoe verdient SpaceX geld? ### 1. Lanceerservices Het oorspronkelijke bedrijf. SpaceX verkoopt lanceringen aan drie soorten klanten: - **Commerciële satellietoperators** — bedrijven die een lading in een baan om de aarde nodig hebben, betalen voor een toegewijde lancering of een plek op een **rideshare**-missie (veel kleine satellieten op één raket, geprijsd per kilogram). - **Overheid en militair** — nationale veiligheidsladingen en wetenschappelijke missies, vaak met een premie voor betrouwbaarheid en zekerheid. - **Andere ruimtevaartbedrijven** — inclusief, steeds meer, concurrenten die nog steeds op SpaceX vertrouwen omdat het de goedkoopste en meest beschikbare rit is. De unit-economie werkt dankzij **herbruikbaarheid**: dezelfde eerste-trap-booster vliegt vele malen, zodat de marginale kosten van een lancering ver onder de prijs liggen. Falcon 9 is het werkpaard; Falcon Heavy verwerkt de zwaarste ladingen. ### 2. Starlink (de machine voor terugkerende inkomsten) Starlink is een constellatie van duizenden satellieten in een lage aardbaan die snel internet levert aan plaatsen die terrestrisch breedbandinternet niet kan bereiken of niet bedient. Het is nu het deel van SpaceX dat lijkt op een echt abonnementsbedrijf, met meerdere lagen: - **Consument** — huishoudens betalen voor een schotel (hardware) plus een maandelijks abonnement. - **Zakelijk en mobiliteit** — duurdere plannen voor bedrijven, maritiem (schepen, jachten) en **luchtvaart** (inflight-wifi-deals met luchtvaartmaatschappijen). - **Overheid** — inclusief **Starshield**, de defensiegerichte variant die aan militaire en overheidsdoelgroepen wordt verkocht. - **Direct-to-cell** — partnerschappen met mobiele operators om satellietconnectiviteit rechtstreeks aan gewone telefoons in dode zones te leveren. Starlink combineert hardwareverkoop (de terminal) met maandelijks terugkerende inkomsten (het abonnement) bij miljoenen abonnees — de klassieke scheermes-en-mesjes-vorm, op planetaire schaal. Daarom schatten de meeste analyses Starlink nu in als SpaceX' grootste inkomstenlijn, boven lanceringen. ### 3. Overheidscontracten Een apart, zeer groot segment dat overlapt met lanceringen maar het waard is te scheiden: - **NASA** — SpaceX vliegt astronauten naar het Internationaal Ruimtestation in het kader van het **Commercial Crew**-programma (Crew Dragon) en bevoorraadt het met **Cargo Dragon**. Het won ook een contract om een **Starship**-gebaseerd menselijk landingssysteem te bouwen voor NASA's maanambities. - **Nationale veiligheid** — terugkerende lanceringcontracten voor defensie- en inlichtingenladingen. Deze contracten zijn hoogwaardig, meerjarig en financieren een groot deel van de ontwikkeling die het commerciële segment ten goede komt. ### 4. Starship (de motor van de toekomst, nog geen winstcentrum) Starship is SpaceX's volledig herbruikbare zwaar-liftraket — de langetermijnvervanging voor Falcon en de sleutel tot zowel maan/Mars-missies als de volgende, grotere generatie Starlink-satellieten. Vandaag is het een kostencentrum gefinancierd door de andere drie bedrijfsonderdelen. Als het routinevluchten bereikt, verlaagt het de lanceringskost opnieuw dramatisch en maakt het een veel grotere Starlink-inzet mogelijk — dat is de weddenschap die investeerders eigenlijk maken. ## Is SpaceX winstgevend? SpaceX is privé en publiceert geen gecontroleerde financiële overzichten, dus alles precies is een schatting. Het breed gerapporteerde beeld: lanceringen zijn winstgevend per missie dankzij herbruikbaarheid, en Starlink is in positief cashflowterritorium beland naarmate zijn abonneebase groeide. Het bedrijf steekt enorme bedragen terug in de ontwikkeling van Starship, dus 'winst' hangt sterk af van hoe je die R&O behandelt. De richting van ontwikkeling — groeiende terugkerende Starlink-inkomsten bovenop een dominant lanceringsbedrijf — is wat de enorme private waardering van het bedrijf ondersteunt. ## De IPO-vraag Dit is het deel dat iedereen vraagt, dus hier is de eerlijke versie. **Er wordt niet verwacht dat SpaceX snel naar de beurs gaat.** Elon Musk heeft herhaaldelijk gezegd dat hij SpaceX liever privé houdt zolang Starship en het Mars-programma kapitaalintensief en langetermijngericht zijn — de kwartaaldruk van de publieke markt past niet bij een decennialange missie. In plaats daarvan biedt SpaceX liquiditeit aan werknemers en vroege investeerders via periodieke **tender offers** (het bedrijf faciliteert aandelenverkopen tegen een vaste prijs), waarmee mensen kunnen uitcashen zonder een beursnotering. Die secundaire verkopen zijn wat de kopregel-waarderingscijfers oplevert — SpaceX is in recente rondes gewaardeerd op honderden miljarden dollars. **Een Starlink spin-off IPO wordt al lang gesuggereerd** — Musk zelf suggereerde jaren geleden dat Starlink uiteindelijk naar de beurs zou kunnen gaan zodra zijn inkomsten stabiel en voorspelbaar waren. Maar hij heeft ook herhaaldelijk de verwachtingen voor korte termijn getemperd. Per 2026 heeft Starlink geen IPO gedaan en er is geen bevestigde datum. Behandel elke kop met 'Starlink IPO-datum' met scepsis tenzij het van het bedrijf zelf komt. ## Conclusie SpaceX's model is een stapel: herbruikbaar lanceren creëert een kostengreppel, die greppel maakt Starlink economisch mogelijk, Starlink maakt het geheel een terugkerend-inkomstenbedrijf, en overheidscontracten financieren het grensverleggende werk (Starship) dat de kostencurve opnieuw reset. Het blijft privé uit keuze, waarbij tender offers worden gebruikt in plaats van een IPO — en de meest waarschijnlijke weg naar de publieke markten is een toekomstige Starlink-notering, niet SpaceX als geheel, wanneer het bedrijf beslist dat het de juiste tijd is. ## SpaceX-inkomstenmodel — FAQ 2026 ### Wat is SpaceX' grootste inkomstenbron? De meeste schattingen plaatsen **Starlink** nu boven lanceerservices als SpaceX' grootste inkomstenlijn, aangedreven door miljoenen consument-, zakelijke, mobiliteits- en overheidsabonnementen plus terminalhardwareverkoop. Lanceerservices blijven groot en zeer winstgevend per missie, maar het terugkerende model van Starlink schaalt sneller. ### Is SpaceX beursgenoteerd? Kan ik SpaceX-aandelen kopen? Nee. SpaceX is een privaat bedrijf en zijn aandelen zijn niet beschikbaar op publieke aandelenbeurzen. De meeste mensen kunnen niet direct instappen; toegang is over het algemeen beperkt tot werknemers en erkende investeerders die deelnemen aan private rondes of tender offers. Wees op uw hoede voor aanbiedingen van 'SpaceX-aandelen' die anders suggereren. ### Gaan SpaceX of Starlink naar de beurs? Er wordt niet verwacht dat SpaceX op korte termijn naar de beurs gaat — Musk heeft gezegd het privé te willen houden tijdens de kapitaalintensieve Starship/Mars-fase. Een **Starlink**-IPO wordt al jaren besproken als een mogelijkheid zodra zijn inkomsten voorspelbaar zijn, maar per 2026 is er geen bevestigde datum. Elke specifieke 'IPO-datum'-claim moet sceptisch worden behandeld tenzij die van het bedrijf komt. ### Hoe verdient Starlink geld? Starlink rekent klanten een satellietschotel (hardware) plus een maandelijks abonnement, over consument-, zakelijk, maritiem, luchtvaart- en overheidsniveaus — inclusief de defensiegerichte Starshield en direct-to-cell-operatorpartnerschappen. Het is een scheermes-en-mesjes-model: hardware vooraf, daarna terugkerende inkomsten. ### Hoe helpt herbruikbaarheid SpaceX' winst? Dezelfde raketbooster meerdere keren landen en opnieuw laten vliegen verlaagt de marginale kosten van elke lancering ver onder de in rekening gebrachte prijs. Dat kostenvoordeel is wat SpaceX de goedkoopste lanceerprovider maakt en wat het economisch haalbaar maakt om een Starlink-constellatie van meerdere duizenden satellieten in te zetten. **Gerelateerde lectuur:** [Hoe verdient Uber geld](https://alejandrorioja.com/how-does-uber-make-money/) · [Hoe verdient Shopify geld](https://alejandrorioja.com/how-shopify-makes-money/) · [Hoe verdient PayPal geld](https://alejandrorioja.com/how-does-paypal-make-money/) --- ## De kortere versie SpaceX verkoopt goedkoop ritten naar een baan om de aarde omdat het zijn raketten hergebruikt, en gebruikt dat kostenvoordeel vervolgens om Starlink te exploiteren — een satellietinternet-abonnementsbedrijf dat nu zijn grootste verdiener is — terwijl overheidscontracten de volgende generatie Starship financieren. Het blijft opzettelijk privé; een Starlink-beursgang, geen SpaceX-beursgang, is de meest waarschijnlijke uiteindelijke weg naar de publieke markten. --- ## Claude geplande taken gebruiken: terugkerend werk automatiseren met cron Source: https://alejandrorioja.com/nl/how-to-use-claude-scheduled-tasks/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: Geplande taken veranderen een eenmalige Claude-prompt in een terugkerende klus: hij gaat af op een cron-achtig schema, doet het werk en levert het resultaat. Gebruik de Claude-app voor persoonlijke terugkerende prompts (een ochtenddigest, een wekelijkse samenvatting) en Claude Code-routines of Managed Agents-deployments voor ontwikkelaarsautomatisering in de cloud. De winst zit in het automatiseren van werk dat je anders elke dag of week met de hand zou doen. ## Table of contents _Bijgewerkt juni 2026._ **TL;DR:** Geplande taken veranderen een eenmalige Claude-prompt in een terugkerende klus: hij gaat af op een cron-achtig schema, doet het werk en levert het resultaat. Gebruik de **Claude-app** voor persoonlijke terugkerende prompts (een ochtenddigest, een wekelijkse samenvatting) en **Claude Code-routines** of **Managed Agents-deployments** voor ontwikkelaarsautomatisering in de cloud. De winst zit in het automatiseren van werk dat je anders elke dag of elke week met de hand zou herdoen. **[Lees voor operators]** De meest impactvolle automatiseringen zijn niet spectaculair — het zijn de kleine terugkerende klussen die je dagelijks stilletjes 20 minuten kosten. Een geplande taak is de manier om die één keer aan Claude over te dragen en er nooit meer over na te denken. Ik draai er meerdere: een ochtendlijke concurrentieverkenning, een nachtelijke PR-statuscheck, een wekelijks content-pipeline-concept. Geen ervan kostte meer dan tien minuten om in te stellen. ## Wat een geplande taak is Een normale Claude-sessie is synchroon: je typt, het reageert, je bent erbij. Een **geplande taak** is asynchroon en terugkerend: je definieert een prompt (of een heel agent-workflow) plus een schema, en Claude voert het zelfstandig uit — om 7 uur elke werkdag, elke maandag, elk uur — en geeft je het resultaat als het klaar is. Onder de motorkap is het een cron-job met een LLM in het middelpunt. Je schrijft geen code om APIs aan elkaar te plakken; je beschrijft het resultaat in gewone taal en laat de agent elke keer de stappen uitzoeken als hij afgaat. ## De drie plaatsen waar je ze instelt Er is niet één knop — er zijn drie oppervlakken, afgestemd op wie je bent. ### 1. De Claude-app (voor iedereen) De Claude-apps voor consumenten ondersteunen terugkerende taken: je slaat een prompt en een cadans op, Claude voert het uit op schema en geeft je een melding met het resultaat. Dit is het pad zonder code — ideaal voor een dagelijkse briefing, een terugkerende onderzoeksopvraag, een taak "vat mijn ongelezen nieuwsbrieven elke ochtend samen". Als je geen ontwikkelaar bent, begin je hier. ### 2. Claude Code-routines (voor mensen die in de terminal leven) Als je **Claude Code** gebruikt, kun je een prompt of een slash-opdracht plannen om op een cron-cadans te draaien als een cloud-agent — een "routine". Het draait server-side op je repo of workspace, dus het werkt ook als je laptop dicht is. Typische toepassingen: openstaande pull requests in de gaten houden, een nachtelijke lint-en-fix-pass uitvoeren, elke ochtend een conceptpost genereren voor review. Jij definieert het schema en de taak; Claude Code regelt het afgaan en het uitvoeringslogboek. ### 3. Managed Agents-deployments (voor ontwikkelaars die producten bouwen) Voor teams die bouwen op de Claude API voeren **geplande deployments** een agent uit op een terugkerend cron-schema — elke activering start een sessie die het werk autonoom doet (een nachtelijke compliance-scan, een wekelijks rapport, een uurlijkse monitor). Je krijgt een uitvoeringslogboek per activering om successen en fouten te controleren. Dit is de programmatische, productie-waardige versie van hetzelfde idee. ## Hoe je over het schema nadenkt Alle drie gebruiken hetzelfde mentale model — **welke taak, hoe vaak, wat doen met de uitvoer**: 1. **De taak** — schrijf hem zoals je een goede agent-prompt zou schrijven: rol, context, exacte actie, beperkingen en een check. Een geplande taak kan halverwege de uitvoering geen verduidelijkende vraag stellen, dus moet hij *van tevoren volledig gespecificeerd* zijn. Dit is het grootste verschil met interactief gebruik. 2. **De cadans** — dagelijks, wekelijks, uurlijks, alleen werkdagen, een specifiek tijdstip in jouw tijdzone. Stem het af op hoe snel de onderliggende zaak daadwerkelijk verandert; een "dagelijkse" digest van een wekelijks bijgewerkte bron zijn verspilde runs. 3. **De levering** — waar het resultaat terechtkomt (een melding, een bestand, een bericht, een concept). Besluit dit van tevoren zodat de uitvoer nuttig is zodra hij binnenkomt. ## Patronen die echt lonen - **De ochtenddigest.** "Elke werkdag om 7 uur, haal het laatste over [onderwerpen] op, vat de drie belangrijkste punten samen en stuur me een 5-punten brief." Vervangt 20 minuten handmatig scannen. - **Het wekelijkse rapport.** "Elke maandag, stel [statistieken] samen tot een samenvatting van één pagina met wat er veranderd is en waarom." Verandert een terugkerende karwei in een review. - **De nachtwerker.** Een coderoutine die een lang, goed gespecificeerd werk uitvoert terwijl je slaapt — een refactor, een testdoorloop, een data-opruiming — zodat je wakker wordt met een te beoordelen resultaat. - **De monitor.** "Elk uur, controleer [ding]; stuur me alleen een bericht als [conditie] waar is." De beste automatiseringen zijn grotendeels stil en spreken alleen als het er toe doet. ## Insteladviezen uit productiegebruik - **Over-specificeer de prompt.** Halverwege de uitvoering zijn geen verduidelijkende vragen mogelijk. Geef het formaat, de bronnen, de beperkingen en wat te doen in randgevallen op. - **Begin met een handmatige test.** Voer de exacte prompt één keer met de hand uit. Als hij interactief oplevert wat je wilt, plan hem dan in. Zo niet, corrigeer eerst de prompt — een slechte prompt inplannen levert alleen betrouwbaar slechte resultaten op. - **Stem de cadans af op de veranderingssnelheid.** Voer niets uurlijks uit tegen iets dat wekelijks bijgewerkt wordt. - **Houd uitvoer als concepten wanneer de inzet hoog is.** Voor alles wat de wereld in gaat — een gepubliceerd bericht, een verzonden e-mail — laat de taak een *concept* produceren voor jouw review, geen live actie. Reserveer het volledig autonome "doe het gewoon" voor laagrisico, omkeerbaar werk. - **Houd de eerste runs in de gaten.** Geplande taken driften — een bron verandert van formaat, een feed wordt stil. Controleer de vroege uitvoeringslogboeken, vertrouw hem dan. ## Claude Geplande Taken — FAQ 2026 ### Wat zijn geplande Claude-taken? Het zijn terugkerende klussen: je definieert een prompt of agent-workflow plus een cron-achtig schema, en Claude voert het automatisch uit — dagelijks, wekelijks, uurlijks — en levert het resultaat zonder dat je achter het toetsenbord hoeft te zitten. Ze bestaan in de Claude-apps voor consumenten (voor persoonlijke terugkerende prompts), in Claude Code (als cloud-routines) en in de Claude API (als Managed Agents-deployments). ### Moet ik ontwikkelaar zijn om ze te gebruiken? Nee. De Claude-app ondersteunt terugkerende taken zonder code — gewoon een opgeslagen prompt en een cadans. Claude Code-routines en Managed Agents-deployments zijn de ontwikkelaar-gerichte versies voor het automatiseren van code- en productworkflows. ### Hoe verschilt een geplande taak van een normale Claude-chat? Een normale chat is interactief — je bent erbij om vervolgvragen te beantwoorden. Een geplande taak is autonoom en terugkerend, dus de prompt moet van tevoren volledig gespecificeerd zijn; Claude kan halverwege de uitvoering niet pauzeren om een vraag te stellen. Hij gaat af op schema, voltooit het werk en geeft je het resultaat. ### Wat is een goede eerste geplande taak? Een ochtenddigest. "Elke werkdag om 7 uur, vat het laatste over [jouw onderwerpen] samen in vijf punten." Het is laagrisico, makkelijk te verifiëren en vervangt direct een terugkerende handmatige karwei — de perfecte sjabloon om de workflow te leren voordat je iets groters automatiseert. ### Kan een geplande taak echte acties uitvoeren, zoals e-mails versturen? Ja, maar wees bewust. Voor omkeerbaar, laagrisico werk, laat het handelen. Voor alles wat naar buiten gericht is of moeilijk ongedaan te maken, laat de taak een concept produceren dat jij goedkeurt in plaats van automatisch te handelen — zeker bij onbewaakt uitvoering. Omkeerbaarheid is de juiste toets voor hoeveel autonomie je verleent. **Gerelateerde lectuur:** [De beginnersgids voor AI-agenten](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [Hoe verdient Anthropic geld](https://alejandrorioja.com/how-does-anthropic-make-money/) · [Hoe geciteerd worden in ChatGPT-antwoorden](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- **Wil je een systeem van geplande agenten dat je terugkerende werk afhandelt?** Dat is precies wat ik bouw — [neem contact op](https://alejandrorioja.com/contact/). --- ## De Kostenrekensom van AI-agents: Wanneer Haiku Sonnet Verslaat (en Wanneer Niet) Source: https://alejandrorioja.com/nl/ai-agent-cost-math-when-haiku-beats-sonnet/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Voor Claude Haiku kiezen in plaats van Sonnet kan de kosten per aanroep drastisch verlagen, maar alleen wanneer de taak een lager slaagpercentage verdraagt. De echte maatstaf zijn niet de kosten per aanroep — het zijn de kosten per geslaagd resultaat, inclusief herpogingen en menselijke nabewerking. Ik route per taak, niet per standaardinstelling. ## Inhoudsopgave _Bijgewerkt juni 2026._ **TL;DR:** Voor Claude Haiku kiezen in plaats van Sonnet kan de kosten per aanroep met een orde van grootte verlagen, maar alleen wanneer de taak Haiku's lagere slaagpercentage verdraagt. De maatstaf die telt zijn de **kosten per geslaagd resultaat** — aanroepkosten plus herpogingen plus menselijke nabewerking — niet de catalogusprijs per token. Ik route per taak, en een aanzienlijk deel van mijn stappen met hoog volume draait op Haiku terwijl de oordeelskwesties op Sonnet blijven. **Blik van de operator:** Ik draai meer dan 100 agents, en inferentie is een echte kostenpost. Maar ik heb teams "geld zien besparen" door alles op het goedkoopste model te forceren en vervolgens de kosten te betalen in herpogingen, escalaties en boze klanten. De kostenrekensom werkt alleen als je de hele funnel meet. Het goedkoopste model is niet het model met de laagste prijs per token. Het is het model met de laagste totale kosten om het werk goed te doen. Dat zijn verschillende getallen, en de kloof daartussen is precies waar de meeste kostenbeslissingen rond agents misgaan. ## De tokeneconomie, recht voor zijn raap Anthropic rekent voor Claude per miljoen tokens, waarbij invoer en uitvoer apart worden gefactureerd, en uitvoer kost meerdere keren zoveel als invoer. De exacte cijfers verschuiven in de tijd, dus check de actuele prijzen van Anthropic — maar het is de **structuur** die de beslissing stuurt: - **Haiku** is de goedkope, snelle laag — veruit de laagste kosten per token in de familie. - **Sonnet** zit ertussenin — merkbaar duurder dan Haiku, merkbaar goedkoper dan Opus. - **Opus** is de premiumlaag voor het moeilijkste redeneerwerk. Twee dingen volgen daaruit. Ten eerste domineren uitvoertokens de kosten bij generatieve taken, dus een breedsprakig model kost meer, zelfs bij dezelfde prijs per token. Ten tweede is de kloof in prijs per token tussen Haiku en Sonnet groot genoeg om bij een stap met hoog volume absoluut op de rekening op te duiken. Dat is het argument *vóór* Haiku. Nu het argument ertegen. ## De maatstaf die er echt toe doet: kosten per geslaagd resultaat Kosten per aanroep is een ijdelheidscijfer. Dit is de formule die ik echt gebruik: ``` kosten_per_succes = (aanroepkosten × pogingen) + nabewerkingskosten ÷ slaagpercentage ``` Waarbij `pogingen` rekening houdt met herpogingen, en `nabewerkingskosten` de verwachte kosten zijn van een mens die de doorgeglipte fouten herstelt. Kijk wat dit met de vergelijking doet. Stel dat Haiku per aanroep ongeveer een tiende kost van Sonnet. Als Haiku op een taak 80% van de tijd slaagt en Sonnet 98%, lijkt de besparing per aanroep enorm. Maar als elke Haiku-fout één herpoging triggert en 1 op de 10 nog steeds een mens nodig heeft die echt geld kost, kan de nabewerkingsterm de tokenbesparing verzwelgen. Bij een taak met lage inzet en hoog volume slaat de rekensom overweldigend uit naar Haiku. Bij een taak waar een fout een e-mail naar de verkeerde klant stuurt, kan ze volledig omslaan. Je kunt deze afweging niet maken zonder het slaagpercentage per model te meten — wat precies is wat een [eval-harnas](/the-eval-harness-i-use-to-ship-ai-agents/) je geeft. Draai dezelfde evalset tegen beide modellen en lees de slaagpercentages af op dezelfde meetlat. ## Waar Haiku doorslaggevend wint Haiku is de juiste keuze wanneer de taak **smal, gestructureerd en verifieerbaar** is: - **Classificatie en routering** — "is dit inkomende bericht een boeking, een klacht of spam?" Drie bakjes, makkelijk te verifiëren, draait voortdurend. De hele dag Haiku. - **Extractie met een schema** — een datum, een naam, een bedrag uit tekst halen, gevalideerd met Zod. Als de uitvoer parseert, is ze vrijwel zeker juist. - **Korte herschrijvingen en opmaak** — toonbijstellingen, een bekend-goede invoer samenvatten, data normaliseren. - **Filtering in eerste instantie** — Haiku triageert, en alleen de dubbelzinnige gevallen worden naar Sonnet geëscaleerd. Dit is het patroon met de hoogste hefboomwerking. De rode draad: de kosten van een Haiku-fout zijn laag en de fout is goedkoop te betrappen. Wanneer verificatie goedkoop is en de inzet laag, wint het goedkope model. ## Waar Sonnet zijn prijs waarmaakt Sonnet (en soms Opus) is het waard wanneer de taak **open, meerstaps of duur om fout te doen** is: - **Multi-tool agentlussen** waar één verkeerde tool-aanroep een cascade veroorzaakt. Hogere redeneerbetrouwbaarheid stapelt zich op over de stappen heen — de orkestratiepatronen die ik behandel in [multi-agentorkestratie](/multi-agent-orchestration-patterns-queues-state-handoffs/) leunen erop dat het model de draad niet kwijtraakt. - **Klantgerichte generatie** waar een slechte uitvoer vertrouwen kost, niet slechts een herpoging. - **Alles waar de verificatie zelf moeilijk is.** Als je niet goedkoop kunt vaststellen of de uitvoer klopt, kun je je geen model veroorloven dat vaak fout zit. Een fout hier kost geen herpoging — ze kost een terugbetaling, een afgehaakte klant, of mijn tijd. Daartegenover is de meerprijs per token een afrondingsfout. ## De routeringsregel die ik daadwerkelijk uitrol Ik kies niet één model per agent. Ik route per **taak** binnen de agent, meestal met een goedkope classifier die bepaalt welk stroomafwaarts model het werk afhandelt: ```typescript function pickModel(task: Task): string { // Goedkoop, verifieerbaar, hoog volume → Haiku if (task.type === "classify" || task.type === "extract") { return "claude-haiku"; } // Open of klantgericht → Sonnet if (task.customerFacing || task.steps > 2) { return "claude-sonnet"; } return "claude-sonnet"; // standaard de veilige keuze } ``` Twee principes zitten hierin gecodeerd. **Standaard het veilige model**, niet het goedkope — je optimaliseert de kosten *omlaag* vanaf een werkende basislijn, nooit de betrouwbaarheid *omhoog* vanaf een kapotte. En **escaleer, gok niet**: laat Haiku de makkelijke 80% afhandelen en geef de moeilijke 20% aan Sonnet. Die hybride verslaat bijna altijd het alles draaien op één van beide modellen alleen. Er is ook prompt-caching om bovenop te leggen: als je systeemprompt groot is en hergebruikt wordt, snijdt caching de invoerkosten aanzienlijk weg, ongeacht de laag, wat Sonnet soms goedkoop genoeg maakt om de Haiku-vraag overbodig te maken. ## Een uitgewerkt voorbeeld uit mijn eigen stack Neem een triagestap voor inkomende berichten met hoog volume. Hij draait duizenden keren, de taak is een driewegsclassificatie, en een misser betekent alleen dat het item in een beoordelingswachtrij belandt — goedkoop te betrappen, lage inzet. Dat is een schoolvoorbeeld van een Haiku-taak, en hem weghalen bij Sonnet verlaagde de kosten van die stap merkbaar zonder meetbare impact op het resultaat dat ertoe deed. Neem nu de stap die het daadwerkelijke antwoord aan een klant opstelt. Lager volume, open, en een slecht concept dat de deur uitgaat kost vertrouwen. Die blijft op Sonnet. Dezelfde agent, twee modellen, gerouteerd op inzet. Ik houd de kosten per run en de slaagcijfers voor beide in de gaten, zoals ik beschrijf in [hoe ik meet of een AI-agent daadwerkelijk werkt](/how-i-measure-whether-an-ai-agent-is-actually-working/) — en ik duw een stap pas een laag omlaag nadat de eval zegt dat het goedkopere model het slaagpercentage vasthoudt. ## FAQ ### Is Claude Haiku in de praktijk altijd goedkoper dan Sonnet? Per token, ja — met ruime marge. Per geslaagd resultaat, niet altijd. Als Haiku's lagere slaagpercentage herpogingen en menselijke nabewerking triggert, kunnen de totale kosten die van Sonnet overstijgen op taken waar fouten duur te betrappen of te herstellen zijn. ### Hoe beslis ik voor een gegeven taak tussen Haiku en Sonnet? Beoordeel de taak op twee assen: hoe verifieerbaar de uitvoer is en hoe kostbaar een fout is. Goedkoop te verifiëren, laag-inzet, hoog-volume werk gaat naar Haiku; open, klantgericht of moeilijk te verifiëren werk gaat naar Sonnet. Route per taak, niet per agent. ### Wat is de enige kostenmaatstaf die ik moet bijhouden? Kosten per geslaagd resultaat — aanroepkosten maal pogingen plus verwachte nabewerkingskosten, gedeeld door het slaagpercentage. De prijs per aanroep alleen verbergt herpogingen en menselijke tijd, en daar worden goedkope modellen stiekem duur. ### Kan ik beide modellen in één agent gebruiken? Ja, en meestal zou je dat ook moeten. Het sterkste patroon is een goedkope eerste ronde (Haiku classificeert of filtert) die alleen dubbelzinnige gevallen naar Sonnet escaleert. Die hybride verslaat doorgaans het alles draaien op één enkele laag. --- ## Een AI-agent debuggen in productie (een praktijkgids) Source: https://alejandrorioja.com/nl/how-to-debug-an-ai-agent-in-production/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Een AI-agent in productie debuggen draait vooral om isoleren welke laag faalde — prompt, tool, model of orkestratie. Ik log elke stap met een trace-ID, speel de exacte invoer opnieuw af en bisecteer. In mijn agents blijkt ~70% van de 'AI-bugs' loodgieterswerk-bugs te zijn, geen modelbugs. ## Inhoudsopgave _Bijgewerkt juni 2026._ **TL;DR:** Een AI-agent in productie debuggen draait vooral om isoleren welke laag faalde — prompt, tool-aanroep, modeluitvoer of orkestratie. Ik log elke stap met een trace-ID, speel de exacte invoer opnieuw af en bisecteer van daaruit. In mijn agents blijkt ongeveer 70% van wat op een "AI-bug" lijkt loodgieterswerk te zijn: een misvormd toolresultaat, een afgekapte invoer, een stilletjes opgeslokte exceptie. **Blik van de operator:** Ik draai meer dan 100 productie-agents — boekingsflows voor Pickleland, contentpipelines, inbox-triagers. Ze breken zoals alle software breekt, plus een paar nieuwe manieren. Dit is de praktijkgids die ik graag had gehad: hoe je de falende laag vindt zonder naar een muur van tokens te staren. Wanneer een agent zich misdraagt in productie, is het instinct om het model de schuld te geven. "Claude hallucineerde." Soms waar. Meestal niet. Het model is één laag in een stapel van vijf of zes, en de bug zit veel vaker in de laag die jij schreef dan in die welke Anthropic uitbracht. Deze post is de systematische manier waarop ik hem vind. ## Maak elke run traceerbaar voordat je ook maar iets debugt Je kunt niet debuggen wat je niet kunt zien. Het meest hefboomwerkende wat je kunt doen — voordat er een specifieke bug opduikt — is een trace-ID aan elke agent-run hangen en elke stap die hij zet loggen. Een "stap" is alles wat een grens overschrijdt: de inkomende trigger, elke modelaanroep (met de volledige messages-array), elke tool-aanroep (met argumenten), elk toolresultaat en de uiteindelijke uitvoer. Log ze als gestructureerde JSON, geïndexeerd op de trace-ID. ```typescript function logStep(traceId: string, step: string, payload: unknown) { console.log(JSON.stringify({ traceId, step, // "trigger" | "model_call" | "tool_call" | "tool_result" | "output" ts: Date.now(), payload, })); } ``` Op Cloudflare Workers stuur ik deze naar een queue en in een tabel; lokaal gaan ze naar stdout. De regel is absoluut: als een stap niet gelogd is, dan is hij wat debuggen betreft niet gebeurd. Dit weerspiegelt de instrumentatie die ik beschrijf in [de agent-stack die ik gebruik](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) — de trace-ID is de ruggengraat waar al het andere aan hangt. ## Isoleer de laag: prompt, tool, model of orkestratie Zodra je een trace hebt, wordt debuggen een bisectie. Er zijn vier lagen en de bug woont meestal in precies één ervan. ### 1. De invoerlaag (de meest voorkomende boosdoener) Haal de exacte `messages`-array tevoorschijn die de gefaalde modelaanroep inging. Geen reconstructie — de letterlijke payload uit de log. Lees hem dan zoals een vreemde zou doen. De helft van mijn "het model negeerde de instructies"-bugs zijn eigenlijk: - Een toolresultaat dat terugkwam als `"[object Object]"` omdat iets verkeerd naar string werd geconverteerd. - Een invoer die midden in een zin werd afgekapt omdat hij het contextvenster opblies en een naïeve slice hem doorsneed. - Een variabele die als `undefined` werd geïnterpoleerd en stilletjes de prompt vergiftigde. Als de invoer fout is, deed het model zijn werk perfect op rommel. Repareer het loodgieterswerk. ### 2. De toollaag Als de invoer er schoon uitziet, controleer dan of een tool een fout teruggaf die de agent als succes behandelde. Een klassieker: een API geeft `200` terug met een body van `{ "error": "rate limited" }`, je tool-wrapper controleert de body niet, en de agent handelt vol vertrouwen naar een foutmelding. Log toolresultaten ruw en valideer hun vorm. ### 3. De modellaag Pas nadat ik 1 en 2 heb uitgesloten, verdenk ik het model. Zelfs dan betekent "modelbug" meestal "mijn prompt is dubbelzinnig." Neem de exacte gefaalde invoer, gooi hem in een wegwerpscript tegen hetzelfde model en dezelfde temperatuur, en kijk of het reproduceert. Als het reproduceert, is de oplossing promptwerk of een [strakkere eval](/the-eval-harness-i-use-to-ship-ai-agents/), geen paniekerige modelwissel. ### 4. De orkestratielaag Als één stap op zichzelf prima is maar de meerstapsrun faalt, zit de bug in de overdracht — verloren staat tussen stappen, een race condition, een retry die een niet-idempotente actie opnieuw uitvoerde. Dit zijn de vervelendste en ik behandel de patronen in [multi-agent-orkestratiepatronen](/multi-agent-orchestration-patterns-queues-state-handoffs/). ## Reproduceer non-determinisme in plaats van ertegen te vechten Wat agents ondebugbaar doet aanvoelen, is non-determinisme: dezelfde invoer levert verschillende uitvoer op over runs heen. Je kunt het temmen. Ten eerste, **zet vast wat je kunt.** Stel `temperature: 0` in tijdens het debuggen. Het maakt Claude niet volledig deterministisch, maar het versmalt de variantie sterk zodat je een echte bug van samplingruis kunt onderscheiden. Ten tweede, **draai hem N keer.** Als een fout 1 op de 20 runs reproduceert, loop dan de exacte invoer 50 keer en leg elke uitvoer vast. Nu heb je een steekproef, geen anekdote. Een bug die 5% van de tijd afgaat, is een echte bug — je hebt alleen volume nodig om hem te zien. ```bash for i in $(seq 1 50); do node replay.mjs --trace=abc123 >> runs.jsonl done # tel daarna de fouten grep -c '"status":"fail"' runs.jsonl ``` Ten derde, **diff de geslaagde en gefaalde runs.** Met de temperatuur vastgezet en dezelfde invoer betekent een verschil in uitvoer een verschil in invoer dat je nog niet hebt opgemerkt — een tijdstempel in de prompt, een toolresultaat dat varieert, een opgehaald document dat veranderde. ## Bouw een replay-harnas zodat je stopt met debuggen in productie Debuggen door de live agent opnieuw te triggeren is traag en riskant — hij verstuurt echte e-mails, boekt echte banen. Leg in plaats daarvan de trace vast en speel hem offline opnieuw af. Het replay-harnas laadt een gelogde trace, reconstrueert de exacte invoer voor elke willekeurige stap en draait alleen die stap opnieuw tegen het model. Omdat je de volledige `messages`-array hebt gelogd, heb je het upstream-systeem helemaal niet nodig. Dit verandert een retourtje van 10 minuten in productie in een lokale lus van 2 seconden, en het is de grootste versnelling in mijn debug-workflow. Een goed replay-harnas laat je ook **muteren en opnieuw draaien**: verander één regel van de systeemprompt, speel dezelfde 50 gefaalde traces opnieuw af en kijk hoeveel er nu slagen. Dat is de brug van debuggen naar eval — zodra je een corpus van gefaalde traces hebt, heb je het begin van een regressiesuite. ## Houd de metrieken in de gaten die breuk echt voorspellen Sommige fouten gooien nooit een exceptie. De agent draait, geeft iets plausibels terug en doet stilletjes het verkeerde. Om die te vangen houd je gedragsmetrieken in de gaten, niet alleen foutpercentages: - **Slagingspercentage van tool-aanroepen** per tool. Een daling hier gaat vaak vooraf aan een zichtbare fout. - **Geldigheid van het uitvoerschema** — welk % van de uitvoer parseert tegen de verwachte structuur. Ik valideer elke uitvoer met Zod en alarmeer wanneer de geldigheid daalt. - **Luslengte** — gemiddeld aantal stappen per run. Een plotselinge piek betekent meestal dat de agent vastzit in opnieuw proberen. - **Kosten per run** — een op hol geslagen lus verschijnt als een kostenpiek voordat hij als een klacht verschijnt. (Wanneer kosten ertoe doen, is de [Haiku-versus-Sonnet-rekensom](/ai-agent-cost-math-when-haiku-beats-sonnet) de moeite waard.) Ik volg deze net zoals ik al het andere volg — zie [hoe ik meet of een AI-agent daadwerkelijk werkt](/how-i-measure-whether-an-ai-agent-is-actually-working/). De metriek die een stille fout vangt is er tien waard die luide vangen. ## De triage-checklist van 5 minuten Wanneer een agent breekt en de klok tikt, draai ik dit in volgorde: 1. **Haal de trace-ID** van de gefaalde run. 2. **Lees de exacte invoer** voor de gefaalde stap. Is hij goed gevormd? (Lost hier ~50% van de gevallen op.) 3. **Controleer de toolresultaten** in die trace op fouten vermomd als succes. 4. **Speel de stap offline opnieuw af** op `temperature: 0`. Reproduceert hij? 5. **Als hij reproduceert,** is het een prompt-/modelprobleem — repareer en draai het trace-corpus opnieuw. **Zo niet,** dan is het non-determinisme of een staat-/orkestratiebug — loop hem 50× om hem te karakteriseren. Gedisciplineerde isolatie verslaat slimme prompting elke keer. Het model is zelden het probleem; het systeem eromheen meestal wel. ## FAQ ### Hoe debug ik een AI-agent die maar soms faalt? Leg de exacte invoer vast uit een gelogde trace en speel hem 50+ keer opnieuw af op temperatuur 0. Intermitterende fouten zijn echte bugs met lage afgaanpercentages — volume verandert de anekdote in een reproduceerbare steekproef die je kunt diffen en repareren. ### Zit de bug meestal in het model of in mijn code? In mijn productie-agents is ongeveer 70% van de schijnbare "AI-bugs" loodgieterswerk: misvormde toolresultaten, afgekapte invoer, opgeslokte excepties of verloren staat tussen stappen. Sluit de invoer- en toollagen uit voordat je het model verdenkt. ### Wat is de minimale logging die ik nodig heb om agents te debuggen? Een trace-ID op elke run, plus gestructureerde logs van de trigger, elke modelaanroep (volledige messages-array), elke tool-aanroep en het ruwe resultaat ervan, en de uiteindelijke uitvoer. Als een stap niet gelogd is, kun je hem niet debuggen. ### Hoe stop ik met debuggen tegen de live productie? Bouw een replay-harnas dat een gelogde trace laadt en elke afzonderlijke stap offline opnieuw uitvoert met de vastgelegde invoer. Het verandert een traag, riskant productieretourtje in een snelle lokale lus en wordt het zaadje van je regressiesuite. --- ## Hoe Meet Je of AI-zoeken Je Daadwerkelijk Verkeer Stuurt Source: https://alejandrorioja.com/nl/how-to-measure-ai-search-traffic/ Published: 2026-06-08 Tags: GEO, Analytics TL;DR: Het meeste AI-zoekverkeer verschijnt als een straaltje verwijzingen van chatgpt.com, perplexity.ai en claude.ai — maar het grotere effect is dark: mensen lezen het antwoord van de AI en klikken nooit. Ik meet beide, met referrers voor de klikken en de stijging in merkzoekopdrachten voor de invloed. ## Inhoudsopgave _Bijgewerkt juni 2026._ **TL;DR:** Het meeste AI-zoekverkeer komt binnen als een dun stroompje verwijzingen van `chatgpt.com`, `perplexity.ai` en `claude.ai` — makkelijk te tellen zodra je weet waar je moet kijken. Maar het grotere effect is **dark**: mensen lezen het antwoord van de AI, nemen je merk in zich op en klikken nooit. Ik volg de klikken met referrer-segmenten en de invloed met de stijging in merkzoekopdrachten, verschuivingen in direct verkeer en citatiemonitoring. Alleen klikken tellen onderschat AI-zoeken zwaar. **Blik van de operator:** Ik run een content-engine en bekijk de analytics dagelijks. De vraag "stuurt AI-zoeken verkeer?" heeft een frustrerend antwoord: ja, maar het meeste van de waarde verschijnt niet in je sessierapport. Hier is hoe ik het deel meet dat dat wel doet en het deel afleid dat dat niet doet. Iedereen wil één getal: "hoeveel verkeer stuurt ChatGPT me?". Het eerlijke antwoord is dat AI-zoeken twee zeer verschillende effecten produceert, en je hebt twee verschillende metingen nodig. Verwar ze en je raakt in paniek (de klikken lijken minuscuul) of je houdt jezelf voor de gek (je mist de echte impact). ## Effect 1: Directe verwijzingen — telbaar, en kleiner dan je zou hopen Wanneer iemand op een citatie binnen ChatGPT, Perplexity of een Claude-antwoord klikt, registreert je analytics een referrer. Dit zijn echte, toewijsbare sessies. Bouw in GA4 of welk analysetool dan ook een segment dat de AI-engines opvangt: ``` session source matches any of: chatgpt.com chat.openai.com perplexity.ai claude.ai gemini.google.com copilot.microsoft.com ``` Bewaar dat als een "AI-zoeken"-kanaal en bekijk het in de loop van de tijd. Een paar kanttekeningen die mensen verrassen: - **Referrers lekken.** Sommige AI-oppervlakken strippen of verminken de referrer, dus een deel van de echte AI-klikken belandt in plaats daarvan in "Direct". Je verwijzingstelling is een ondergrens, niet de waarheid. - **Het volume is laag ten opzichte van de antwoord-impressies.** AI-engines beantwoorden de vraag op de pagina; alleen de nieuwsgierige minderheid klikt door. Een handvol dagelijkse verwijzingen kan overeenkomen met veel meer mensen die je geciteerd zagen. Het verwijzingssegment is dus noodzakelijk maar onvoldoende. Het vertelt je dat AI-zoeken *enig* verkeer stuurt. Het ondertelt de invloed zwaar. ## Effect 2: Dark invloed — de grotere, moeilijker te zien helft De echte actie is zero-click. Iemand stelt ChatGPT een vraag, je merk verschijnt in het antwoord als aanbevolen bron, en hij klikt nooit — hij onthoudt je gewoon. Dat duikt later op als een **merkzoekopdracht** of een **direct bezoek**, aan niets toegeschreven. Het is dezelfde dynamiek die featured snippets frustrerend maakte om te meten, uitvergroot. Je kunt dark invloed niet rechtstreeks meten, maar je kunt het trianguleren: 1. **Volume merkzoekopdrachten.** Volg zoekopdrachten naar je naam/merk in Google Search Console in de loop van de tijd. Als je geciteerd begint te worden door AI-engines en je merkimpressies stijgen zonder een bijbehorende campagne, dan is die stijging een vingerafdruk van AI-invloed. 2. **Trend in direct verkeer.** Een aanhoudende stijging in "Direct"-sessies die geen enkele campagne volgt, weerspiegelt vaak AI-verwijzingen die van hun referrer zijn ontdaan, plus mensen die je intypen na een AI-vermelding. 3. **Geassisteerde conversies.** Kijk of AI-zoeksessies, zelfs wanneer zeldzaam, opduiken als het *eerste* contactpunt in converterende journeys. Een kanaal dat op last-click minuscuul is, kan op first-touch betekenisvol zijn. Geen van deze is een schoon getal. Samen vertellen ze je of de dark helft beweegt. ## Volg citaties, niet alleen klikken Hier is de metric waar ik me het meest om bekommer bij AI-zoeken, en hij staat helemaal niet in je analytics: **word ik geciteerd, en voor welke zoekopdrachten?** Houd een lijst bij van de 20-40 zoekopdrachten die ertoe doen voor je bedrijf en draai ze volgens een schema door ChatGPT, Perplexity en Claude — wekelijks is ruim voldoende. Noteer, voor elke zoekopdracht en engine: word je geciteerd, en op welke positie? Dit is het GEO-equivalent van rank tracking, en het is de voorlopende indicator. Citaties bewegen *vóór* het downstream-verkeer en de merkstijging, dus hier zie je of je [GEO-werk voor lokale bedrijven](/geo-for-local-business-getting-a-brick-and-mortar-cited-by-ai-search/) aanslaat. Ik bouwde een kleine agent die deze controles uitvoert en de resultaten logt — het soort ding dat triviaal wordt zodra je een agent-stack hebt. Als je het liever met de hand doet, werkt een spreadsheet en een wekelijkse pass van 30 minuten prima om mee te beginnen, of gebruik een speciaal daarvoor gebouwde checker zoals [mentioned.at](https://mentioned.at) als je de agent niet zelf wilt bouwen. De methodologie spiegelt mijn [ChatGPT-vs-Google-citatietest](/chatgpt-search-vs-google-50-term-test/), alleen continu uitgevoerd in plaats van eenmalig. ## Bouw het dashboard: vier getallen, wekelijks Ik verdrink niet in metrics. Voor AI-zoeken let ik op vier dingen en bekijk ze wekelijks: 1. **AI-verwijzingssessies** — de telbare klikken uit het referrer-segment. Trend, geen absolute waarde. 2. **Citatiedekking** — % van mijn gevolgde zoekopdrachten waar ik over de drie engines word geciteerd. De voorlopende indicator. 3. **Merkzoek-impressies** — uit Search Console, als proxy voor dark invloed. 4. **AI-afkomstige conversies** — al is het klein, of AI-sessies ooit een converterende journey starten. Als de citatiedekking stijgt terwijl de verwijzingssessies vlak blijven, is dat *geen* mislukking — meestal betekent het dat de dark helft groeit en het merkzoekgetal zou moeten volgen. Als de citatiedekking daalt, is dat een vroege waarschuwing om op te handelen voordat enig verkeersgetal beweegt. Dit is dezelfde "meet de voorlopende indicator"-discipline die ik op agents toepas in [hoe ik meet of een AI-agent echt werkt](/how-i-measure-whether-an-ai-agent-is-actually-working/). ## Wat te doen met de getallen Meten is alleen nuttig als het verandert wat je doet. Het draaiboek: - **Citatiedekking laag voor een zoekopdracht die je belangrijk vindt?** Dat is een content- + [schema](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/)-probleem. De pagina bestaat ofwel niet, is niet gestructureerd voor extractie, of is niet gezaghebbend genoeg om in het antwoord te worden getrokken. - **Geciteerd maar geen verwijzingsverkeer?** Verwacht en prima — AI-zoeken doet merkwerk, geen klikwerk. "Repareer" het niet door klikken na te jagen; zet in op het zijn van de geciteerde bron. - **Verwijzingen van de ene engine maar niet de andere?** Engines lopen sterk uiteen in bronnen (ik mat ~40% overlap tussen ChatGPT en Google). Door de een geciteerd worden levert je de anderen niet op — werk de dekking van elke engine apart uit. ## Een opmerking over eerlijkheid bij toeschrijving Weersta de drang om een precisie te claimen die je niet hebt. AI-zoekmeting in 2026 is triangulatie, geen toeschrijving. Wie je een schoon getal verkoopt van het type "ChatGPT bracht je X dollar op", overdrijft wat kenbaar is, want de referrers lekken en het grootste effect is zero-click door ontwerp. De juiste houding: tel wat je kunt tellen, bekijk de proxy's voor wat je niet kunt, en neem beslissingen op de trend. De trend is betrouwbaar, zelfs wanneer het absolute getal dat niet is. ## FAQ ### Hoe zie ik verkeer van ChatGPT of Perplexity in GA4? Bouw een kanaal/segment dat overeenkomt met de domeinen van de AI-engines — chatgpt.com, chat.openai.com, perplexity.ai, claude.ai, gemini.google.com, copilot.microsoft.com — als sessiebron. Dat vangt de doorklik-verwijzingen op, hoewel sommige worden gestript naar "Direct", dus behandel de telling als een ondergrens. ### Waarom is mijn AI-zoekverwijzingsverkeer zo laag? Omdat AI-zoeken grotendeels zero-click is — de engine antwoordt op de pagina en slechts een minderheid klikt door. Lage verwijzingstellingen vallen vaak samen met veel grotere citatie-impressies. Meet citaties en de stijging in merkzoekopdrachten om het deel te zien dat verwijzingen missen. ### Wat is de beste voorlopende indicator voor AI-zoeken? Citatiedekking: het percentage van je gevolgde bedrijfskritische zoekopdrachten waar je over ChatGPT, Perplexity en Claude wordt geciteerd. Hij beweegt vóór verkeer en merkstijging, dus hij vertelt je vroeg of je GEO-werk aanslaat. ### Kan ik exacte omzettoeschrijving uit AI-zoeken krijgen? Nee, niet betrouwbaar in 2026. Referrers lekken naar Direct en het grootste deel van de impact is zero-click door ontwerp. Behandel AI-zoekmeting als triangulatie — tel klikken, bekijk de proxy's voor merkzoekopdrachten en direct verkeer, en beslis op de trend, niet op een vals-precies dollarbedrag. --- ## Multi-Agent Orkestratiepatronen: Queues, State en Handoffs Source: https://alejandrorioja.com/nl/multi-agent-orchestration-patterns-queues-state-handoffs/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Betrouwbare multi-agentsystemen draaien niet om slimme prompts — ze draaien om de saaie discipline van gedistribueerde systemen: duurzame queues tussen agents, state buiten het model gehouden, en idempotente handoffs die retries overleven. Het model is de werker; de queue is de ruggengraat. ## Inhoudsopgave _Bijgewerkt juni 2026._ **TL;DR:** Betrouwbare multi-agentsystemen win je niet met slimme prompts — je wint ze met de saaie discipline van gedistribueerde systemen. Zet een duurzame **queue** tussen agents, houd de **state buiten het model** en maak elke **handoff idempotent**, zodat een retry niet dubbel kan handelen. Het model is de werker; de queue is de ruggengraat. Krijg die drie goed en orkestratie houdt op eng te zijn. **Blik van de operator:** De meeste van mijn 100+ agents zijn enkelstaps. Degene die dat niet zijn — de pipelines die classificeren, dan verrijken, dan handelen — werden pas betrouwbaar toen ik stopte met denken in "promptketen" en begon te denken in "jobqueue met LLM-werkers". Dit is architectuur, geen prompt engineering. "Multi-agent" klinkt alsof de agents met elkaar praten. In de praktijk is de betrouwbare versie het tegenovergestelde: agents communiceren helemaal niet rechtstreeks. Ze laten berichten achter op een queue en pakken werk op uit een queue, en de orkestratie zit in het leidingwerk ertussen. Hier zijn de patronen die het volhouden in productie. ## Patroon 1: Zet een duurzame queue tussen elke agent De eerste neiging is om agent B rechtstreeks aan te roepen vanuit agent A. Doe het niet. Directe aanroepen koppelen de twee: is B traag, dan blokkeert A; faalt B, dan is A's werk verloren; moet je B schalen, dan kan dat niet zonder A aan te raken. In plaats daarvan rondt A zijn werk af en **plaatst een bericht in de queue** voor B. B is een aparte werker die de queue in zijn eigen tempo leegt. ```typescript // Agent A is klaar en draagt over via de queue — geen directe aanroep naar B await env.ENRICH_QUEUE.send({ traceId, type: "enrich", payload: classifierResult, }); // A's job is gedaan. B pikt dit onafhankelijk op. ``` Op Cloudflare gebruik ik Workers Queues precies hiervoor — dezelfde primitieven achter [de agent-stack die ik gebruik](/the-agent-stack-i-use-to-run-30-production-agents-no-python/). De queue geeft je vier dingen gratis: **buffering** (B kan plat liggen zonder werk te verliezen), **retries** (mislukte berichten worden opnieuw bezorgd), **backpressure** (een piek komt in de queue in plaats van te crashen) en **ontkoppeling** (schaal of herimplementeer B zonder A aan te raken). Elk daarvan is iets dat je anders met de hand zou moeten bouwen en fout zou doen. ## Patroon 2: Houd state altijd buiten het model De meest voorkomende multi-agentbug is aannemen dat het model iets onthoudt tussen stappen. Dat doet het niet. Elke modelaanroep is stateless; het enige geheugen is wat je in de prompt zet. Dus de bron van waarheid voor "waar staat deze job in de pipeline" moet in een database leven, niet in een conversatie. Ik houd één enkel jobrecord bij dat elke agent leest en bijwerkt: ```typescript interface JobState { traceId: string; stage: "classified" | "enriched" | "acted" | "done" | "failed"; data: Record; attempts: number; updatedAt: number; } ``` Elke agent doorloopt dezelfde lus: de jobstate **lezen**, zijn werk doen, de nieuwe state **schrijven**, de volgende fase in de queue plaatsen. Het model houdt nooit de state — het ontvangt de relevante doorsnede als invoer en geeft een resultaat terug. Dit is wat het systeem herstartbaar maakt: sterft een werker midden in een job, dan zegt het staterecord nog steeds precies waar het stond, en het opnieuw bezorgde queuebericht pikt daar weer op. Het maakt debuggen ook behapbaar, want de statetabel is een opvraagbaar register van de reis van elke job — dezelfde instrumentatie-mindset uit [hoe ik meet of een agent echt werkt](/how-i-measure-whether-an-ai-agent-is-actually-working/). ## Patroon 3: Maak elke handoff idempotent Queues garanderen *minstens-één-keer* bezorging, niet precies één keer. Dat betekent dat een bericht twee keer bezorgd kan worden — netwerkhaperingen, retries, herimplementaties. Is de actie van je agent niet idempotent, dan handelt een dubbele bezorging dubbel: twee bevestigingsmails, twee boekingen, twee afschrijvingen. Dit is de naarste klasse orkestratiebug, en het is degene die teams in productie ontdekken. De oplossing is om acties idempotent te maken met een sleutel: ```typescript async function handleEnrich(msg: QueueMessage, env: Env) { const job = await getJob(env, msg.traceId); if (job.stage !== "classified") { // Al voorbij deze fase verwerkt — dit is een dubbele bezorging. Overslaan. return; } const result = await enrich(job.data); await advanceJob(env, msg.traceId, "enriched", result); await env.ACT_QUEUE.send({ traceId: msg.traceId, type: "act" }); } ``` De fasecontrole maakt de operatie veilig om twee keer uit te voeren: de tweede bezorging ziet dat de job al is gevorderd en doet niets. Voor externe neveneffecten (een mail versturen, een kaart belasten) geef je een idempotentiesleutel mee aan de downstream-API zodat *die* ook dedupliceert. Ga ervan uit dat elk bericht twee keer bezorgd wordt en ontwerp zo dat dat onschadelijk is — want vroeg of laat gebeurt het. ## Patroon 4: Orkestrator vs choreografie — kies bewust Er zijn twee manieren om de flow te bedraden, en de juiste keuze hangt af van de complexiteit. **Choreografie** (mijn standaard): elke agent kent alleen de volgende stap en plaatst die in de queue. De flow ontstaat uit de keten. Eenvoudig, gedecentraliseerd, makkelijk uit te breiden — voeg een fase toe door een queue in te voegen. Het nadeel is dat geen enkele plek de hele flow beschrijft, dus een complexe pipeline kan moeilijk te doorgronden worden. **Orkestratie** (een centrale coördinator): één orkestrator bezit de flow, roept elke agent om de beurt aan en beslist op basis van resultaten wat er volgt. De hele flow leeft op één leesbare plek en de vertakkingslogica is expliciet. De prijs is een centraal component dat zelf duurzaam moet zijn — is de eigen state van de orkestrator niet geëxternaliseerd (Patroon 2), dan wordt hij het enkele punt van falen. Mijn regel: **choreografie tot de vertakking complex wordt, dan een duurzame orkestrator.** Een lineaire pipeline van drie fasen is choreografie. Een flow met conditionele routering, parallelle fan-out en joins wil een orkestrator wiens state in de database leeft, zodat hij na een crash kan hervatten. ## Patroon 5: Fan-out, fan-in zonder stukken te verliezen Wanneer één job N parallelle subtaken voortbrengt (50 records verrijken, 20 documenten samenvatten) en je op ze allemaal moet wachten voordat je doorgaat, heb je een **join** nodig. De truc is een teller in de jobstate: 1. De parent plaatst N child-berichten in de queue en schrijft `expected: N, completed: 0` naar het jobrecord. 2. Elk child doet zijn werk en **verhoogt atomair** `completed`. 3. Het child dat `completed` opvoert tot gelijk aan `expected` plaatst de volgende fase in de queue. De atomaire ophoging is dragend — zonder haar kunnen twee gelijktijdig eindigende children allebei denken dat ze niet de laatste zijn, en vuurt de join nooit. Gebruik een teller die de datastore atomair kan ophogen, of een transactie. Dit patroon laat je het dure midden van een pipeline parallelliseren (vaak Haiku-goedkoop werk — zie de [Haiku-vs-Sonnet-kostenberekening](/ai-agent-cost-math-when-haiku-beats-sonnet)) terwijl je aan het eind een schone join behoudt. ## Wat ik zou overslaan Je hebt geen zwaargewicht agent-framework nodig om iets hiervan te doen. Queues, een statetabel en idempotentiesleutels zijn primitieven die elk platform al heeft. Ik heb teams gezien die naar uitgebreide multi-agentframeworks grepen om functies te krijgen die een queue gratis geeft, en een blackbox erfden die moeilijker te debuggen was dan het leidingwerk dat hij verving. Begin met de saaie primitieven. Grijp pas naar een framework wanneer je een specifieke pijn hebt gevoeld die het oplost. De samenvatting: agents zijn stateless werkers, queues zijn de duurzame ruggengraat, state leeft in een database, en elke handoff is veilig om twee keer uit te voeren. Dat is het hele spel. ## FAQ ### Moeten agents elkaar rechtstreeks aanroepen of via een queue gaan? Via een queue. Directe aanroepen koppelen agents — het falen of de traagheid van de een plant zich voort naar de ander, en je kunt niet onafhankelijk schalen of herimplementeren. Een duurzame queue geeft je buffering, retries, backpressure en ontkoppeling gratis. ### Waar moet multi-agentstate leven? Buiten het model, in een database, als een jobrecord dat elke agent leest en bijwerkt. Modelaanroepen zijn stateless, dus de bron van waarheid voor pipelinevoortgang moet extern zijn — dat is wat het systeem herstartbaar maakt na een crash. ### Hoe voorkom ik dat een agent twee keer handelt op dezelfde job? Maak handoffs idempotent. Controleer de fase van de job voordat je handelt en doe niets als hij al is gevorderd, en geef idempotentiesleutels mee aan externe API's. Queues bezorgen minstens één keer, dus ga ervan uit dat elk bericht twee keer kan aankomen en ontwerp zo dat duplicaten onschadelijk zijn. ### Heb ik een multi-agentframework nodig? Meestal niet. Duurzame queues, een statetabel en idempotentiesleutels dekken de meeste productiebehoeften met primitieven die je platform al biedt. Adopteer pas een framework wanneer je op een concreet probleem stuit dat het uniek oplost, niet standaard. --- ## De Eval-Harness die Ik Gebruik om AI-Agents Zonder Angst te Lanceren Source: https://alejandrorioja.com/nl/the-eval-harness-i-use-to-ship-ai-agents/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Agents zonder angst lanceren komt voort uit één ding: een eval-harness. Een vaste set beoordeelde testgevallen, automatisch gescoord (asserties plus een LLM-jurylid), uitgevoerd vóór elke prompt- of modelwijziging. Houdt de score stand, dan lanceer je. De testset wordt opgebouwd uit echte productiefouten. ## Inhoudsopgave _Bijgewerkt juni 2026._ **TL;DR:** De reden dat ik een prompt kan wijzigen of een model kan verwisselen op een live agent zonder mijn adem in te houden, is één ding: een **eval-harness**. Een vaste set beoordeelde testgevallen, automatisch gescoord — harde asserties waar ik ze kan schrijven, een LLM-jurylid waar dat niet lukt — uitgevoerd vóór elke wijziging. Houdt de score stand, dan lanceer ik. Daalt de score, dan niet. De testset is niet synthetisch; hij is opgebouwd uit echte productiefouten, dus elke bug wordt een permanente regressietest. **Operator's read:** Over meer dan 100 agents heen is het verschil tussen die ik met vertrouwen aanraak en die waar ik bang voor ben, of ze evals hebben. Geen eval-harness betekent dat elke promptaanpassing een gok is. Een eval-harness verandert "ik denk dat dit beter is" in "dit is meetbaar 4 punten beter en heeft niets gebroken". Dat is de hele ontgrendeling. Je zou geen code lanceren zonder tests. Mensen lanceren voortdurend agents zonder evals en vragen zich dan af waarom een "kleine promptaanpassing" de productie brak. Een eval-harness is de testsuite voor niet-deterministische software. Hier is de harness die ik daadwerkelijk draai. ## Begin met een testset opgebouwd uit echte fouten De harness is slechts zo goed als zijn testgevallen, en de beste testgevallen komen uit de productie, niet uit je verbeelding. Telkens als een agent in het wild faalt, leg ik de exacte invoer vast (ik log elke run met een trace-ID — zie [hoe je een agent in productie debugt](/how-to-debug-an-ai-agent-in-production)) en maak er een eval-geval van: ```typescript interface EvalCase { id: string; input: AgentInput; // de exacte productie-invoer expected?: string; // ground truth, wanneer die er is assertions: Assertion[]; // harde controles die moeten slagen rubric?: string; // voor het LLM-jurylid, wanneer de uitvoer open is } ``` Twee praktijken doen er hier toe. **Haal uit de productie**, zodat je evals testen wat daadwerkelijk breekt, niet wat je gokte dat zou kunnen breken. En **dek de hele spreiding** — het gelukkige pad, randgevallen, vijandige invoer, en de lege/misvormde invoer die stille fouten veroorzaakt. Een testset van 30 tot 50 goedgekozen gevallen vangt veel meer dan 500 luie. Ik heb liever 40 gevallen die elk een echte faalmodus vertegenwoordigen dan duizend die allemaal hetzelfde makkelijke pad testen. ## Scoor eerst met asserties, daarna met een LLM-jurylid Niet elke uitvoer heeft een model nodig om te beoordelen. Ik grijp naar de goedkoopste scorer die werkt. **Harde asserties** voor alles wat gestructureerd is. Parseert de uitvoer als geldige JSON? Bevat het het vereiste veld? Valt de geëxtraheerde datum binnen het bereik? Heeft het de juiste tool met de juiste argumenten aangeroepen? Deze zijn deterministisch, gratis en ondubbelzinnig — schrijf er zoveel je kunt. ```typescript const assertions: Assertion[] = [ (out) => isValidJSON(out), (out) => parse(out).category in ALLOWED_CATEGORIES, (out) => parse(out).confidence >= 0 && parse(out).confidence <= 1, ]; ``` **Een LLM-jurylid** voor de open rest — toon, behulpzaamheid, "heeft dit de vraag echt beantwoord". Hier geef je een model de invoer, de uitvoer en een rubriek, en vraag je het om te scoren. Twee regels houden het jurylid eerlijk: maak de rubriek **specifiek** (een schaal van 1 tot 5 met beschreven ankers verslaat "beoordeel de kwaliteit"), en gebruik een **sterk model als jurylid** — beoordelen is een redeneertaak, dus dit is een plek waar ik met plezier voor Sonnet betaal, zelfs wanneer de agent zelf op Haiku draait volgens de [kostenwiskunde](/ai-agent-cost-math-when-haiku-beats-sonnet). Een vage rubriek of een zwak jurylid geeft je ruis die op signaal lijkt. ## Draai de harness vóór elke wijziging De harness bestaat om één vraag te beantwoorden: *heeft deze wijziging de agent beter of slechter gemaakt?* Dus ik draai hem vóór elke promptbewerking, modelverwisseling of toolwijziging. ```bash # baseline op main npm run eval -- --suite=booking-agent > baseline.json # maak de wijziging, draai dan opnieuw npm run eval -- --suite=booking-agent > candidate.json # vergelijk npm run eval:diff baseline.json candidate.json ``` De diff toont de geaggregeerde score, het slagen/falen per geval en — cruciaal — **welke specifieke gevallen geregresseerd zijn.** Een aggregaat dat omhoog kruipt terwijl drie gevallen stilletjes breken is geen verbetering; het is een afweging die ik wil zien en goedkeuren, niet eentje die er stiekem doorheen glipt. De diff per geval in de gaten houden is hoe je "één ding gerepareerd, twee andere gebroken" vermijdt — de faalmodus die mensen bang maakt voor hun eigen prompts. ## Stel een regressiepoort in en laat hem blokkeren Zodra je de harness vertrouwt, koppel hem als poort in het pad naar productie. Mijn regel is bot: **een wijziging die de score onder de baselinedrempel duwt, wordt niet gelanceerd.** Niet "ik kijk er later naar" — hij is geblokkeerd, net als een falende CI-test. ```typescript const PASS_THRESHOLD = 0.90; // 90% van de gevallen moet slagen if (candidate.passRate < PASS_THRESHOLD || candidate.passRate < baseline.passRate) { throw new Error(`Eval regression: ${candidate.passRate} < ${baseline.passRate}`); } ``` Dit is wat evals omzet van een leuke-bijkomstigheid in het ding dat je snel laat bewegen. De poort is wat "zonder angst lanceren" letterlijk waar maakt: het ergste geval voor een slechte wijziging is een rode eval-run, geen productie-incident. En omdat de testset groeit telkens als er iets breekt, wordt de poort vanzelf strenger en beschermender naarmate de tijd vordert. ## Houd rekening met non-determinisme bij het scoren Een subtiliteit waar mensen over struikelen: dezelfde invoer kan over runs heen anders scoren omdat het model anders sampelt. Als je elk geval één keer draait, zie je spookregressies — een geval dat "brak" maar in werkelijkheid slechts samplingruis is. Twee tegenmaatregelen. Draai evals op **`temperature: 0`** om de variantie te verkleinen (het zal die niet volledig wegnemen). En voor gevallen die je hebt zien flikkeren: **draai ze N keer en neem het slagingspercentage**, niet een enkel slagen/falen. Een geval dat 9 van de 10 keer slaagt is er beter aan toe dan een dat 5 van de 10 keer slaagt, ook al kunnen beide een groene enkele run tonen. Dit is hetzelfde principe van volume-boven-anekdote dat ik gebruik bij het [debuggen van intermitterende fouten](/how-to-debug-an-ai-agent-in-production) — één run is een mening, vijftig runs zijn data. ## Sluit de lus met productiemonitoring De eval-harness test tegen bekende gevallen. De productie werpt nieuwe op. Dus de lus is: monitor live gedrag, vang een nieuwe faalmodus, maak er een eval-geval van, repareer het, en nu is het permanent bewaakt. De monitoringkant — het bijhouden van slagingspercentage, uitvoervaliditeit en kosten per run op live verkeer — is wat ik behandel in [hoe ik meet of een AI-agent daadwerkelijk werkt](/how-i-measure-whether-an-ai-agent-is-actually-working/). Evals en monitoring zijn twee helften van hetzelfde systeem: monitoring vindt de bugs, evals zorgen dat ze dood blijven. Die feedbacklus is het echte product. Elke afzonderlijke eval-set veroudert; een *proces* dat elke productiefout omzet in een permanente test wordt elke week sterker. Zo gaat een agent van "eng om aan te raken" naar iets dat ik op een vrijdagmiddag zonder te knipperen herstructureer. ## Veelgestelde vragen ### Wat hoort er in een eval-set voor een AI-agent? Echte productie-invoer omgezet in beoordeelde gevallen — gelukkig pad, randgevallen, vijandige en misvormde invoer — elk met harde asserties en, voor open uitvoer, een LLM-jurylid-rubriek. 30 tot 50 gevallen uit echte fouten verslaan honderden synthetische die allemaal het makkelijke pad testen. ### Moet ik een LLM gebruiken om agent-uitvoer te beoordelen? Gebruik harde asserties overal waar de uitvoer gestructureerd is (geldige JSON, juist veld, juiste toolaanroep) — ze zijn gratis en deterministisch. Reserveer een LLM-jurylid voor open eigenschappen als toon en behulpzaamheid, met een specifieke rubriek en een sterk jurymodel, zodat je signaal krijgt, geen ruis. ### Hoe voorkom ik dat een promptwijziging de productie stilletjes breekt? Draai de eval-harness vóór elke wijziging en diff tegen een baseline, met aandacht voor regressies per geval, niet alleen de geaggregeerde score. Koppel deploys vervolgens aan het resultaat, zodat elke wijziging die onder de baselinedrempel zakt, geblokkeerd wordt als een falende test. ### Hoe ga ik om met non-determinisme in evals? Draai op temperatuur 0 om de variantie te verminderen, en voor gevallen die flikkeren, draai ze meerdere keren en scoor het slagingspercentage in plaats van een enkele run. Een geval dat 9 van de 10 keer slaagt is gezonder dan een dat 5 van de 10 keer slaagt, zelfs als een enkele run beide groen toont. --- ## Hoe je je Newsletter Automatiseert met een AI-Agent Source: https://alejandrorioja.com/nl/how-to-automate-your-newsletter-with-an-ai-agent/ Published: 2026-06-06 Updated: 2026-06-25 Tags: AI Agents, Growth TL;DR: Een Claude-agent leest mijn contentqueue, kiest de sterkste invalshoek van de week, stelt een newsletter op in mijn stem, segmenteert de lijst op betrokkenheidsniveau en plant de verzending via de Kit API — allemaal zonder dat ik een editor open. Ik bekijk een gerenderde preview en klik op goedkeuren. Het moeilijke creatieve werk is van mij; de mechanische uitvoering is van de agent. ## Inhoudsopgave _Bijgewerkt juni 2026._ **TL;DR:** Een Claude-agent leest mijn contentqueue, kiest de sterkste invalshoek van de week, stelt een newsletter op in mijn stem, segmenteert de lijst op betrokkenheidsniveau en plant de verzending via de Kit API — allemaal zonder dat ik een editor open. Ik bekijk een gerenderde preview en klik op goedkeuren. Het moeilijke creatieve werk is van mij; de mechanische uitvoering is van de agent. **[Lezersnotitie van de operator]** Een newsletter die consistent verstuurt wint het van een die "beter" is maar verschijnt wanneer de inspiratie toeslaat. De beperking was de uitvoeringsoverhead, niet de ideeën. Ik had ideeën; ik had niet de bandbreedte om ze elke week te formatteren, plannen en segmenteren. De agent heeft dat gat gedicht. ## De echte bottleneck in de meeste newsletter-workflows De meeste newsletter-automatiseringsadviezen richten zich op het verkeerde: welkomstsequenties, automatiseringen, tagging-logica. Dat is prima, maar het lost het wekelijkse creatieprobleem niet op. De echte rem is dit: je weet wat je wilt zeggen, maar gaan zitten om het te formatteren, de onderwerpregelvarianten te schrijven, het juiste segment te kiezen en het op het juiste moment te plannen kost 2-3 uur contextwisseling per week. Vermenigvuldig met 52 weken en je hebt een volledige werkweek besteed aan alleen maar *versturen* van newsletters. De agent verwerkt elke stap na "ik weet wat de invalshoek van deze week is." ## De stack die ik gebruik - **[Kit](/recommends/convertkit)** (voorheen ConvertKit) — het emailplatform. Uitstekende API, solide abonnee-tagging, schone analytics. De agent-vriendelijke API was wat mij overtuigde. - **Claude (Anthropic SDK)** — de generatielaag - **Cloudflare Workers** — geplande trigger (draait elke dinsdag om 8 uur CT) - **Airtable** — contentqueue en goedkeuringspostvak Als je niet op Kit bent, werkt hetzelfde patroon met elk platform dat een REST API heeft voor het aanmaken en plannen van uitzendingen. ## Stap 1: De contentqueue De agent heeft een bron van waarheid nodig voor "waarover schrijven we." Die van mij is een [Airtable](/recommends/airtable)-tabel met kolommen: - `Topic` — de invalshoek of de vraag - `Status` — Queue / Approved / Sent - `Tier` — of dit voor alle abonnees is of alleen voor betrokken abonnees - `Notes` — eventuele beperkingen (vermijd deze toon, voeg deze link toe, enz.) Elke week besteed ik 10 minuten aan het toevoegen van 2-3 onderwerpen aan de queue. Dat is mijn creatieve inbreng. De rest is het werk van de agent. ## Stap 2: De concept-agent ```typescript // workers/newsletter-agent/index.ts import Anthropic from "@anthropic-ai/sdk"; import Airtable from "airtable"; const client = new Anthropic(); const VOICE_SYSTEM = `You are writing a weekly newsletter for Alejandro Rioja's subscribers. His audience: founders and operators interested in AI agents, SEO, and growing a one-person business. Voice: direct, first-person, practitioner. No hype, no "exciting times," no excessive bullet lists. Structure every newsletter as: 1. One-sentence hook (the problem or observation) 2. The core insight (3–5 paragraphs, no headers, conversational) 3. One concrete action the reader can take this week 4. A short sign-off (2 sentences max) Subject line: specific, outcome-oriented, under 50 chars. No clickbait. Return JSON: { "subject": "...", "preheader": "...", "body": "..." }`; async function getNextTopic(): Promise<{ id: string; topic: string; notes: string; tier: string }> { const base = new Airtable({ apiKey: process.env.AIRTABLE_API_KEY }).base(process.env.AIRTABLE_BASE_ID!); const records = await base("Newsletter Queue") .select({ filterByFormula: "{Status} = 'Queue'", sort: [{ field: "Created", direction: "asc" }], maxRecords: 1 }) .firstPage(); if (!records.length) throw new Error("Queue is empty. Add topics."); const r = records[0]; return { id: r.id, topic: r.get("Topic") as string, notes: (r.get("Notes") as string) ?? "", tier: (r.get("Tier") as string) ?? "all" }; } async function draftNewsletter(topic: string, notes: string): Promise<{ subject: string; preheader: string; body: string }> { const msg = await client.messages.create({ model: "claude-sonnet-4-6", max_tokens: 2048, system: VOICE_SYSTEM, messages: [{ role: "user", content: `Write this week's newsletter on: "${topic}". Additional notes: ${notes || "none"}` }], }); const text = (msg.content[0] as any).text.replace(/```json\n?/, "").replace(/```/, "").trim(); return JSON.parse(text); } async function scheduleWithKit(draft: { subject: string; preheader: string; body: string }, tier: string): Promise { const segmentId = tier === "engaged" ? process.env.KIT_ENGAGED_SEGMENT_ID : null; const sendAt = new Date(); sendAt.setDate(sendAt.getDate() + ((4 - sendAt.getDay() + 7) % 7)); // next Thursday sendAt.setHours(9, 0, 0, 0); // 9am CT const payload: any = { broadcast: { subject: draft.subject, content: draft.body, description: draft.preheader, send_at: sendAt.toISOString(), email_layout_template: "minimal", }, }; if (segmentId) payload.broadcast.segment_id = segmentId; const res = await fetch("https://api.kit.com/v4/broadcasts", { method: "POST", headers: { "Content-Type": "application/json", "X-Kit-Api-Key": process.env.KIT_API_KEY! }, body: JSON.stringify(payload), }); const data = await res.json(); return data.broadcast?.id ?? ""; } export default { async scheduled(_event: ScheduledEvent, env: Env) { // Inject env vars Object.assign(process.env, env); const { id, topic, notes, tier } = await getNextTopic(); const draft = await draftNewsletter(topic, notes); const broadcastId = await scheduleWithKit(draft, tier); // Mark as Approved in Airtable (not Sent — human reviews the Kit preview before confirm) const base = new Airtable({ apiKey: env.AIRTABLE_API_KEY }).base(env.AIRTABLE_BASE_ID); await base("Newsletter Queue").update(id, { Status: "Approved", KitBroadcastId: broadcastId }); console.log(`Scheduled broadcast ${broadcastId} for topic: ${topic}`); }, }; ``` ## Stap 3: De goedkeuringsstap De agent maakt de uitzending aan in de conceptstatus van Kit en markeert het Airtable-record als "Approved." Kit stuurt me een melding met een previewlink. Ik klik erop, lees het, en als het er goed uitziet, bevestig ik de verzending. Als ik wijzigingen wil, bewerk ik direct in Kit. Dit is de poort die voorkomt dat de agent volledig autonoom wordt bij uitgaande e-mail. Ik vertrouw de concepten ongeveer 90% van de tijd. De 10% die ik bij de review ontdek — een toon die iets te ver afwijkt, een statistiek die ik wil verifiëren, een link die ik wil toevoegen — is de 3 minuten durende review waard. ## Wat de agent afhandelt dat ik nooit meer wil doen - Onderwerpregelvarianten schrijven en de beste kiezen - De preheadertekst opmaken - De juiste verzendtijd berekenen (mijn publiek opent donderdagochtend; de agent weet dit) - Correct segmenteren op basis van het niveau van het onderwerp - Alles loggen naar Airtable zodat ik een record heb ## Wat ik nog steeds bezit Het *idee*. Het onderwerp in de queue is van mij. De invalshoek is van mij. De agent is een uitstekende uitvoerder van een duidelijke briefing; het is geen strategielaag. Als ik een slecht onderwerp in de queue zet, krijg ik een goed geschreven newsletter over een slecht onderwerp. Ook: de eerste beoordelingspoort. Elke verzending wordt door mij bekeken voordat hij uitgaat. Dat gaat niet veranderen. ## De conclusie van de operator Als je meer dan een uur per week besteedt aan newsletter-mechanica — formattering, planning, segmentatie — moet je het automatiseren. De Kit API is schoon, de Worker-cron-trigger is ijzersolide, en de kwaliteit van het Claude-concept is hoog genoeg dat ik ~90% van de eerste concepten ongewijzigd goedkeur. Bouw de queue in Airtable, verbind de Worker en ga terug naar het creëren van ideeën in plaats van het uitvoeren van verzendingen. --- ## Hoe je Scoort in AI-zoekopdrachten zonder ook maar één Nieuw Blogbericht te Schrijven Source: https://alejandrorioja.com/nl/how-to-rank-in-ai-search-without-writing-a-single-new-blog-post/ Published: 2026-06-06 Updated: 2026-06-22 Tags: GEO, SEO TL;DR: AI-engines citeren content die vragen direct beantwoordt, duidelijk auteurschap claimt en kennis structureert op een manier die ophalen eenvoudig maakt. De meeste bestaande blogberichten kunnen worden aangepast om aan alle drie criteria te voldoen met bewerkingen, niet herschrijvingen. Het plan: een directe TL;DR toevoegen, entiteitssignalen aanscherpen, FAQ-schema toevoegen en indienen bij llms.txt. Nieuwe content is optioneel; herstructurering niet. ## Inhoudsopgave _Bijgewerkt juni 2026._ **TL;DR:** AI-engines citeren content die vragen direct beantwoordt, duidelijk auteurschap claimt en kennis structureert op een manier die ophalen eenvoudig maakt. De meeste bestaande blogberichten kunnen worden aangepast om aan alle drie criteria te voldoen met bewerkingen, niet herschrijvingen. Het plan: een directe TL;DR toevoegen, entiteitssignalen aanscherpen, FAQ-schema toevoegen en indienen bij llms.txt. Nieuwe content is optioneel; herstructurering niet. **[Operator's lezing]** Ik heb dit proces toegepast op 341 bestaande berichten voordat ik één nieuw GEO-gericht artikel schreef. Citaties in ChatGPT en Perplexity gingen omhoog. Nieuwe content versnelde de winsten — maar de audit van bestaande content was waar ik begon, en het wierp sneller vruchten af dan verwacht. ## Waarom AI-engines je bestaande content niet citeren Vraag jezelf voor je iets nieuws schrijft: waarom wordt wat ik al heb niet geciteerd? Het antwoord is bijna nooit "de content bestaat niet." Het is meestal een van deze: 1. **Geen direct antwoord bovenaan** — het bericht begraafd het antwoord in paragraaf 6 2. **Zwakke auteursignalen** — geen duidelijke auteursentiteit, geen referenties in de content 3. **Structurele ruis** — lange introducties, irrelevante secties, geen duidelijke kopjeshiërarchie 4. **Geen machineleesbare Q&A** — AI-engines houden van gestructureerde vraag-antwoordparen; de meeste blogberichten hebben die niet 5. **Niet in een AI-leesbaar index** — geen llms.txt, geen sitemaps die crawlers vinden Alle vijf zijn herstelbaar op bestaande content. Geen van hen vereist een nieuw bericht. ## Het vier-stappen retrofitting-proces ### Stap 1: Directe TL;DR in de eerste 100 woorden toevoegen AI-engines doen iets analoog aan wat jij doet als je scant — ze zoeken naar het directe antwoord voor ze dieper gaan. Als je bericht begint met een verhaal, een vraag of context-setting, leest het model misschien nooit ver genoeg om je eigenlijke antwoord te vinden. Oplossing: Voeg een **TL;DR**-blok toe in de eerste 100 woorden. Formaat: conclusie → waarom → beperking of voorbehoud. Twee tot vier zinnen. Geen opvulling. Voorbeeld voor: > *Heb je je ooit afgevraagd waarom sommige bedrijven de Google-zoekresultaten lijken te domineren? In dit bericht verkennen we de strategieën die de best scorende sites gebruiken...* Voorbeeld na: > **TL;DR:** Drie dingen bewegen de naald voor lokale SEO in 2026: volledigheid van Google Bedrijfsprofiel, consistentie van vermeldingen in directories en gestructureerd schema voor je NAP-gegevens. Tactieken zoals "elke dag posten" en "snel 100 reviews krijgen" zijn secundair ten opzichte van die drie. Het plafond is de nauwkeurigheid van je GBP — repareer dat eerst. De herschrijving is niet langer. Het is alleen naar voren geladen. ### Stap 2: Je entiteitssignalen aanscherpen AI-engines bouwen een kennisgraaf. Ze willen weten: wie schreef dit, waar gaat het over, en is de auteur geloofwaardig op dit onderwerp? Voor auteursentiteit: zorg dat je Over mij-pagina van elk bericht gelinkt is, je auteurschema `sameAs`-links naar LinkedIn en Twitter bevat, en je auteursbio op elk bericht specifieke referenties vermeldt (niet "marketingprofessional" — "leidde SEO voor drie SaaS-bedrijven van 0 naar 100K maandelijkse bezoekers"). Voor onderwerps­entiteit: gebruik de exacte termen die je publiek zoekt. Als je "GEO" (generatieve engine-optimalisatie) behandelt, zeg dan "generatieve engine-optimalisatie" ergens, niet alleen de afkorting. Modellen gebruiken co-voorkomen van termen om content te classificeren. ### Stap 3: FAQ-schema toevoegen aan elk bericht dat vragen beantwoordt FAQPage-schema is het meest invloedrijke schematype voor GEO-citatie omdat het expliciet vraag naar antwoord koppelt in een formaat dat modellen direct kunnen verwerken. Neem de 3–5 vragen die je bericht impliciet beantwoordt en maak ze expliciet: ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "How long does it take to rank in AI search?", "acceptedAnswer": { "@type": "Answer", "text": "Most sites see initial citation improvements within 4–8 weeks of restructuring existing content for direct answers and adding FAQ schema. Brand-new domains take longer — expect 3–6 months before consistent citations appear." } } ] } ``` Voeg dit toe aan de `` van je bericht of via het schemaveld van je CMS. Elke grote AI-engine crawlt en verwerkt dit. ### Stap 4: Indienen bij llms.txt en de AI-index van je platform `llms.txt` is een opkomende standaard — een platte tekstbestand op `jouwesite.com/llms.txt` dat AI-crawlers vertelt welke content van hoge kwaliteit is en hoe ze die moeten prioriteren. Het is analoog aan `robots.txt` maar voor LLMs. Een basis llms.txt: ``` # llms.txt # alejandrorioja.com — AI agents and GEO for operators ## Priority content - /blog/geo-for-local-business (definitive guide, updated monthly) - /blog/schema-markup-for-ai-engines (technical reference) - /blog/how-to-get-cited-by-chatgpt (step-by-step) ## Author Alejandro Rioja — operator, AI agent builder, GEO practitioner. LinkedIn: https://linkedin.com/in/alejandrorioja ``` Combineer dit met een schone sitemap die `lastmod`-tijdstempels bevat. AI-crawlers geven minder prioriteit aan content die er verouderd uitziet. ## Hoe je prioriteert welke berichten te retrofitting Niet elk bericht is het retrofitting waard. Concentreer je eerste ronde op: 1. **Berichten die al op pagina 1 staan voor een vraagformaat-zoekwoord** — deze zijn het dichtst bij geciteerd worden; ze hebben alleen de structuurcorrectie nodig 2. **Berichten over onderwerpen waarop je aantoonbaar geloofwaardig bent** — AI-engines wegen auteurschap zwaar; een bericht waar je referenties relevant zijn krijgt een citatieboost van entiteitssignalen 3. **Berichten die direct een vraag beantwoorden vs. berichten die informeren** — "Hoe doe je X" en "Wat is X" retrofitting beter dan lijstjes of opiniestukken Gebruik je Search Console-data: filter voor zoekopdrachten die vragen zijn (hoe, wat, waarom, beste manier om). Berichten op positie 5–15 voor die zoekopdrachten zijn je beste retrofitting-kandidaten — ze zijn relevant maar nog niet dicht genoeg bij de top om geciteerd te worden. ## De fout die de meeste mensen maken Ze schrijven een nieuw bericht geoptimaliseerd voor AI-zoekopdrachten voor ze hun bestaande archief retrofitting. Nieuwe content helpt, maar de bestaande berichten hebben leeftijd, backlinks en crawlgeschiedenis aan hun kant. Een goed gestructureerd drie jaar oud bericht zal een nieuw bericht over hetzelfde onderwerp maandenlang overtreffen. Doe de retrofitting eerst. Schrijf nieuwe content waar er echte hiaten zijn — vragen die je bestaande berichten helemaal niet beantwoorden. Dat is wanneer nieuw beter is dan oud. ## De conclusie van de operator Als je meer dan 20 bestaande blogberichten hebt, begint je GEO-werk met audit en retrofitting, niet met een contentkalender. Voeg TL;DRs toe, scherp entiteitssignalen aan, voeg FAQ-schema toe en dien in bij llms.txt. Doe dat op je top 20 berichten voor je iets nieuws schrijft. Je zult in weken, niet maanden, verbeteringen in citaties zien — en je hebt een schonere basislijn om te meten of nieuwe content de naald echt beweegt. --- ## Ik bouwde een Claude-vaardigheid die mijn Facebook-advertenties beheert — hier is de code Source: https://alejandrorioja.com/nl/i-built-a-claude-skill-that-runs-my-facebook-ads-heres-the-code/ Published: 2026-06-06 Updated: 2026-06-28 Tags: AI Agents TL;DR: Ik bouwde een Claude-vaardigheid die mijn Meta Ads-account leest via de Graph API, underperformers identificeert, advertentieteksten herschrijft in mijn merkstem en nieuwe advertentiesets aanmaakt zonder dat ik de Advertentiebeheerder hoef aan te raken. Het geheel is minder dan 300 regels TypeScript. Het rendement was onmiddellijk: ik reduceerde de wekelijkse advertentiebeheer-tijd van ~3 uur naar ongeveer 20 minuten. ## Inhoudsopgave _Bijgewerkt juni 2026._ **TL;DR:** Ik bouwde een Claude-vaardigheid die mijn Meta Ads-account leest via de Graph API, underperformers identificeert, advertentieteksten herschrijft in mijn merkstem en nieuwe advertentiesets aanmaakt zonder dat ik de Advertentiebeheerder hoef aan te raken. Het geheel is minder dan 300 regels TypeScript. Het rendement was onmiddellijk: ik reduceerde de wekelijkse advertentiebeheer-tijd van ~3 uur naar ongeveer 20 minuten. **[Operatorslectuur]** Ik beheer advertenties voor Pickleland en voor mijn consultancymerk. Twee accounts, verschillende doelgroepen, constante creatieve vermoeidheid. Ik bracht zondagmiddagen door in de Advertentiebeheerder met dingen die een model zou moeten doen. Dus automatiseerde ik het. ## Waarom ik stopte met het handmatig beheren van Facebook-advertenties Het eigenlijke werk van het beheren van Facebook-advertenties valt uiteen in drie taken: 1. **Monitoring** — controleren welke advertentiesets geld verbranden vs. verdienen 2. **Diagnose** — uitzoeken *waarom* iets onderpresteert (creatieve vermoeidheid? slechte targeting? landingspagina?) 3. **Iteratie** — nieuwe teksten schrijven, nieuwe advertentiesets aanmaken, budgetten aanpassen Taak 1 is mechanisch. Taak 3 is grotendeels mechanisch (met een stembepaling). Taak 2 vereist oordeel — en is de enige die baat heeft bij een mens in de lus. Een Claude-vaardigheid kan 1 en 3 doen. Ik controleer de resultaten van taak 2 voordat er iets wordt gepubliceerd. Dat is de architectuur waarop ik me heb vastgelegd. ## De Meta Graph API-instelling (dit is het vervelende deel) Vóór enige code: u heeft een Meta Business-account, een Systeemgebruiker en een permanent toegangstoken nodig. Het ontwikkelaarsportaal van Facebook is vijandig, maar het pad is: 1. Een **Meta App** aanmaken op developers.facebook.com (type: Business) 2. Het product **Marketing API** toevoegen 3. Onder uw Bedrijfsportfolio → Instellingen → Gebruikers → Systeemgebruikers een systeemgebruiker aanmaken en hem de rol `ADVERTISER` geven op uw advertentieaccount 4. Een token genereren met deze machtigingen: `ads_read`, `ads_management`, `business_management` Sla het token op als `META_ACCESS_TOKEN` en uw advertentieaccount-ID (formaat: `act_XXXXXXXX`) als `META_AD_ACCOUNT_ID` in uw `.env`. ## De bestandsstructuur van de vaardigheid ``` .claude/skills/fb-ads/ SKILL.md ← instructies die Claude leest index.ts ← de daadwerkelijke tool-implementatie types.ts ← gedeelde typen ``` De `SKILL.md` vertelt Claude wanneer en hoe de vaardigheid te gebruiken. De mijne zegt: ```markdown # Facebook Ads Manager Skill Use this skill when the user says "check my ads", "run ads report", "pause underperformers", or "write new ad copy". Never run this without explicit user instruction — it touches live ad spend. ## What it can do - Pull performance data for all active ad sets (last 7 or 30 days) - Flag ad sets with ROAS < 1.5 or CTR < 0.8% as underperformers - Rewrite ad copy for flagged creatives in Ale's voice - Create new ad sets with revised copy (PAUSED by default — you approve before activating) ## What it will NOT do - Change budgets on live ad sets without explicit confirmation - Activate new ad sets automatically - Delete anything ``` De beperking "nooit automatisch activeren" is niet onderhandelbaar. Deze vaardigheid maakt dingen aan in de status GEPAUZEERD. Ik controleer en activeer handmatig. Alles wat live advertentie-uitgaven aanraakt, heeft een menselijk controlepunt nodig. ## De kern TypeScript-code (Codeblokken blijven in het Engels — alleen de omringende tekst wordt vertaald.) ## Hoe ik het dagelijks gebruik De vaardigheid wordt aangeroepen vanuit Claude Code (mijn dagelijkse tool). Een typische maandagochtend-sessie: ``` > check my ads from the last 7 days ``` Claude voert `runAdsReport(7)` uit, formatteert de resultaten als een tabel, markeert underperformers en vraagt of ik herschrijvingen wil. Ik zeg ja. Het genereert nieuwe tekst, toont me beide versies naast elkaar en maakt GEPAUZEERDE advertentiesets aan met het nieuwe creatief. Ik controleer ze in de Advertentiebeheerder, activeer de ones die ik leuk vind en archiveer de verliezers. Totale tijd: 20 minuten. Nul zondagmiddagen in de Advertentiebeheerder. ## Wat dit niet vervangt De vaardigheid kan me niet vertellen of een product-markt-fit-probleem zich vermomt als een tekstprobleem. Als de ROAS overal slecht is, is dat een funnel- of aanbodprobleem, geen kopprobleem. Claude zal getrouw teksten herschrijven op een kapotte funnel — en de herschrijvingen zullen het niet redden. De diagnosestap is nog steeds van mij. Ik lees het rapport, bekijk de funnel-gegevens en besluit of we creatief itereren of iets stroomopwaarts oplossen. De agent is snel in alles *behalve* dat oordeel. ## De conclusie van de operator Als u advertenties handmatig beheert en meer dan twee keer per week de Advertentiebeheerder aanraakt, doet u operaties die een script zou moeten doen. De Graph API is goed gedocumenteerd en de Meta-machtigingsstroom, hoewel vervelend, is een eenmalige instelling. Bouw de vaardigheid in een middag. De terugverdientijd in teruggewonnen tijd is zichtbaar in week één. --- ## De 5 AI-Tools die ik Echt Gebruik om Mijn Bedrijf te Runnen (2026) Source: https://alejandrorioja.com/nl/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/ Published: 2026-06-06 Updated: 2026-06-23 Tags: AI Agents, Growth TL;DR: Vijf tools: Claude (operatorlaag + codering), Cursor (TypeScript-ontwikkeling), Airtable (data-ruggengraat voor alle agenten), Kit (nieuwsbrief + e-mailautomatisering) en Cloudflare Workers (agenthosting). Al het andere dat ik heb geprobeerd is vervangen door een van deze of volledig geschrapt. Dit is de stack die ik opnieuw zou bouwen als ik vandaag opnieuw zou beginnen. ## Inhoudsopgave _Bijgewerkt juni 2026._ **TL;DR:** Vijf tools: Claude (operatorlaag + codering), Cursor (TypeScript-ontwikkeling), [Airtable](/recommends/airtable) (data-ruggengraat voor alle agenten), [Kit](/recommends/convertkit) (nieuwsbrief + e-mailautomatisering) en Cloudflare Workers (agenthosting). Al het andere dat ik heb geprobeerd is vervangen door een van deze of volledig geschrapt. Dit is de stack die ik opnieuw zou bouwen als ik vandaag opnieuw zou beginnen. **[Operator's lezing]** Ik run twee bedrijven: een persoonlijk AI-consultingmerk (alejandrorioja.com) en Pickleland, een pickleball-faciliteit in Pflugerville, TX. Verschillende contexten, verschillende doelgroepen, verschillende operaties. Deze vijf tools runnen beide. Ik lijst ze niet op omdat ze trendy zijn; ik lijst ze op omdat ik hun vervangers heb verwijderd. ## 1. Claude — de operatorlaag Claude (via Claude Code en de Anthropic SDK) is het brein van alles wat beweegt. Ik gebruik het in drie modi: **Claude Code** is mijn dagelijkse ontwikkeltool. Ik schrijf TypeScript, bouw agenten, debug infrastructuurproblemen en beheer content — allemaal vanuit de Claude Code-interface. Het is niet alleen autocomplete; het is een medewerker die een 500-regelig bestand kan lezen, de intentie kan begrijpen en een refactoring kan voorstellen die ik niet had overwogen. **De Anthropic SDK** drijft elke agent aan die ik heb gebouwd. Mijn nieuwsbriefagent, mijn Facebook-advertentievaardigheid, mijn contentpijplijn, mijn OG-kaartgenerator — allemaal Claude op de backend. De modelkwaliteit is hoog genoeg dat ik eerste concepten ongeveer 85% van de tijd vertrouw. **Claudes stem en merk**oordeel is onderschat. Wanneer ik iets schrijf dat als ik moet klinken, heb ik ontdekt dat Claude + een gedetailleerde systeemprompt elk ander model overtreft dat ik heb getest. De truc is een specifieke, eigenzinnige systeemprompt — niet "schrijf in een casual toon" maar "schrijf als Alejandro: direct, praktijkgericht, geen hype, genummerd, eerste persoon, met eerlijke kanttekeningen." Ik betaal voor Claude Max. Het is het meest gebruikte abonnement dat ik heb, en de ROI is niet te vergelijken. ## 2. Cursor — waar het TypeScript geschreven wordt Cursor is de IDE. Ik ben ongeveer een jaar geleden overgestapt van VS Code en heb niet achteromgekeken. De tab-voltooiing is snel genoeg om oprecht te veranderen hoe ik code schrijf — ik denk op een hogere hoogte en laat Cursor de syntactische boilerplate afhandelen. De diff-weergave voor AI-suggesties is schoon. Het multi-bestand contextvenster betekent dat ik het kan vragen een functie bij te werken en het werkt ook de bellers bij. Ik gebruik Cursor niet voor architectuurbeslissingen. Ik schets die nog op papier of in Claude. Maar zodra het ontwerp duidelijk is, is Cursor het snelste pad van ontwerp naar werkend TypeScript. De grootste ontgrendeling: Cursor + Claude Code parallel. Ik gebruik Claude Code voor high-level planning en agentorkestratie; ik gebruik Cursor voor het gedetailleerde implementatiewerk. Ze conflicteren niet — ze bestrijken verschillende hoogten. ## 3. Airtable — de data-ruggengraat Elke AI-agent die ik run heeft een plek nodig om van te lezen en naar te schrijven. Die plek is [Airtable](/recommends/airtable). Dit is waarvoor ik het gebruik in beide bedrijven: - **Contentrij** — berichten en nieuwsbriefonderwerpen in uitvoering, met statustracking - **Boekingsrecords** — Pickleland-baanreserveringen gesynchroniseerd vanuit het boekingssysteem - **Affiliatelinkcatalogus** — 105+ slugs met metadata die de contentagent leest tijdens het genereren - **Agentauditlog** — wat er draaide, wanneer, wat het produceerde, eventuele fouten De API is schoon en snel. Airtable is geen database voor high-throughput workloads — maar voor agent-bijgaande tabellen, revisierijen en goedkeuringsworkflows met menselijke tussenkomst, is het precies het juiste gereedschap. De visuele interface betekent dat ik elke tabel kan inspecteren zonder een query te schrijven. Het alternatief dat ik probeerde: Notion-databases. De Notion API is langzamer en het datamodel is onhandiger voor agentlezingen. Airtable wint voor agentgerelateerde data. ## 4. Kit — nieuwsbrief en e-mailautomatisering Ik ben overgestapt naar [Kit](/recommends/convertkit) (voorheen ConvertKit) om één reden: de API is echt goed. De meeste e-mailplatforms behandelen hun API als bijzaak. Kit behandelt het als een eersteklas product. Ik kan uitzendingen maken, verzendingen plannen, segmenteren op tag en analyses lezen — allemaal programmatisch. Mijn nieuwsbriefagent doet dit allemaal zonder dat ik de composer aanraak. Kit-specifieke dingen die ik gebruik: - **Broadcasts API** — mijn agent maakt elke week programmatisch geplande uitzendingen - **Abonneelabeling** — ik label abonnees op gedrag (opende de laatste 5 verzendingen = "betrokken"; heeft 60 dagen niet geopend = "risicovol") en mijn agent richt zich dienovereenkomstig op segmenten - **Formulieren + landingspagina's** — schoon, snel ladend, zonder code. Ik manipuleer deze niet programmatisch; ze werken gewoon. Als je op Mailchimp of een legacy-platform zit: de migratie is de moeite waard. De API van Mailchimp vereist drie extra oproepen om te doen wat Kit in één doet. ## 5. Cloudflare Workers — waar de agenten leven Elke geplande agent draait op Cloudflare Workers. Het argument: wereldwijde edge-implementatie, nul cold starts op de gratis laag en een cron-triggersysteem dat echt werkt. Mijn agenten hebben geen server nodig. Ze hebben een geplande functie nodig die betrouwbaar draait, externe API-aanroepen kan doen en vrijwel niets kost op mijn schaal. Workers is het antwoord. Wat ik op Workers heb draaien: - **Contentpijplijn** — genereert EN-bericht, vertakt naar 12 vertalingen, genereert OG-kaart - **Nieuwsbriefagent** — stelt de wekelijkse verzending op en plant deze - **Facebook-advertentiemonitor** — leest prestaties, markeert achterblijvers, informeert me - **Pickleland bezettingsrapporteur** — leest boekingsgegevens, stuurt me een dagelijkse samenvatting Totale maandelijkse kosten voor dit alles: ~$5. Dat is het betaalde Workers-plan. De agenten draaien betrouwbaar op het cron-schema; ik heb in zes maanden één storing gehad (een DNS-probleem aan de kant van Meta, niet de mijne). ## Wat ik heb geschrapt en waarom **Zapier** — vervangen door Workers + de respectievelijke platform-API's direct. Zapier voegt latentie toe, kost meer op schaal en heeft een plafond dat Workers niet heeft. **ChatGPT** — Claudes contextvenster, toolgebruik en systeempromptkwaliteit zijn beter voor de operatorgebruikscase. Ik houd een ChatGPT-tabblad voor snelle webzoekopdrachten maar bouw er niet op. **Webflow** — heb mijn site verplaatst naar Astro + Cloudflare Pages. Meer controle, betere prestaties, bouwproces waar ik tegen kan scripten. **Grammarly** — Claude doet alles wat Grammarly doet en behoudt mijn stem beter. ## De conclusie van de operator De vijf tools hierboven zijn niet de nieuwste of meest besproken. Het zijn degenen die standgehouden hebben bij dagelijks productiegebruik in twee verschillende bedrijven. Voordat je een nieuwe tool aan je stack toevoegt, vraag: welke van deze vijf zou dit werk kunnen doen? Je zult verrast zijn hoe vaak het antwoord is "een van hen kan het al." --- ## Waarom je AI-Agent Blijft Falen in Productie (En Hoe je het Oplost) Source: https://alejandrorioja.com/nl/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it/ Published: 2026-06-06 Updated: 2026-06-25 Tags: AI Agents TL;DR: De meeste productieagentstoringen komen voort uit vijf oorzaken: breekbare prompts die randgevallen niet afhandelen, ontbrekende herhaalpoginglogica voor tijdelijke API-fouten, geen observeerbaarheid om te zien wat stuk gaat, ongecontroleerde lussen zonder uitstapconditie en tooldefinities die ambiguïs genoeg zijn dat het model de verkeerde kiest. Alle vijf zijn oplosbaar zonder modellen of frameworks te wijzigen. ## Inhoudsopgave _Bijgewerkt juni 2026._ **TL;DR:** De meeste productieagentstoringen komen voort uit vijf oorzaken: breekbare prompts die randgevallen niet afhandelen, ontbrekende herhaalpoginglogica voor tijdelijke API-fouten, geen observeerbaarheid om te zien wat stuk gaat, ongecontroleerde lussen zonder uitstapconditie en tooldefinities die ambiguïs genoeg zijn dat het model de verkeerde kiest. Alle vijf zijn oplosbaar zonder modellen of frameworks te wijzigen. **[Operator's lezing]** Ik run meer dan 30 agenten in productie. Ik heb al deze storingen gehad. De storingen die het meeste tijd kostten waren niet de exotische — het waren de saaie infrastructuurstoringen waarvan ik dacht dat ik ze had afgehandeld. ## Storing 1: Breekbare prompts die op randgeval-invoer kapotgaan Een prompt die werkt op je testgevallen zal falen op invoer die je niet had geanticipeerd. Dat is geen modellimitatie — het is een instructieschrijfprobleem. **Symptomen:** De agent produceert zinloze uitvoer, roept het verkeerde tool aan of levert malformateerde JSON bij invoer die enigszins verschilt van wat je hebt getest. **Oorzaak:** Je systeemprompt beschrijft alleen het gelukkige pad. Het zegt het model niet wat te doen wanneer gegevens ontbreken, malformateerd of dubbelzinnig zijn. **Oplossing:** Voeg expliciete randgeval-afhandeling toe aan je systeemprompt: ``` If the input data is missing a required field, return: { "status": "error", "reason": "missing_field", "field": "" } Do NOT attempt to infer or hallucinate missing values. If you are uncertain which tool to call, call no tool and return: { "status": "clarification_needed", "question": "..." } ``` Het model volgt expliciete instructies voor randgevallen betrouwbaar. De fout is aannemen dat het de gelukkig-pad instructies zal generaliseren om de rommelige gevallen af te handelen. ## Storing 2: Geen herhaalpoginglogica voor tijdelijke API-fouten Elke externe API die je agent aanroept zal op een gegeven moment falen. De Claude API, de Meta Graph API, je database — ze geven allemaal 5xx-fouten terug, times out, of rate-limiten. Als je agent geen herhaalpoginglogica heeft, doodt één tijdelijke fout de hele run. **Symptomen:** Agenten-runs falen willekeurig op verschillende stappen. De logs tonen een 503 of 429 zonder vervolgpoging. **Oplossing:** Wikkel elke externe aanroep in een exponentieel-backoff herhalingpoging: ```typescript async function withRetry(fn: () => Promise, retries = 3, baseDelayMs = 500): Promise { for (let attempt = 0; attempt <= retries; attempt++) { try { return await fn(); } catch (err: any) { const isTransient = err.status === 429 || err.status >= 500 || err.code === "ECONNRESET"; if (!isTransient || attempt === retries) throw err; const delay = baseDelayMs * Math.pow(2, attempt) + Math.random() * 100; await new Promise((r) => setTimeout(r, delay)); } } throw new Error("unreachable"); } // Usage const result = await withRetry(() => client.messages.create({ ... })); ``` Drie herhalingspogingen met exponentieel backoff behandelt ~99% van de tijdelijke storingen. Voeg dit toe aan elke externe aanroep en de helft van je willekeurige storingen verdwijnt. ## Storing 3: Geen observeerbaarheid — je kunt niet zien wat stuk gaat Dit is de meest voorkomende storingsmodus in productie en degene die het meeste tijd kost om te debuggen: de agent faalt stil of produceert verkeerde uitvoer, en je hebt geen idee waar in de keten het fout ging. **Symptomen:** Je weet dat er iets mis is maar kunt de stap niet identificeren. Je voegt `console.log`-instructies toe en voert handmatig opnieuw uit om te proberen te reproduceren. **Oplossing:** Gestructureerde logging bij elke stap, met een run-ID die de hele uitvoering traceert: ```typescript function createLogger(runId: string, agentName: string) { return { step: (step: string, data: object) => console.log(JSON.stringify({ runId, agent: agentName, step, ts: new Date().toISOString(), ...data })), error: (step: string, err: unknown) => console.error(JSON.stringify({ runId, agent: agentName, step, error: String(err), ts: new Date().toISOString() })), }; } const log = createLogger(crypto.randomUUID(), "newsletter-agent"); log.step("fetch_topic", { topicId: topic.id, topic: topic.name }); // ... do work ... log.step("draft_complete", { subject: draft.subject, wordCount: draft.body.split(" ").length }); ``` Als je op Cloudflare Workers bent, gaan deze logs naar Logpush of Workers Tail. Als je lokaal of op een VPS draait, stuur ze naar een logaggregator. De gestructureerde JSON betekent dat je op `runId` kunt filteren om precies te zien wat er in een enkele run is gebeurd. ## Storing 4: Ongecontroleerde lussen zonder uitstapconditie Agentische lussen — waar het model tools aanroept en itereert totdat een conditie is voldaan — kunnen voor altijd draaien als die conditie nooit wordt voldaan of het model hem verkeerd identificeert. **Symptomen:** Agent geeft honderden dollars uit aan API-kosten voor time-out. Of het voert dezelfde toolaanroep steeds opnieuw uit zonder voortgang te boeken. **Oplossing:** Heb altijd een harde iteratielimiet en een voortgangscontrole: ```typescript const MAX_ITERATIONS = 10; let iterations = 0; let lastToolCallName = ""; let sameToolCallCount = 0; while (true) { iterations++; if (iterations > MAX_ITERATIONS) { log.error("loop", { reason: "exceeded_max_iterations" }); break; } const response = await client.messages.create({ ... }); // Detect stuck loops: same tool called 3x in a row const toolCall = response.content.find(b => b.type === "tool_use"); if (toolCall?.name === lastToolCallName) { sameToolCallCount++; if (sameToolCallCount >= 3) { log.error("loop", { reason: "stuck_loop", tool: toolCall.name }); break; } } else { sameToolCallCount = 0; lastToolCallName = toolCall?.name ?? ""; } if (response.stop_reason === "end_turn") break; } ``` Dit vangt zowel de "te lang gelopen" als de "in de ronde gedraaid" storingsmodi. De limiet moet royaal genoeg zijn voor het gelukkige pad maar strak genoeg om de explosieradius te beperken. ## Storing 5: Dubbelzinnige tooldefinities die het model verkeerd oplost Als je het model twee tools geeft met overlappende beschrijvingen, zal het soms de verkeerde aanroepen. Dit is vooral gebruikelijk met tools zoals `search_database` vs `get_record` of `send_email` vs `create_draft`. **Symptomen:** Het model roept de juiste categorie tool aan maar kiest de verkeerde specifieke. Of het roept een tool in de verkeerde context aan (gebruikt een schrijftool terwijl alleen lezen gepast was). **Oplossing:** Maak tooldefinities wederzijds exclusief en voeg expliciet "wanneer NIET te gebruiken" toe: ```typescript const tools = [ { name: "get_subscriber", description: "Fetch a single subscriber record by email. Use ONLY when you have a specific email address. Do NOT use for searching or listing subscribers.", input_schema: { ... } }, { name: "search_subscribers", description: "Search subscribers by tag, segment, or status. Use when you need to find subscribers matching a criteria — NOT when you have a specific email address.", input_schema: { ... } } ]; ``` De "NIET gebruiken wanneer X"-clausule is het deel dat de meeste mensen overslaan. Het is het belangrijkste deel. Modellen zijn beter in het volgen van expliciete negatieve beperkingen dan ze te infereren uit positieve beschrijvingen. ## Nog één ding: test je agenten op slechte invoer De meeste agenten worden alleen getest op schone, gelukkig-pad invoer. Productie heeft vuile invoer: lege strings, null-velden, Unicode-randgevallen, API-antwoorden die 200 teruggeven maar met een onverwacht schema. Voeg een testsuite toe die expliciet uitoefent: - Lege of null-invoer - Invoer bij de maximale lengte die je zou verwachten - Invoer met speciale tekens of niet-ASCII-tekst - Externe API's die onverwachte antwoordvormen retourneren Als je agent op een van deze kapotgaat, los het dan op voor het live gaat. De productieomgeving zal elke aanname die je hebt gemaakt vinden. ## De conclusie van de operator De meeste agentstoringen in productie zijn infrastructuurproblemen die zich voordoen als modelproblemen. Voeg voor je van model wisselt herhalingspogingen, gestructureerde logging, luslimieten en expliciete randgeval-afhandeling toe aan je prompts. Los de dubbelzinnige tooldefinities op. Test dan op slechte invoer. Doe dat allemaal voor je het model de schuld geeft — in mijn ervaring is het model doorgaans het laatste dat veranderd moet worden. --- ## Hoe Je Je Eerste AI-Agent Bouwt in 15 Minuten Source: https://alejandrorioja.com/nl/how-to-build-your-first-ai-agent-in-15-minutes/ Published: 2026-06-02 Updated: 2026-06-26 Tags: AI Agents TL;DR: Je hebt geen framework, cursus of doctoraat nodig. Je hebt Node.js, de Anthropic SDK en 25 regels TypeScript nodig. Deze tutorial bouwt een echte, werkende agent — een gestructureerde content-samenvatter die je in dezelfde sessie naar Cloudflare kunt deployen. De enige vereiste is een gratis API-sleutel. ## Inhoudsopgave _Bijgewerkt juni 2026._ **TL;DR:** Je hebt geen framework, cursus of doctoraat nodig. Je hebt Node.js, de Anthropic SDK en 25 regels TypeScript nodig. Deze tutorial bouwt een echte, werkende agent — een gestructureerde content-samenvatter die je in dezelfde sessie naar Cloudflare kunt deployen. De enige vereiste is een gratis API-sleutel. **[Operator's blik]** Wat ik het vaakst hoor van oprichters die met AI willen automatiseren, is "ik moet eerst meer leren". Dat hoeft niet. Het agentpatroon is eenvoudig, en de snelste manier om het te begrijpen is er een te bouwen. Hier is precies het pad dat ik zou nemen als ik vandaag vanaf nul zou beginnen. ## Waarom de meeste "bouw een AI-agent"-tutorials je in de steek laten Ze gebruiken óf Python (prima voor ML-engineers, wrijving voor iedereen anders), verbergen de echte code achter een framework zoals LangChain, óf bouwen iets te abstracts om met je echte werk te verbinden. Deze tutorial doet drie dingen anders: 1. **Alleen TypeScript** — als je ooit JavaScript hebt geschreven, kun je dit volgen 2. **Geen framework** — je ziet elke regel code die het model raakt 3. **Een nuttige output** — je bouwt een gestructureerde samenvatter die je daadwerkelijk kunt gebruiken op klantmails, reviews of vergadernotities ## Wat je gaat bouwen Een **content-samenvatter-agent**: plak een willekeurig tekstblok en krijg een gestructureerde samenvatting terug in een consistent formaat. Eén HTTP-verzoek erin, één nette samenvatting eruit. Waarom dit als eerste project: het patroon — systeemprompt + gebruikersinvoer → gestructureerde uitvoer — is de basis van elke agent die ik draai. Verwissel de systeemprompt en je hebt een vraagbeantwoorder, een toonherschrijver, een classifier of een conceptgenerator. Leer dit één keer en je hebt 80% geleerd van wat productieagents daadwerkelijk doen. ## Vereisten (2 minuten) - **Node.js 18+** — controleer met `node --version`. Installeer indien nodig vanaf nodejs.org. - **Een Anthropic API-sleutel** — meld je aan bij [Claude](/recommends/claude) en haal een sleutel op uit de console. De gratis laag werkt. - Een terminal en een teksteditor. Geen Docker. Geen virtuele omgeving. Geen `pip install` van wat dan ook. ## Stap 1: Het project aanmaken (2 minuten) ```bash mkdir my-first-agent && cd my-first-agent npm init -y npm install @anthropic-ai/sdk npm install -D tsx typescript ``` Voeg een script toe aan `package.json` zodat je de agent gemakkelijk kunt uitvoeren: ```json { "scripts": { "agent": "tsx agent.ts" } } ``` ## Stap 2: De agent schrijven (5 minuten) Maak `agent.ts` aan en plak dit: ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY, }); const SYSTEM_PROMPT = `You are a precise content summarizer. When given any block of text, return a structured summary in this exact format: **One-line summary:** **Key points:** - - - **Action item (if any):** Be specific. No filler. Under 150 words total.`; async function summarize(text: string): Promise { const message = await client.messages.create({ model: "claude-haiku-4-5", max_tokens: 512, system: SYSTEM_PROMPT, messages: [{ role: "user", content: text }], }); const block = message.content[0]; if (block.type !== "text") throw new Error("Unexpected response type"); return block.text; } const sample = ` Hey team — following up on the Q2 review meeting. We agreed to push the launch to July 15th instead of June 30th due to the payment integration delay. Marketing needs the new landing page copy by June 20th or we can't start the email campaign. Budget for the launch campaign is confirmed at $8,000. Please confirm receipt. `; const result = await summarize(sample); console.log(result); ``` ## Stap 3: Uitvoeren (1 minuut) ```bash ANTHROPIC_API_KEY=sk-ant-... npm run agent ``` Verwachte uitvoer: ``` **One-line summary:** Launch pushed to July 15th due to payment delay; landing page copy needed by June 20th to unblock email campaign. **Key points:** - Launch date moved from June 30th to July 15th - Landing page copy deadline: June 20th (blocks email campaign) - Campaign budget confirmed at $8,000 **Action item (if any):** Confirm receipt and deliver landing page copy by June 20th. ``` Dat is een werkende AI-agent. Echte invoer, een aangepaste systeemprompt, gestructureerde uitvoer. Het geheel is 30 regels code. ## Stap 4: Pas hem aan voor jouw use case De systeemprompt is het enige wat deze agent van jou maakt. Hier zijn drie kant-en-klare alternatieven: **Classifier voor klantreviews:** ```text Classify this customer review as POSITIVE, NEGATIVE, or MIXED. Then extract the main complaint or praise in one sentence. Format: SENTIMENT: