Agentic AI in productie, multi-agent portfolio

Het probleem

Een persoonlijk portfolio bouwen waar de input domeinen totaal verschillen: ruwe CV-tekst, project-beschrijvingen, taxonomy-keuzes, design-tokens, Next.js code, Cloudflare deploy-configuratie. Traditioneel pak je dit op met één AI-thread waar je copy/pastet tussen rolverwachtingen, content schrijven, dan ineens componenten, dan een SEO-check.

Twee dingen breken zo:

1. Context-drift. In een lange thread vergeet de LLM eerdere beslissingen. "Welke kleuren hadden we gekozen? Wat staat er in projects.json?" Het vraagt om herhaalde context-priming en zelfs dan glipt informatie weg.

2. Rolverwarring. Dezelfde LLM in dezelfde context die zowel content-schrijver, code-reviewer, taxonomy-curator én deploy-engineer moet zijn, levert middelmatige output op alle fronten. Een specialist met scherpe scope verslaat een generalist met vage opdracht, elke keer.

De aanpak

17 gespecialiseerde agent-rollen, elk met een eigen instructie-bestand in agents/. Een orchestrator coördineert tussen ze. Vier flows zorgen voor structuur:

Flow 1, Content Ingestion. Raw input → project-highlight-extractor → taxonomy-specialist (canonical naming, duplicate detection) → content-curator (schrijft MDX) → data-modeler (genereert JSON met integriteits-checks) → language-specialist (NL tone-of-voice polish).

Flow 2, App Build. portfolio-strategist (info-architectuur) → persona-specialist (over mij) → design-specialist (tokens + componenten) → app-specialist (Next.js implementatie) → accessibility / seo / code-checker als quality gates.

Flow 3, Deploy. security-auditor (secrets, CSP, deps) → deployment-specialist (Cloudflare Pages, edge-runtime) → access-specialist (Cloudflare Access met email-allowlist).

Flow 4, Iterate. growth-strategist adviseert wat toevoegen of opschonen → relevante specialisten in mini Flow 1/2/3 cyclus.

Elke agent heeft drie dingen die hem onderscheiden van een generieke LLM-prompt:

1. Een eigen instructie-file met scherp afgebakende scope, niet "doe alles met content", maar bv. "extract titels, rollen, klanten, periodes, technieken en impact-cijfers uit een ruwe doc".
2. Gedefinieerde input- en output-contracten, JSON-schema's voor data-agents, MDX-frontmatter voor content-agents.
3. Geen toestemming om buiten zijn scope te werken, een design-specialist schrijft geen content, een content-curator scaffoldt geen routes.

Wat het opleverde

Van leeg repo naar deze live portfolio. Concrete cijfers op moment van schrijven:

• 18 projecten met gestructureerde data + MDX-content
• 14-entry loopbaan met type-classificatie en via-relaties
• 5-laags taxonomy (skills, topics, tech, klanten, domains) met klik-graaf overal
• 100% edge-rendered op Cloudflare Pages, nul runtime LLM-calls in de uitgeleverde site
• WCAG-keyboard-nav en prefers-reduced-motion respect ingebouwd vanaf dag 1

Belangrijker dan de cijfers: concrete validatie dat multi-agent systems werken voor niet-triviale eindproducten, niet alleen voor experimenten en demo's.

Wat ik specifiek deed

• Architectuur en orchestratie-flows ontworpen, welke agent waarvoor, in welke volgorde, met welke input/output contracten.
• Alle 17 agent-instructies geschreven, één voor één, met scherpe scope-afbakening.
• Quality gate op alles wat agents opleveren, geen blinde acceptatie. Elke output check ik tegen content-feiten, technische correctheid en de tone-of-voice die we afspraken.
• Design-richting en stijl bepaald, kleurpalet, typografie, motion-principes, als briefing voor de design-agent, niet als output van een agent.

Wat ik ervan heb meegenomen

Multi-agent ≠ meer agents = beter. De waarde zit in sharp role boundaries, niet in het aantal agents. Een agent met vage scope produceert vage output. Dat is dezelfde fout als een algemene "AI consultant" zonder afgebakend domein.

Een orchestrator is een verantwoordelijkheid, geen luxe. Iemand moet de domeingrenzen bewaken, anders zit je weer in single-LLM-vagueness, alleen met meer overhead.

Productie-AI is iets anders dan demo-AI. Alle agents zaten in het bouwproces. De uitgeleverde site is edge-rendered en statisch, geen runtime LLM-calls, geen tokens-per-request, geen latency-risico. Dat is bewust. Een portfolio dat zelf "AI-powered" moet zijn om informatie te tonen, is meestal een symptoom van probleem-misdiagnose.

De duurste les: weten wanneer je géén agent moet spawnen. Een specialist voor één triviale taak is overhead, context-laden, prompt-engineering, output-validatie kost meer dan de taak zelf. De zinvolle drempel: een taak met minstens twee onafhankelijke beslis-momenten, of waarbij domein-expertise output-kwaliteit meetbaar verbetert.

Gerelateerd

• Data & AI Lead bij BrainStax, waar dit denken over productie-architectuur en team-orchestratie volwassen werd
• Private GenAI-chatbot bij Gemeente Rotterdam, vergelijkbare productie-AI tegenover hype-AI dichotomie
• Skills: multi-agent-orchestratie, productie-architectuur
• Topics: agentic-ai, generative-ai