Hoe ik daadwerkelijk AI-agents bouw die werk gedaan krijgen

Zes maanden geleden zag ik een engineer een AI-agent demonstreren die vergaderingen boekte, voorstellen opstelde en een CRM bijwerkte — allemaal vanuit één enkele prompt. De hele reeks duurde ongeveer negentig seconden. Het publiek klapte. Iemand vroeg "is dit echt?" De presentator glimlachte en zei ja.

Ik ging naar huis en probeerde hetzelfde te bouwen. Het kostte me drie weken om iets te maken dat half zo functioneel was. De agent hallucineerde tool calls. Hij vergat context tussen stappen. Hij riep de verkeerde API-endpoints aan met de verkeerde parameters. Op een gegeven moment stuurde hij een test-e-mail naar een echte klant met als onderwerp "TODO: fix this later."

Die ervaring leerde me iets waar ik steeds op terugkom: de kloof tussen een AI-agent demo en een AI-agent die werkt in productie is enorm. En bijna niemand praat over wat die kloof vult.

Onlangs keek ik naar Remy Gasill's uiteenzetting over het beheersen van AI-agents — een oprecht grondige doorloop die de volledige stack behandelt, van mentale modellen tot praktische architectuur. Het kristalliseerde veel patronen die ik intuïtief gebruikte tot frameworks die ik nu helder kan uitleggen. Wat volgt is mijn kijk op die concepten, gefilterd door maanden van het bouwen van agents met Claude Code voor echte projecten, echte klanten en echte fouten.

Wat mij het meest verbaasde? Het moeilijkste deel van het bouwen van bruikbare AI-agents is niet de AI. Het is alles rondom de AI.

Chatmodellen zijn geen agents (en de verwarring kost je weken)

Dit moet ik eerst ophelderen, want het misverstand is zo wijdverspreid dat het het standaard mentale model is geworden — en het klopt niet.

Wanneer de meeste mensen zeggen "ik gebruik AI-agents," bedoelen ze dat ze ChatGPT of Claude openen en vragen typen. Dat is een chatmodel. Een heel goed chatmodel. Maar het is fundamenteel een one-shot interactie: jij vraagt, het antwoordt, jij vraagt opnieuw, het antwoordt opnieuw. Elke uitwisseling is relatief geïsoleerd. Het model gaat niet namens jou dingen doen. Het reageert.

Een agent is architecturaal anders. Een agent ontvangt een doel, breekt het op in stappen, voert die stappen uit met tools, evalueert de resultaten en beslist wat er vervolgens moet gebeuren — allemaal zonder dat jij nog een prompt typt. De mens bepaalt de bestemming. De agent rijdt.

Denk er zo over na. Als je een chatmodel vraagt om "een nieuw Express.js-project op te zetten met TypeScript, ESLint en Prettier geconfigureerd," krijg je een prachtig antwoord dat elke stap uitlegt. Misschien zelfs code blocks die je kunt kopiëren en plakken. Maar jij moet nog steeds de bestanden aanmaken. Jij moet nog steeds de commando's uitvoeren. Jij moet nog steeds de configuratieconflicten tussen ESLint en Prettier debuggen die het model vergat te vermelden.

Een agent die draait in Claude Code? Die maakt de directory aan. Initialiseert het project. Installeert dependencies. Schrijft de configuratiebestanden. Draait de linter om te verifiëren dat alles werkt. Fixt de twee configuratieconflicten die het vindt. Commit het resultaat. Klaar.

Dat verschil — tussen jou vertellen wat je moet doen en het daadwerkelijk doen — is de hele paradigmaverschuiving. En het verandert hoe je nadenkt over elke taak die je aan AI delegeert.

Ik bracht mijn eerste maand met Claude Code door en behandelde het nog steeds als een chatmodel. Vragen stellen. Antwoorden lezen. De suggesties handmatig uitvoeren. Het moment dat ik het doelen begon te geven in plaats van vragen, veranderde mijn productiviteit op een manier die ik kan meten: taken die me 45 minuten kostten, waren in minder dan 10 klaar. Niet omdat de AI slimmer werd. Omdat ik stopte de bottleneck te zijn tussen zijn denken en zijn doen.

Maar hier is het punt — een agent werkt alleen als de onderliggende architectuur solide is. En die architectuur heeft een naam.

De Agent Loop: Observe, Think, Act

Elke functionele AI-agent draait op dezelfde kernlus. Remy Gasill noemt het "observe, think, act," en die framing is de helderste die ik heb gezien. Zodra je deze lus begrijpt, begrijp je waarom agents slagen of falen — en nog belangrijker, hoe je ze kunt debuggen wanneer ze kapotgaan.

Observe. De agent neemt context op. Dit omvat de oorspronkelijke taak, alle bestanden die het heeft gelezen, tool-outputs van eerdere stappen, foutmeldingen, omgevingsstatus. Alles wat de agent op dit moment weet, leeft in zijn context window. De kwaliteit van deze observatiefase bepaalt alles stroomafwaarts.

Think. Het LLM redeneert over wat het heeft waargenomen. Wat is er tot nu toe bereikt? Wat resteert? Wat is de volgende logische stap? Moet het een tool aanroepen, om verduidelijking vragen, of een eindresultaat leveren? Dit is waar de intelligentie van het model er echt toe doet — en het is waar goedkopere modellen beginnen te worstelen met complexe taken.

Act. De agent voert een tool call uit. Een bestand lezen. Een terminalcommando uitvoeren. Een API-verzoek doen. Code bewerken. Welke actie de redeneerstap ook heeft geselecteerd, de agent voert het uit. Het resultaat van die actie voedt terug in de observatiefase, en de lus gaat verder.

Deze cyclus herhaalt zich — soms drie keer, soms dertig — totdat de agent bepaalt dat de taak voltooid is.

Dit is wat het me een tijdje kostte om te internaliseren: de lus is waar de kwaliteit van de agent zit. Niet in het model. Niet in de tools. In de lus. Een middelmatig model met uitstekende context engineering en goed ontworpen tools presteert beter dan een briljant model met slordig context en slecht gedefinieerde tools. Ik heb dit getest. Ik heb dezelfde taak door Claude Opus 4.6 met waardeloze contextbestanden gehaald versus Claude Sonnet met zorgvuldig samengestelde context. Sonnet won. Consequent.

Daarom zijn de volgende drie concepten — harnesses, context engineering en skills — zo belangrijk. Het zijn allemaal mechanismen om de lus beter te laten werken.

Agent Harnesses: de cockpit waarin je AI zit

De agent loop draait niet in een vacuüm. Het heeft een omgeving nodig — een harness — die de lusuitvoering beheert, tools beschikbaar stelt, rechten afhandelt en de interface presenteert waarmee jij communiceert. Zie het als de cockpit. Het LLM is de piloot. Het harness is elk instrument, stuurvlak en veiligheidssysteem rondom die piloot.

Ik heb uitgebreid met vier harnesses gewerkt, en elk heeft zijn eigen karakter.

Claude Code is mijn dagelijkse werkpaard. Terminal-native, diepe filesystem- en git-integratie, gedetailleerde rechten. Wanneer ik een agent nodig heb die kan redeneren over een hele codebase en wijzigingen met vertrouwen kan doorvoeren, komt er op dit moment niets in de buurt.

Codex van OpenAI start een gesandboxte cloudomgeving op voor elke taak — je lokale bestanden blijven onaangeraakt tenzij je resultaten expliciet terugsynchroniseert. Uitstekend voor teams die zich zorgen maken over de blast radius. De afweging is latentie door het opstarten van de omgeving.

OpenClaw is de open-source optie die het volgen waard is. Terminal-gebaseerd, uitbreidbaar, community-gedreven. Ruwere randjes dan Claude Code, maar maximale controle over agentgedrag.

Co-work agents (zoals Anthropic's webgebaseerde Claude-agent) behandelen langlopende taken. Stuur een verzoek, sluit de browser, kom terug voor de resultaten. Onderzoeksynthese, analyse van grote documenten, meerstaps-workflows die geen real-time interactie vereisen.

Kies het harness dat past bij hoe je werkt. Ik heb twee weken verspild door te proberen een webgebaseerde agent te gebruiken voor snelle code-iteratie voordat ik overstapte naar Claude Code — en mijn frustratie verdween van de ene op de andere dag. Er is geen universeel beste keuze, alleen de juiste match voor jouw workflow.

Maar ongeacht welk harness je kiest, er is één protocol dat snel de standaard wordt voor het verbinden van agents met externe tools. En als je het nog niet gebruikt, bouw je met één hand op je rug gebonden.

MCP: de USB-C-poort voor AI-agents

Model Context Protocol — MCP — is een van die dingen die saai klinkt totdat je begrijpt wat het daadwerkelijk mogelijk maakt. Dan wordt het het meest opwindende onderdeel van de agent-stack.

Dit is het probleem dat MCP oplost. Stel dat je wilt dat je agent met je database communiceert. Zonder MCP zou je custom code schrijven: een functie die verbinding maakt met PostgreSQL, een query uitvoert, de resultaten formatteert en teruggeeft aan de agent. Dan wil je Slack-integratie. Meer custom code. Dan Google Calendar. Meer custom code. Dan je interne API. Meer custom code. Elke integratie is maatwerk, fragiel en wordt alleen door jou onderhouden.

MCP standaardiseert dit. Het creëert een universeel protocol — zie het als een USB-C-poort — waar elke tool op kan worden aangesloten. Iemand bouwt één keer een MCP-server voor PostgreSQL, en elk agent-harness dat MCP ondersteunt kan het gebruiken. Een ander bouwt er een voor Slack. Nog een ander voor Notion. Weer een ander voor je CRM. Het maakt de agent niet uit hoe de tool intern werkt. Hij roept het gewoon aan via MCP en krijgt gestructureerde resultaten terug.

Ik draai momenteel MCP-servers voor GitHub, filesystem-toegang en een custom interne API die ik voor een klantproject heb gebouwd. Het toevoegen van een nieuwe mogelijkheid aan mijn agent betekende vroeger het schrijven van integratiecode. Nu betekent het het toevoegen van drie regels aan een configuratiebestand dat verwijst naar een MCP-server.

De praktische setup ziet er zo uit in Claude Code:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "your-token-here"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "postgresql://user:pass@localhost:5432/mydb"
      }
    }
  }
}

Zet dat in je .claude/-configuratie, en plotseling kan je agent GitHub-repo's en PostgreSQL-databases doorzoeken net zo natuurlijk als het bestanden leest. Geen custom wrappers. Geen fragiele API-code. Gewoon tools, beschikbaar en klaar.

Het MCP-ecosysteem groeit snel. Begin 2026 zijn er door de community onderhouden servers voor tientallen diensten — databases, communicatietools, cloudproviders, projectmanagementplatforms. De kwaliteit varieert (sommige zijn uitstekend, sommige zijn weekendprojectjes), maar de trend is duidelijk. MCP wordt de standaard integratielaag voor AI-agents.

Een beveiligingsopmerking die ik hier wil maken omdat het ertoe doet: elke MCP-server die je toevoegt, vergroot het aanvalsoppervlak van je agent. Een MCP-server met databasetoegang betekent dat je agent je database kan lezen — en mogelijk beschrijven. Beperk rechten strikt. Gebruik waar mogelijk read-only verbindingen. Geef je agent niet de sleutels tot productie tenzij je goed hebt nagedacht over wat er gebeurt als het een fout maakt. Want het zal fouten maken. De mijne zeker.

Dat brengt ons bij iets dat net zo belangrijk is als de tools die je agent kan gebruiken — en misschien nog belangrijker: de context die je agent ontvangt voordat het begint te werken.

Context Engineering: de vaardigheid die niemand onderwijst

Ik dacht vroeger dat prompt engineering de bottleneck-vaardigheid was voor het werken met AI. Schrijf betere prompts, krijg betere resultaten. En dat klopt — voor chatmodellen. Voor agents is de bottleneck iets anders: context engineering.

Context engineering is de praktijk van het structureren van wat een agent weet voor en tijdens de uitvoering. Het is niet alleen de prompt die je typt. Het zijn de bestanden die de agent automatisch leest. De projectspecifieke instructies die het verwerkt voordat het je verzoek behandelt. Het geheugen dat het meeneemt van eerdere sessies. De conventies die het volgt zonder dat het elke keer verteld hoeft te worden.

In Claude Code leeft context engineering voornamelijk op twee plaatsen: CLAUDE.md en agents.md-bestanden.

Je CLAUDE.md-bestand is het eerste dat Claude Code leest wanneer het een sessie start in een directory. Het mijne bevat projectspecifieke conventies, architectuurbeslissingen, codeerstandaarden en expliciete instructies over wat NIET te doen. Dat laatste deel — de negatieve beperkingen — bleek verrassend belangrijk. Zonder deze beperkingen maakt de agent constant redelijke-maar-verkeerde aannames.

Hier is een gestript voorbeeld uit een van mijn Laravel-projecten:

# CLAUDE.md

## Project Architecture
- Laravel 11 with Inertia.js + React 19 + TypeScript
- PostgreSQL 16, Redis 7 for caching and queues
- All API responses use the ApiResponse helper class — never return raw arrays

## Conventions
- Controllers: single-action when possible, __invoke method
- Form Requests for ALL validation — never validate in controllers
- Feature tests use RefreshDatabase, unit tests don't touch the database

## Do NOT
- Never modify the User model without explicit approval
- Never change database migrations that have already been committed
- Never use DB::raw() — use the query builder or Eloquent scopes
- Never create routes outside of routes/web.php and routes/api.php

Dat bestand bespaart me het corrigeren van de agent tientallen keren per sessie. Zonder zou Claude Code af en toe validatielogica in controllers plaatsen, ruwe SQL-queries gebruiken of routebestanden op niet-standaard locaties aanmaken. Allemaal redelijke keuzes op zich — gewoon fout voor dit specifieke project.

Het agents.md-patroon breidt dit verder uit voor multi-agent setups. Wanneer ik gespecialiseerde agents heb — een code review agent, een documentatie-agent, een testing-agent — krijgt elk zijn eigen contextbestand dat zijn rol, beperkingen en verwacht gedrag definieert. Dit is hoe je van één generieke agent naar een team van gespecialiseerde agents gaat die elk hun werk goed doen.

Remy Gasill maakte een punt dat me bijbleef: context engineering gaat uiteindelijk over het verminderen van het aantal beslissingen dat een agent zelfstandig moet nemen. Elke beslissing die het autonoom neemt, is een potentiële fout. Elke beslissing die je in context codeert, is één minder kans voor de agent om af te dwalen. De beste agent-setups die ik heb gebouwd, zijn bijna saai om naar te kijken. De agent maakt geen creatieve keuzes. Het volgt een goed gedefinieerd pad, met goed gedefinieerde tools, binnen goed gedefinieerde beperkingen. En het levert uitstekend werk op dankzij die voorspelbaarheid, niet ondanks die voorspelbaarheid.

Maar contextbestanden behandelen alleen wat de agent moet weten bij de start. Hoe zit het met wat het leert tijdens het werk?

Memory.md: je agent leren onthouden

Dit is de functie die mijn agent-workflows transformeerde van sessiegebaseerd naar continu.

Standaard verdwijnt alles wat de agent tijdens een sessie heeft geleerd wanneer je een Claude Code-sessie sluit. Open een nieuwe sessie, en het begint helemaal opnieuw. Het weet niets over de bug die je gisteren hebt gefixt. Het weet niets over het API-patroon dat je vorige week bent overeengekomen. Het weet niet dat de UserService-klasse tijdens de vorige sessie is gerefactord naar drie kleinere services.

Memory.md verandert dit. Het is een persistent bestand — opgeslagen in je projectdirectory — dat de agent leest bij het begin van elke sessie en kan bijwerken tijdens de sessie. Zie het als een gedeeld notitieboek tussen je verleden en toekomstige agent-sessies.

Mijn memory.md voor een huidig project ziet er ongeveer zo uit:

# Memory

## Decisions Made
- 2026-03-10: Switched from JWT to session-based auth. JWT was causing issues
  with token refresh on mobile. Session approach uses Redis for storage.
- 2026-03-14: Moved all email templates from Blade to React Email. Better
  component reuse and type safety.
- 2026-03-17: Added rate limiting middleware to all public API endpoints.
  Config: 60 requests/minute for authenticated, 20 for unauthenticated.

## Known Issues
- The PaymentService has a race condition on concurrent subscription updates.
  Temporary fix: database-level advisory lock. Proper fix planned for next sprint.
- Test suite takes 4+ minutes to run. Focus: writing targeted tests, not
  running the full suite on every change.

## Patterns Established
- All new services use constructor injection with interfaces, not facades.
- Background jobs extend BaseJob which handles retry logic and dead-letter queue.
- API versioning: URI-based (/v1/), not header-based.

Wanneer de agent dit bestand leest bij het begin van de sessie, heeft het onmiddellijk continuïteit. Het zal geen JWT voorstellen voor het authenticatiesysteem. Het zal geen Blade gebruiken voor e-mailtemplates. Het weet van de race condition en zal deze niet per ongeluk triggeren. Het volgt de vastgestelde patronen zonder eraan herinnerd te worden.

Ik werk dit bestand handmatig bij, ongeveer één keer per week, en ik ben begonnen de agent zelf notities te laten toevoegen wanneer er tijdens een sessie belangrijke beslissingen worden genomen. Het commando is simpel — "add this decision to memory.md" — en de agent formatteert en voegt het toe.

Het samengestelde effect is echt. Na een maand van het onderhouden van memory.md starten mijn agent-sessies merkbaar sneller. Minder correcties. Minder herhaling. Minder "nee, we hebben besloten het niet zo te doen." De agent heeft institutionele kennis. En die kennis is persistent.

Als je liever wilt dat iemand deze hele agent-architectuur voor je opzet — contextbestanden, geheugensystemen, MCP-integraties, de hele workspace — neem ik precies dit soort opdrachten aan. Je kunt zien wat ik heb gebouwd op fiverr.com/s/EgxYmWD.

Nu vertelt memory de agent wat er in het verleden is gebeurd. Maar hoe vertel je het hoe het terugkerende taken elke keer goed moet uitvoeren?

Skills: standaard werkprocedures die je agent kan volgen

Skills zijn het concept dat mijn agents eindelijk consistent maakte. Voordat ik ze adopteerde, varieerde de outputkwaliteit elke keer dat ik een agent vroeg om "een blogpost te schrijven" of "een API-endpoint te maken" of "een nieuwe microservice op te zetten." Soms uitstekend. Soms middelmatig. Altijd net iets anders dan de vorige keer.

Het probleem was niet het model. Het was ik. Ik gaf vage instructies en verwachtte consistente resultaten. Dat is alsof je iemand een functietitel geeft zonder inwerkhandleiding en je dan verbaast dat ze dingen anders doen dan je had verwacht.

Skills zijn de inwerkhandleiding.

Een skill is een markdown-bestand — opgeslagen in .claude/skills/ — dat stapsgewijze instructies bevat voor een specifieke, herhaalbare taak. De agent leest de relevante skill voordat het uitvoert, en volgt het als een standaard werkprocedure.

Hier is een echte skill die ik gebruik voor het aanmaken van API-endpoints in mijn Laravel-projecten:

# Skill: Create API Endpoint

## Steps
1. Create a Form Request class in `app/Http/Requests/` with validation rules
2. Create a single-action controller using `__invoke` method
3. Add the route to `routes/api.php` inside the appropriate version group
4. Create a feature test in `tests/Feature/Api/` that covers:
   - Successful request with valid data
   - Validation failure with each invalid field
   - Authentication/authorization check
   - Edge cases specific to the endpoint
5. Run the test suite: `php artisan test --filter={TestClassName}`
6. If tests pass, add the endpoint to the API documentation in `docs/api.md`

## Conventions
- Response format: always use ApiResponse::success() or ApiResponse::error()
- Status codes: 201 for creation, 200 for retrieval/update, 204 for deletion
- Never return Eloquent models directly — use API Resources

## Common Mistakes to Avoid
- Don't forget to add the route inside the auth middleware group
- Don't use Route::resource() — we use explicit single-action routes
- Don't skip the authorization check in the Form Request

Wanneer ik de agent vertel "maak een API-endpoint voor profielupdates van gebruikers," leest het deze skill en volgt het stap voor stap. Elke keer. De controllerstructuur is consistent. De testdekking is consistent. Het antwoordformaat is consistent. Geen variatie meer. Geen "oh, het vergat de Form Request dit keer."

Het mooie van skills als gewone markdown-bestanden is portabiliteit. Ze werken over agent-harnesses heen. Hetzelfde skillbestand dat ik in Claude Code gebruik, werkt in Cursor, in OpenClaw, in elke tool die markdown-instructies leest. Eén bron van waarheid, meerdere gebruikers.

Ik heb momenteel elf skills in mijn primaire project: API-endpoint aanmaken, databasemigratie, componentscaffolding, tests schrijven, code review, documentatie bijwerken, deployment checks, security audit, performance review, bug triage en PR-beschrijving genereren. Elk kostte me 15-20 minuten om te schrijven. Samen besparen ze me uren per week en — nog belangrijker — ze elimineerden een hele categorie van "de agent deed het fout"-momenten.

Skills stapelen met memory. De agent leest de skill voor hoe iets te doen. Het leest memory.md voor welke beslissingen er al zijn genomen. Samen geven ze de agent de procedurele kennis en institutionele context die het nodig heeft om te opereren als een teamlid dat al maanden aan het project werkt, niet als een contractor die de codebase voor het eerst ziet.

Beveiliging en rechtenschoping: het gesprek dat niemand wil voeren

Ik ga eerlijk zijn: een AI-agent toegang geven tot je filesystem, terminal en externe API's is een beveiligingsbeslissing. Behandel het als zodanig.

Een engineer die ik ken gaf zijn agent onbeperkte schrijftoegang en het overschreef een productie .env-bestand tijdens een routinematige refactor. Niets kwaadaardigs — gewoon een redelijke-maar-catastrofale beslissing in een context waarin de agent die macht niet had moeten hebben.

Mijn rechtenprincipes:

Principe van minimale rechten. Geef de agent precies de toegang die het nodig heeft en niets meer. Als het alleen bestanden hoeft te lezen, geef dan geen schrijftoegang. Als het alleen binnen /src hoeft te werken, geef het dan geen toegang tot /. MCP-servers moeten read-only databaseverbindingen gebruiken tenzij schrijfbewerkingen expliciet vereist zijn voor de taak.

Sandbox onvertrouwde operaties. Wanneer je een nieuwe skill test of een nieuwe MCP-server probeert, draai het eerst in een gesandboxte omgeving. Een verse git-branch, een Docker-container, een wegwerp-VM. Kijk wat de agent doet voordat je het vertrouwt met iets waardevols.

Audit trails zijn belangrijk. Git diffs zijn je vriend. Elke agentwijziging moet incrementeel worden gecommit zodat je kunt reviewen en terugdraaien. Ik review door agents gegenereerde diffs op dezelfde manier als ik pull requests van junior developers review — met aandacht en gezond scepticisme.

Scheid omgevingen strikt. Productieprojecten krijgen striktere rechten, minder MCP-servers en expliciete Do NOT-secties. Experimentele projecten krijgen meer vrijheid omdat de blast radius kleiner is.

API-sleutels en credentials. Plaats nooit credentials in voor de agent toegankelijke configuratiebestanden. Gebruik omgevingsvariabelen. Ga ervan uit dat alles wat de agent kan lezen, per ongeluk in een log of gegenereerd codecommentaar kan opduiken. Ik heb het zien gebeuren.

De agents die ik het meest vertrouw, zijn degene die ik het zorgvuldigst heb beperkt.

Over zorgvuldige architectuur gesproken — hoe je al deze onderdelen organiseert, is belangrijker dan je zou verwachten.

Workspace-architectuur: de mapstructuur die schaalt

Na maanden van iteratie heb ik een workspace-structuur ontwikkeld voor agent-aangedreven projecten die alles afhandelt — context, geheugen, skills, MCP-configuratie — zonder een rommeltje te worden naarmate het project groeit.

project-root/
├── .claude/
│   ├── settings.json          # MCP servers, permission config
│   ├── agents/
│   │   ├── code-review.md     # Specialized agent: code review
│   │   ├── documentation.md   # Specialized agent: docs
│   │   └── testing.md         # Specialized agent: test writing
│   └── skills/
│       ├── create-endpoint/
│       │   └── skill.md
│       ├── write-migration/
│       │   └── skill.md
│       ├── security-audit/
│       │   └── skill.md
│       └── deploy-check/
│           └── skill.md
├── CLAUDE.md                  # Project-level context (read on every session)
├── memory.md                  # Persistent agent memory
├── src/                       # Your actual code
├── tests/
└── docs/

Drie ontwerpbeslissingen die het vermelden waard zijn. Ten eerste, CLAUDE.md staat in de projectroot, niet verstopt in .claude/ — zichtbaarheid zorgt voor onderhoud. Ten tweede, skills zijn mappen (geen losse bestanden) omdat ze uiteindelijk ondersteunende templates en voorbeelden verzamelen. Ten derde, memory.md is enkelvoudig en globaal. Ik heb per-agent geheugenbestanden geprobeerd. Synchronisatie was een nachtmerrie. Eén gedeeld bestand houdt institutionele kennis verenigd over alle agents.

Deze structuur heeft vier klantprojecten overleefd zonder reorganisatie nodig te hebben. De sleutel is ermee beginnen vanaf dag één — achteraf inbouwen in een bestaand project is mogelijk maar omslachtig.

Aan de slag: je eerste productiewaardige agent-setup in 30 minuten

Als je tot hier hebt gelezen, heb je het mentale model. Hier volgt hoe je van nul naar een werkende agent-setup komt die alles omvat wat we hebben besproken — context, geheugen, skills en basis MCP-integratie. Dertig minuten. Geen shortcuts, geen speelgoedvoorbeelden.

Stap 1: Installeer Claude Code (5 minuten)

npm install -g @anthropic-ai/claude-code

Draai claude in je projectdirectory. Het authenticeert met je Anthropic-account bij de eerste keer. Als je een goedkopere setup nodig hebt, heb ik Claude Code with OpenRouter in een aparte gids behandeld.

Stap 2: Maak je CLAUDE.md (10 minuten)

Dit zijn de tien minuten met de hoogste hefboomwerking die je zult besteden. Maak een CLAUDE.md aan in je projectroot met vier secties: Project Overview (wat het is, welke stack), Architecture (belangrijke beslissingen, directorystructuur), Conventions (codeerstandaarden, naamgevingspatronen) en Do NOT (dingen die de agent nooit mag doen).

Wees specifiek. "Volg best practices" is nutteloos. "Alle API-antwoorden moeten de ResponseHelper-klasse in app/Helpers/ gebruiken" is nuttig. De agent kan je gedachten niet lezen, maar wel je markdown.

Stap 3: Initialiseer memory.md (2 minuten)

Maak een memory.md aan in de projectroot met drie lege secties: Decisions Made, Known Issues en Patterns Established. Begin spaarzaam. Dit bestand groeit organisch terwijl jij en de agent samen echte beslissingen nemen. Er voortijdig inhoud in forceren creëert ruis.

Stap 4: Maak je eerste skill (8 minuten)

Kies de taak die je het vaakst uitvoert. Voor mij was dat het aanmaken van API-endpoints. Voor jou kan het het schrijven van tests zijn, het scaffolden van componenten, of het opzetten van nieuwe pagina's. Wat het ook is — schrijf de stappen die je elke keer volgt in een skill.md-bestand:

mkdir -p .claude/skills/your-task-name

Schrijf het skillbestand met genummerde stappen, conventies en veelgemaakte fouten. Houd het onder de 50 regels. Als het langer is, combineer je ofwel meerdere skills of specificeer je te veel.

Stap 5: Voeg één MCP-server toe (5 minuten)

Begin met iets met laag risico. De filesystem MCP-server of de GitHub-server zijn goede eerste keuzes. Maak .claude/settings.json:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Sla de daadwerkelijke token op in je omgevingsvariabelen, niet in het configuratiebestand. Test het door de agent te vragen om "list my recent GitHub pull requests" en verifieer dat het echte data retourneert.

Stap 6: Draai je eerste agentische taak (5 minuten)

Begin met iets waarvan je het juiste antwoord kent — niet iets complex. Vraag de agent een taak uit te voeren die door je skillbestand wordt behandeld. Kijk hoe het context uit CLAUDE.md gebruikt en de stappen van de skill volgt.

Als de output het doel mist, zit de oplossing bijna altijd in de contextbestanden, niet in de prompt. Verscherp de CLAUDE.md. Werk de skill bij met de stap die het heeft overgeslagen. Dit iteratieve aanscherpen is het echte werk van het bouwen van productie-agents.

De toekomst is een persoonlijk AI-besturingssysteem

Dit is waar ik aan denk wanneer ik kijk naar waar dit allemaal naartoe gaat — en ik wil eerlijk zijn, dit is speculatie op basis van patronen, geen voorspelling waar ik mijn hypotheek op zou verwedden.

We bouwen naar persoonlijke AI-besturingssystemen. Niet het vaporware-type dat op conferenties wordt gepitcht. Het praktische type waarbij je agent-workspace de primaire interface wordt voor je digitale tools. Denk aan wat we al hebben: een agent die bestanden leest, commando's uitvoert, communiceert met API's via MCP, eerdere beslissingen onthoudt, gedocumenteerde procedures volgt en verbetert naarmate context en skills zich opstapelen. Dat is geen chatbot. Dat is een besturingssysteemlaag tussen jou en je tools.

Remy Gasill wees naar dezelfde conclusie. MCP biedt de integratiestandaard. Skills bieden procedurele kennis. Memory biedt continuïteit. Context engineering biedt afstemming. De puzzelstukken bestaan. Ze worden gebouwd op open protocollen die elk harness kan adopteren.

Wat mij het meest enthousiast maakt, is niet de uitbreiding van mogelijkheden — het is de vermenigvuldiging van hefboomwerking. Een engineer met een goed geconfigureerde agent-workspace werkt op een andere schaal. Taken die vroeger inhuren vereisten, worden taken die je delegeert tussen de koffie en je eerste vergadering.

Wat dit daadwerkelijk verandert aan hoe je werkt

Dit is wat ik wil dat je meeneemt — één helder mentaal model en één concrete actie.

Het mentale model: een AI-agent is een lus (observe, think, act) die draait in een harness (Claude Code, Codex, etc.), verbonden met tools (via MCP), geleid door context (CLAUDE.md, agents.md), procedures volgend (skills) en eerder werk onthoudend (memory.md). Elk van die componenten is een hefboom die je kunt bewegen om je agent beter te maken. Wanneer er iets misgaat, identificeer welk component faalde en repareer dat — herschrijf niet gewoon je prompt.

De concrete actie: neem vandaag dertig minuten en bouw de workspace-structuur die ik heb beschreven in de implementatiesectie. Maak de CLAUDE.md. Start de memory.md. Schrijf één skill. Voeg één MCP-server toe. Draai één taak. Dat is je startlijn.

Over zes maanden kijk je terug naar de agent-workflow die je hebt gebouwd — de opgebouwde context, de verfijnde skills, het beproefde geheugenbestand — en je realiseert je iets. De agent is niet slimmer geworden in die zes maanden. Jij bent beter geworden in het aansturen ervan. En dat is de echte vaardigheid die niemand onderwijst: niet hoe je AI gebruikt, maar hoe je het systeem architecteert dat AI bruikbaar maakt.

Wat is de eerste taak die je gaat delegeren?

Veelgestelde vragen

Wat is het verschil tussen een AI-agent en een gewone chatbot?

Een AI-agent voert autonoom meerstapstaken uit met behulp van tools — bestanden lezen, commando's uitvoeren, API's aanroepen — in een continue lus totdat het doel is bereikt. Een chatbot reageert op individuele prompts zonder actie te ondernemen. Voor details over de observe-think-act lus, zie de sectie Agent Loop hierboven.

Hoe werkt MCP (Model Context Protocol) met AI-agents?

MCP biedt een gestandaardiseerde interface voor het verbinden van AI-agents met externe tools en diensten zoals databases, API's en communicatieplatforms. Je configureert MCP-servers in het instellingenbestand van je agent, en de agent roept ze aan als native tools. Zie de MCP-sectie hierboven voor configuratievoorbeelden.

Heb ik programmeerervaring nodig om AI-agents voor productiviteit op te zetten?

Basiscomfort met de terminal en bekendheid met het bewerken van bestanden zijn voldoende om te beginnen. De workspace-setup gebruikt markdown-bestanden en JSON-configuratie — geen frameworkcode vereist. De stapsgewijze doorloop in de implementatiesectie behandelt de complete setup voor beginners.

Welk AI-agent harness moet ik gebruiken — Claude Code, Codex of OpenClaw?

Kies op basis van je workflow: Claude Code voor terminal-native development met diepe filesystem-integratie, Codex voor gesandboxte cloud-uitvoering met veiligheidsgaranties, OpenClaw voor maximale open-source uitbreidbaarheid. De sectie Agent Harnesses hierboven vergelijkt elk in detail.

Hoe houd ik mijn AI-agent veilig wanneer ik het toegang tot tools geef?

Pas principes van minimale rechten toe: read-only databaseverbindingen, beperkte API-tokens, gesandboxt testen voor nieuwe tools en expliciete rechtenbeperkingen in je contextbestanden. Sla nooit credentials op in voor de agent leesbare configuratiebestanden — gebruik omgevingsvariabelen. Volledige beveiligingspraktijken worden behandeld in de sectie Beveiliging hierboven.

Laten we samenwerken

Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help je graag.

• Fiverr (custom builds & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise-oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io