# 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 --- ## 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](/blog/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](/blog/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. 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-06 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-06 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-06 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-06 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-06 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-02 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: