Welten-agent · technisch faseplan

Volledige documentatie van de gekozen architectuur voor de chat-agent die de kennis én de begeleidingsmethodiek van Willemijn Welten draagt. Gebouwd mét Willemijn: zij levert methodiek, bronnen, validatie en toon; jij bouwt de zeven technische lagen.

Dit document behandelt per laag drie dingen: waarom we deze keuze maken, hoe we het inzetten, en welke upgrades er later mogelijk zijn. Bedoeld als naslag én als blauwdruk om mee te nemen naar de bouwfase (bv. in Claude Code).

Leeswijzer · kernprincipes

Vier principes lopen door alle lagen heen:

De moat zit in laag 3 (methodiek) en laag 7 (bronnen). De rest is commodity — goed uitvoeren, maar nabootsbaar. Willemijns methodiek en gecureerde kennis zijn onkopieerbaar.
Kwaliteit begint bij de bron. Retrieval-kwaliteit hangt af van ingestie-kwaliteit, die afhangt van hoe schoon de bronnen binnenkomen. Garbage in, garbage out.
Begin licht, verzwaar op bewijs. Start met de lichtste keuze die werkt; upgrade pas wanneer schaal, kosten of kwaliteit erom vragen. Enige uitzondering: reranking (laag 5) voeg je vroeg toe.
Kennis onderdompel je, gedrag expliciteer je. Inhoud → kennisbank (RAG). Gedrag/methodiek → system prompt en Mastra-fasen, nooit in de chunks.

Laag 1 · Chat UI

Waarom. De gebruiker heeft een venster nodig om mee te praten, en dat venster moet antwoorden streamend tonen — token voor token — omdat een agent soms 10-30 seconden nadenkt. Zonder streaming staart de gebruiker naar een spinner en haakt af. Een chat-UI zelf bouwen betekent streaming, gespreksstate, tool-weergave en foutafhandeling zelf oplossen; dat wil je niet.

Hoe. Next.js voor de app, met de Vercel AI SDK als de laag die de chat regelt (streaming, state, tool-calling — kant-en-klaar, gebouwd voor Next.js). De SDK is een codebibliotheek en staat volledig los van hosting: je kunt hem gebruiken zonder ooit op Vercel te hosten. Supabase blijft de backend ongeacht de hosting.

De hosting-keuze staat nog open en wordt concreet gemaakt in de bouwfase:

Cloudflare Pages/Workers — vertrouwd van Beam, goedkoper op schaal. Let op: Workers heeft CPU-limieten en een niet-volledig-Node runtime, wat knelt voor zware libraries.
Vercel — gladdere AI SDK-integratie, sneller naar een werkend product, maar duurder op schaal.

In beide gevallen: de ingestie-pipeline (laag 6) draait niet op de chat-hosting maar op een aparte serveromgeving.

Upgrades / later.

Definitieve hosting-keuze op basis van gemeten kosten en gebruik.
Zorg dat de proxy (Cloudflare) streamende antwoorden niet buffert.
Chat-UI verrijken met het tonen van tool-stappen (laten zien wanneer de agent iets opzoekt).

Laag 2 · Orchestratie / agent-laag

Waarom. De agent is een begeleider, geen kennisgids. Hij leidt mensen gefaseerd door een proces (uitvragen → spiegelen → aanreiken) met state over meerdere beurten. Dat is een proces met beslissingen en vertakkingen, en dat moet ergens wonen. Zonder orchestratie-laag zou je die regie als een groeiende berg if-statements zelf onderhouden.

Hoe. Mastra (TypeScript-native, bovenop de Vercel AI SDK). Past in je bestaande TypeScript-stack — geen tweede taal zoals bij het Python-georiënteerde LangGraph. Je definieert de methodiek-fasen als stappen, met condities ertussen; Mastra houdt bij waar elk gesprek zit en bewaart de tussenstand.

Bouwvolgorde: je kunt klein starten (kale AI SDK voor een simpele kennisflow om bronnen/retrieval te valideren) en Mastra erop zetten zodra de begeleidingsfasen komen. Wat je NIET doet: twee systemen permanent naast elkaar met een router ervoor. De triage licht-vs-zwaar hoort ín Mastra (korte flow voor een simpele vraag, lange voor begeleiding), niet als losse wissel. Uiteindelijk loopt alles via Mastra.

Bonus: Mastra heeft een volledige RAG-pijplijn (chunking, embeddings, pgvector, reranking) én evals ingebouwd. Daardoor is een apart RAG-framework niet nodig.

Upgrades / later.

Mastra’s zwaardere workflow-features (durable, branching state machines) inzetten naarmate de begeleiding complexer wordt.
LangGraph zou alleen in beeld komen als je iets nodig hebt dat Mastra echt niet kan — vrijwel niet te verwachten.

Laag 3 · Methodiek-laag — MOAT

Waarom. Dit maakt de agent van Willemijn in plaats van een generieke chatbot. Er is geen tool voor — het is een ontwerp, en het is je verdedigbare waarde. Twee mensen met dezelfde stack maar een andere methodiek-laag bouwen twee totaal verschillende producten. Hier hoort je aandacht heen, niet naar dure infrastructuur.

Hoe. Drie onderdelen:

System prompt — haar houding en toon (warm, vertrouwend; de kernverschuivingen “van hoofd naar intuïtie”, “van wilskracht naar vertrouwen”, “van verhalendrager naar dromenmaker”).
Gespreksstructuur — de fasen (uitvragen → spiegelen → aanreiken) met condities ertussen die bepalen of iemand klaar is voor de volgende stap. Dit giet je in de Mastra-stappen.
Guardrails — geen medische/psychologische claims, primair uit háár materiaal putten, eerlijk zijn wanneer iets buiten de bronnen valt, en herkennen wanneer iemand professionele hulp nodig heeft (zacht doorverwijzen).

De methodiek destilleer je uit haar materiaal: een model haalt het patroon eruit (hoe ze begeleidt, niet wat ze zegt), Willemijn valideert (klopt dit met hoe ik werk?), en je legt het vast in system prompt + Mastra-fasen. Met haar aan boord is de validatie de kern van het proces, geen gok achteraf.

Cruciaal onderscheid: kennis uit haar materiaal → kennisbank (laag 5/6); methodiek (het hoe) → deze laag. Niet door elkaar halen, anders bouw je een encyclopedie in plaats van een coach.

Guardrail-tooling: begin met de moderatie-API van de LLM-provider + een of twee eigen controle-stappen in Mastra (goedkoop model dat checkt op claims/crisis-signalen). Zwaardere frameworks (NeMo Guardrails, Guardrails AI) pas bij veel regels.

Upgrades / later.

Prompt-versionering en -testen (via Langfuse of PromptLayer) zodra je veel gaat itereren op de system prompt.
Zwaardere guardrail-frameworks als het aantal regels groeit.
Verfijning van de fasen op basis van echte gesprekken en Willemijns feedback.

Laag 4 · LLM-router

Waarom. De agent doet deeltaken van heel verschillende zwaarte. Alles door het duurste model jagen is geldverspilling — het kostenverschil tussen modeltiers is 5-25x, en dat bepaalt je marge op schaal. Daarnaast maakt een router je onafhankelijk van één leverancier: wisselen wordt een instelling in plaats van een verbouwing.

Hoe. OpenRouter om te starten (één API voor Claude, GPT, Gemini). Modeltiers (Claude, prijzen per juli 2026 — checken bij de bouw):

Haiku 4.5 ($1/$5 per M tokens) — lichte tussenstappen: vraag herschrijven, ja/nee-fasecheck, classificatie.
Sonnet 4.6 ($3/$15) — het eindantwoord. START HIER: dicht bij Opus-kwaliteit, veel goedkoper, en toon/empathie is niet waar Opus zich onderscheidt.
Opus 4.8 ($5/$25) — achter de hand voor zwaar redeneren.
Fable 5 ($10/$50) — overkill.

Twee kostenhefbomen aanzetten: prompt caching op de vaste system prompt (cache-hit = 10% van de input-prijs) en de Batch API (50% korting) voor offline werk zoals methodiek-extractie en transcript-opschoning.

Let op: houd het eindantwoord-model consistent — verschillende modellen interpreteren dezelfde toon-prompt net anders.

Upgrades / later.

Eigen abstractielaag in plaats van OpenRouter bij schaal (om de tussenpartij-opslag weg te nemen).
GPT/Gemini naast Claude zetten voor echte leveranciersonafhankelijkheid per taak.
Fijnmazigere routing per taaktype naarmate je meer taken hebt.

Laag 5 · Retrieval

Waarom. Dit is het zoeksysteem van de kennisbank en bepaalt — samen met laag 6 — je antwoordkwaliteit meer dan welk duur model dan ook. Het zoekt op betekenis via embeddings, niet op exacte woorden, zodat “ik ben gespannen” de juiste passage vindt ook als dat woord er niet in staat.

Hoe.

pgvector in Supabase — één database voor alles, geen apart systeem. Blijft lang goed (tot honderdduizenden–miljoenen chunks). De rol “sla punten op, vind de dichtstbijzijnde” is nooit optioneel; pgvector is de invulling ervan.
Reranking (Cohere/Voyage) — vroeg toevoegen. Grootste kwaliteitssprong voor weinig geld: vector search haalt grof ~20 kandidaten op, de reranker sorteert fijn en houdt de beste 3-5 over.
Embedding-model — aparte keuze van het chat-model, MOET Nederlands goed aankan (testen: OpenAI, Voyage, Cohere). Dezelfde embedding voor opslag én query.

Upgrades / later.

Hybride search (betekenis + trefwoord) toevoegen zodra exacte termen (oefeningnamen, boektitels, deck-namen) gemist worden.
Gespecialiseerde vector-DB (Turbopuffer, Pinecone, Qdrant) inruilen voor pgvector bij grote schaal.
Query-herschrijving vóór de retrieval om vage vragen scherper te maken.

Laag 6 · Ingestie-pipeline + verrijking — gezamenlijk met Willemijn

Waarom. Deze laag zet ruwe bronnen om in doorzoekbare chunks en legt daarmee de bovengrens van alle kwaliteit erboven vast. Slecht parsen of dom chunken vergiftigt alles — de beste reranker kan alleen kiezen uit wat deze laag oplevert.

Hoe. Drie stappen: parsen (tekst netjes eruit), chunken (opknippen in zinvolle stukken), embedden (naar punten). Draait als achtergrond-job op een aparte serveromgeving, niet tijdens een gesprek.

Krachtigste hefboom: content zo schoon mogelijk aanleveren. Markdown/platte tekst » gestructureerd document » digitale PDF » scan (OCR). Bij schone Markdown vervalt de zware externe parser grotendeels — parsen + chunken wordt eigen code die op de Markdown-koppen splitst. Vraag Willemijn om de schoonste versie (originele manuscripten).

Verrijking — sterke hefboom, mits gesorteerd:

(A) Vindbaarheids-verrijking hoort IN de chunk — samenvatting, thema-labels, context (“hoort bij dag 12”), trefwoorden, gegenereerde vragen. Automatiseerbaar met een goedkoop model (Haiku) in offline batch.
(B) Gedragsinstructies horen NIET in chunks — die horen in de methodiek-laag. Gedrag moet altijd gelden.

Bewezen technieken om te bestuderen (zoektermen): Contextual Retrieval (Anthropic — eerst bestuderen), parent-child / Small2Big hiërarchisch chunken (productiestandaard), semantic chunking, metadata-verrijking, synthetische vragen (Reverse HyDE / QuIM-RAG).

Framework: geen apart nodig — Mastra dekt de RAG. LlamaIndex.TS bestaat maar loopt achter op Python; alleen optioneel erbij voor retrieval als Mastra iets mist. Geavanceerde verrijking bouw je als eigen ingestie-logica bovenop Mastra.

Nuance: chunk-optimalisatie is niet de grootste knop — bronkwaliteit is. Overlap is niet altijd nuttig. Evals nodig om te meten wat bij Nederlands materiaal werkt.

Upgrades / later.

Contextual Retrieval en parent-child chunken toevoegen zodra de basis-retrieval staat.
Synthetische vragen genereren per chunk voor betere match op gebruikersvragen.
Menselijke controle-/verrijkingsstap voor de kern-content (de methodiek-dragende stukken).
Evals inzetten om verrijkingstechnieken te vergelijken op háár materiaal.

Laag 7 · Databronnen — MOAT

Waarom. De ruwe kennis, en samen met de methodiek de reden dat het product verdedigbaar is. Geen tool maar drie vragen: curatie (welke kennis vormt de coherente kern — meer is niet beter), kwaliteit (in hoe schone staat lever je aan), rechten (met Willemijn geregeld; wel schriftelijk vastleggen).

Hoe — de vier brontypes. Elk vraagt andere voorbewerking in laag 6, maar komt daarna via dezelfde route de kennisbank in (schone tekst → chunken + verrijken → embedden → pgvector):

Bron	Voorbewerking	Rol	Aandachtspunt
Boeken	Manuscript opvragen → schone Markdown	Rijkste bron; kern van kennis én methodiek	Minste voorbewerking als je het manuscript krijgt; vermijd het reverse-engineeren van gedrukte PDF’s
Kaartendecks	Alleen samenvatting + context / productomschrijving	Licht; sfeer en thematiek	Losse kaarten zijn korte teksten die weinig kennis dragen — niet elk kaartje apart opnemen loont
Cursussen (incl. video)	Tekst = schoon aanleveren; video-transcripten zelf aangeleverd	Draagt de methodiek sterk (een cursus ís een gestructureerd proces)	Transcriptie-stap vervalt; de procesopbouw is waardevol voor laag 3
Podcasts	Transcript zelf aangeleverd → opschonen → structureren	Aanvullende kennis, losse gesprekken	Nog wel opschonen (spreektaal) en structureren; automatiseerbaar met goedkoop model in batch

Omdat de transcripten van video’s en podcasts zelf worden aangeleverd, vervalt de transcriptie-dienst als apart systeem. Alle vier de types komen na voorbewerking via dezelfde route de kennisbank in: schone tekst → chunken + verrijken → embedden → pgvector.

Upgrades / later.

Nieuwe bronnen toevoegen naarmate Willemijn materiaal maakt (nieuwe boeken, cursussen, afleveringen).
Versiebeheer op bronnen: haar denken evolueert, dus markeer welke content actueel is en welke verouderd.
Metadata per bron (jaar, type, thema) voor gerichter zoeken en filteren.

Opslag & datastromen · hoe alles samenkomt

Twee vormen, allemaal in Supabase. Elke bron leeft in twee vormen tegelijk:

Origineel als bestand (Supabase Storage) — het manuscript, het aangeleverde transcript, de opgeschoonde Markdown. Bewaard als grondstof om later opnieuw te kunnen verwerken als je chunk-strategie verbetert. Wordt bij een gesprek niet gebruikt.
Verwerkte chunks (Postgres + pgvector) — de doorzoekbare kennisbank. Per chunk: de tekst, het embedding-punt, de verrijking (samenvatting, thema-labels, context) en metadata (welk boek, type, jaar).
App-data (gewone Postgres-tabellen, dezelfde database) — gebruikers, gespreksgeschiedenis, en een bronregister (welke bronnen verwerkt, wanneer, welke versie).

Supabase vervult dus drie rollen tegelijk. Geen apart kennisbank-systeem, geen tweede database, geen synchronisatie — dat is de eenvoud die de pgvector-keuze oplevert.

Aparte systemen? Nauwelijks. Buiten Supabase is er alleen een ingestie-werker: een aparte serveromgeving voor de zware verwerkings-jobs (parsen, chunken, verrijken, embedden), die niet op de chat-hosting draait maar wel naar diezelfde Supabase schrijft. De transcriptie-stap vervalt omdat de video- en podcast-transcripten zelf worden aangeleverd.

Twee datastromen:

Vooraf (achtergrond): bron → schone tekst → chunken + verrijken → embedden → pgvector. Dit vult de kennisbank en gebeurt los van gesprekken.
Live (gesprek): vraag → Mastra bepaalt de fase → zoek in pgvector (ophalen + reranken) → LLM antwoordt in haar toon.

Bij een gesprek raadpleegt de agent uitsluitend de chunks in pgvector, nooit de originele bestanden. Wat op gespreksmoment beschikbaar is, is precies wat er tijdens de ingestie in de chunks is gestopt — daarom is laag 6 zo bepalend.

Van vraag naar antwoord · de reis van één vraag

Wat er gebeurt tussen “gebruiker typt” en “antwoord verschijnt”. Voorbeeldvraag: “ik zit al weken vast met mijn droom en weet niet waarom” — een begeleidingsvraag, dus de volle route (tien stappen). Een simpele kennisvraag neemt een kortere weg (zie onderaan).

Triage — kennis of begeleiding? Mastra bepaalt met een goedkoop model (Haiku) welk type vraag dit is en welke route hij neemt. Onze voorbeeldvraag = begeleiding.
Guardrail in — veilig? Een goedkoop model checkt op crisis- of nood-signalen. Bij een signaal buigt de agent af naar zacht doorverwijzen in plaats van manifestatie-advies, en stopt hier.
Vraag herschrijven voor de zoektocht. De ruwe vraag wordt herschreven naar betere zoektermen (“vastzitten, blokkade, droom niet realiseren”). Haiku. Vergroot de kans dat de retrieval de juiste passages vindt.
Zoek in pgvector op betekenis. De herschreven vraag wordt een embedding-punt; de kennisbank levert de ~20 meest kansrijke chunks uit haar boeken en cursussen.
Reranken — de beste eruit. De reranker (Cohere/Voyage) houdt van die ~20 de echt relevante 3-5 over. Grootste kwaliteitssprong voor het minste geld.
Methodiek-fase bepalen. Mastra kijkt waar de gebruiker in het gesprek zit. Eerste beurt → haar methodiek zegt: nog uitvragen, niet aanreiken. Hier komt de moat in actie.
Eindantwoord genereren. Het sterke model (Sonnet) krijgt de system prompt (haar toon) + de opgehaalde passages + de fase-instructie. Prompt caching op de system prompt. De enige dure stap, en terecht — dit leest de gebruiker.
Guardrail uit — mag dit weg? Een goedkoop model checkt: geen medische claim, blijft het binnen haar bronnen? Laatste vangnet.
Antwoord streamt terug. Token voor token. En let op wat het is: geen advies maar een wedervraag — “waar in je lijf voel je dat vastzitten?” Haar methodiek in actie.
State bewaren voor de volgende beurt. Mastra onthoudt in Supabase dat deze gebruiker nu “uitgevraagd” is. Het volgende antwoord bouwt hierop voort. Dit onderscheidt een begeleider van een antwoordmachine.

Twee dingen verankeren het geheel:

Modelverdeling in werking: het goedkope model (Haiku) doet vier van de tien stappen (1, 2, 3, 8); het dure model (Sonnet) doet er precies één, de stap die telt (7). Dat is de router uit laag 4 die je marge gezond houdt.
Licht vs zwaar routeren: bij een kennisvraag slaat de flow stap 6 over en is stap 7 korter (gewoon antwoorden uit de bron). Mastra doorloopt dus niet altijd alle tien stappen — het routeert licht of zwaar op basis van de vraag, binnen één systeem.

Optimaliseren · waar het loont, en welke fases je kunt toevoegen

Kan elke fase geoptimaliseerd worden? Ja, maar de hefboom verschilt sterk — en dat bepaalt waar je aandacht heen moet:

Grootste hefboom: stap 4, 5, 7 (retrieval, reranking, eindantwoord). Hier zit je kwaliteit; betere embeddings/chunking, een betere reranker, of een scherpere system prompt voelt de gebruiker direct. Hier loont sleutelen het meest.
Middelmatige hefboom: stap 3, 6 (herschrijven, fase-bepalen). Verbetert kwaliteit indirect en subtiel.
Kleinste hefboom: stap 1, 2, 8, 10 (triage, guardrails, state). Infrastructuur die betrouwbaar moet zijn, niet briljant. Houd deze simpel; tijd erin steken is vaak verspild.

De evals-laag vertelt je waar optimaliseren loont — zonder meten sleutel je aan de verkeerde fase.

Is dit de perfecte volgorde? Grotendeels ja, want de kern-volgorde is bijna dwingend: guardrail-in vóór het dure werk, herschrijven vóór zoeken, reranken ná zoeken, genereren ná retrieval, guardrail-uit ná genereren. Twee dingen zijn wél een echte ontwerpkeuze om te testen: de plek van fase-bepalen (6) — je zou kunnen betogen dat de fase de retrieval zou moeten sturen en dus vóór stap 4 zou moeten. En sommige stappen kunnen parallel (triage en guardrail-in hoeven niet op elkaar te wachten) — dat is efficiëntere uitvoering van dezelfde volgorde.

Welke fases kun je toevoegen? Een menu aan bewezen extra stappen — in te voegen op bewijs uit de evals, niet allemaal tegelijk en niet vooraf, want elke stap kost latency en complexiteit:

A · Semantische cache (vóór alles) — is deze vraag al eens gesteld? Geef het bewaarde antwoord. Grootste kostenhefboom, maakt ook sneller.
B · Hybride search (bij stap 4) — betekenis + exacte trefwoorden, zodat oefeningnamen/boektitels/deck-namen precies gevonden worden. Toevoegen zodra exacte termen gemist worden.
C · Meerstaps-retrieval (bij stap 4-5) — complexe vraag opdelen en meerdere keren zoeken, voor vragen die meerdere concepten raken.
D · Zelfcontrole / faithfulness (na stap 7) — het model checkt zijn antwoord tegen de opgehaalde passages. Vangt hallucinaties; waardevol waar trouw aan haar werk essentieel is.
E · Context-compressie (vóór stap 7) — de opgehaalde passages inkorten tot het essentiële. Minder tokens = goedkoper eindantwoord. Kostenoptimalisatie bij volume.
F · Gespreks-context meenemen (bij stap 3) — de vraag aanvullen met de gesprekshistorie zodat “en dan?” begrepen wordt. Voor een begeleider over meerdere beurten is dit eerder een vroege must dan een luxe.

De rode draad: niet zoveel mogelijk stappen, maar de juiste stappen op bewijs. Een agent met twintig fases is niet beter dan een met tien — hij is trager en brozer. De evals-laag stuurt het hele optimaliseren: meet waar het misgaat, verander één ding, meet opnieuw.

Dwarslaag · Evals & observability

Waarom. Scheidt hobby van business. Meet of antwoorden goed blijven, trackt kosten, vangt regressies — de AI-tegenhanger van je Playwright-tests. Onmisbaar om te bepalen welke verrijkingstechnieken bij Willemijns materiaal werken.

Hoe. Mastra heeft evals ingebouwd (model-graded, rule-based, statistisch — relevantie, faithfulness, toon-consistentie). Alternatieven: Langfuse, Braintrust.

Upgrades / later. Uitgebreidere eval-sets opbouwen met echte gebruikersvragen; toon-consistentie tegen Willemijns stem meten; kosten per gesprek monitoren.

Fundament

pnpm monorepo, TypeScript overal, Supabase, Vitest + Playwright — volledig hergebruikt uit Beam. Waarschijnlijke structuur: aparte packages voor chat/UI, API, ingestie en gedeelde types.

Rolverdeling met Willemijn

Willemijn levert: methodiek (hoe zij begeleidt), bronnen (boeken, decks, cursussen, podcasts), validatie (klopt de gedestilleerde methodiek?), toon (haar stem als ijkpunt).
Jij bouwt: de zeven technische lagen.
Gezamenlijk: ingestie en verrijking (laag 6) en de methodiek-extractie (laag 3, als dialoog).

Effect: rechten worden een fundament in plaats van een risico, de methodiek wordt authentiek in plaats van gegist, de moat wordt echt in plaats van imitatie.

Chassis · nog te doen (het bedrijf om de motor)

Naast de zeven technische lagen, voor een verkoopbaar product:

Auth & multi-tenancy — Supabase Auth als basis; tenant-isolatie is een vroege ontwerpkeuze.
Betaling & abonnementen — Stripe, usage-based billing (koppel verbruik aan wat de klant betaalt).
Kosten- & rate-limiting — caps, quota, semantische caching. Stille bedrijfskiller bij AI zonder limieten.
Veiligheid & compliance — AVG/GDPR, verwerkersovereenkomsten. Extra relevant met echte gebruikers en persoonsdata.
Deployment & infra — CI/CD, schaling van de ingestie-jobs.
Product-analytics — PostHog: komen gebruikers terug, waar haken ze af.

Eerstvolgende praktische stappen

Bronnen inventariseren met Willemijn — in welke vorm bestaat elk van de vier types (vooral: manuscripten van de boeken), en wie kan de schoonste versie aanleveren.
Afspraken schriftelijk vastleggen — materiaal, rechten, opbrengstverdeling, boekrechten (bij haar of uitgever).
Methodiek beginnen te destilleren — eerste extractie uit haar materiaal, samen valideren.
Fundament opzetten — monorepo vanuit de Beam-conventie, Supabase + pgvector klaarzetten. (Geschikt moment om naar Claude Code over te stappen.)
Kale kennisflow bouwen — retrieval en bronkwaliteit valideren vóór de Mastra-begeleidingsfasen.

Open beslissingen voor de bouwfase: hosting (CF vs Vercel), exacte modelkeuzes in de router, welk embedding-model het beste Nederlands doet, welke verrijkingstechnieken bij haar materiaal werken. Deze maak je concreet zodra je echt materiaal in handen hebt en evals kunt draaien.