AI-agent engineer worden in 2026: van prompt naar productie

Wat is het verschil tussen een chatbot en een agent?

Een chatbot beantwoordt vragen: er komt een prompt binnen en het model produceert tekst. Een agent doet meer: hij ontvangt een verzoek, stelt context samen, laat het model redeneren, valideert een actie, voert die uit in een gecontroleerde omgeving, werkt de staat bij en beslist dan of de lus doorgaat of stopt. Dat herhaalde patroon — intake, context, redenering, actie, validatie, uitvoering, staat, lus of stop — wordt de agent loop genoemd.

Het model zelf weet veel over de wereld, maar niets over jouw bedrijf. De waarde zit daarom niet in het model, maar in alles wat eromheen zit. In de woorden van Chrome: de harness reikt het model gereedschap aan en bepaalt wat het mag aanraken; de loop roept die gereedschappen herhaaldelijk aan met grenzen die zeggen wanneer te stoppen; evals en LLM-ops volgen elke run, scoren hem en voeren verbeteringen terug zodat het systeem beter wordt in plaats van wegdrijft. Wie die vier onderdelen begrijpt, leest elke agent-repository als een kaart.

Waarom de vraag nu explodeert

De cijfers zijn specifiek voor agenten, niet voor AI in het algemeen. Vermeldingen van "agentic systems" in vacatures groeiden van 151 in 2024 naar meer dan 16.500 in 2025, de sterkste stijging in vaardigheidsvraag die onderzoekers bijhielden. Naar de maatstaf van de Stanford AI Index stegen advertenties voor agentische functies met meer dan 10.000 procent.

Drie krachten stuwen de vraag:

• Modellen zijn over een drempel gegaan. Ze zijn goed genoeg om acties te ondernemen en gereedschap te gebruiken, niet alleen tekst te produceren. Bedrijven willen geen chatbot meer, maar werk dat wordt gedaan.
• Iedereen heeft dezelfde modellen. Het voordeel verschuift van het hebben van AI naar het opleveren van AI die standhoudt. Naar verwachting zit eind 2026 in veertig procent van de enterprise-applicaties een AI-agent, tegen minder dan vijf procent in 2024.
• De kloof tussen demo en productie is groot. Een soepele demo breekt zodra echte gebruikers hem raken. De mensen die die kloof kunnen dichten, zijn schaars, en bedrijven bieden tegen elkaar op.

De anatomie van een AI-agent

Wie een agent bouwt, ontwerpt vier lagen. De bekende indeling van Chrome is een handig denkraam en sluit aan bij wat ook in de uitleg over agenten versus chatbots op deze site staat.

1. Het model

Het model is de denklaag: algemene kennis, redeneervermogen, het vermogen om instructies te volgen. Maar een model op zichzelf is statisch. Het weet niets van jouw processen, je database of je producten. Al die kennis moet via context en gereedschap binnenkomen.

2. De harness: gereedschap en grenzen

De harness is de laag die het model verbindt met de wereld. Hij reikt tools aan — een zoekopdracht in documenten, een API-call, een database-query — en bepaalt welke acties zijn toegestaan en welke niet. Een agent zonder duidelijke grenzen is een risico: hij kan dingen doen die je niet bedoeld hebt. Daarom hoort bij elke tool een strakke omschrijving van wat hij mag aanraken. Dit raakt hetzelfde thema als guardrails voor taalmodellen.

3. De loop: herhaling met stopcondities

De loop roept de tools herhaaldelijk aan. Een verzoek komt binnen, context wordt samengesteld, het model redeneert, een actie wordt gevalideerd, uitgevoerd in een sandbox, de staat wordt bijgewerkt — en dan besluit de lus of hij doorgaat of stopt. Zonder stopcondities kan een agent eindeloos blijven proberen, zichzelf herhalen en tokens verbranden. Een gelimiteerde lus is daarom geen beperking maar een ontwerpkeuze.

4. Evals en LLM-ops: meten en verbeteren

Evals en observability zijn de laag die een agent betrouwbaar maakt. Elke run wordt gevolgd, gescoord en teruggekoppeld: waarom ging het mis bij invoer 4.000? Welke tool riep het model aan dat niet bestond? Door kwaliteit als getal te meten in plaats van te gokken, verandert een agent van "ziet er goed uit" naar "scoort 0,9 en hier is het bewijs". Observability-tools zoals LangSmith, gestructureerde logging met trace-ID's en dashboards zijn hier het gereedschap.

Welke vaardigheden heb je nodig?

Niemand neemt een agent-engineer aan die niet kan engineeren. De AI-laag ligt bovenop gewoon softwarevakmanschap. De basis is:

• Python — de taal van het vakgebied, voor sommige rollen aangevuld met Go.
• Backend en API's — services live zetten, FastAPI is een gangbare standaard.
• Cloud — vertrouwdheid met ten minste één cloudplatform om te deployen.
• Databases en datastructuren — de fundamenten die elke loop nog steeds test.
• Git en normale softwarehygiëne — versiebeheer, testen, code van anderen lezen.

Daarboven komt de agent-specifieke stack:

• Orchestratie-frameworks — LangChain en LangGraph zijn de gangbare, CrewAI en AutoGen voor multi-agent-opstellingen.
• Model-API's — praktische ervaring met OpenAI, Anthropic, Llama of Mistral en hun gedrag.
• RAG en vector-winkels — retrieval-pijplijnen op basis van Pinecone, Weaviate, Chroma of Qdrant; de basis staat in RAG voor beginners.
• De agent loop als ontwerppatroon — intake, context, redenering, actievalidatie, sandbox-uitvoering, staat, en dan lus of stop.
• De lagen eromheen — tool-interfaces, geheugenontwerp, orchestratie en guardrails die de agent binnen zijn limieten houden.

De rode draad, en waar interviewers op doorvragen: je ontwerpt een agent als een systeemactor met harde grenzen, niet als een alwetende magische doos.

Wat werkgevers willen zien

Eén gedeployed project verslaat tien notebook-experimenten. In vacatures en van hiring managers klinkt hetzelfde refrein: laat zien dat je iets in productie hebt gebracht. Wat telt in een portfolio:

• Een deployed service — een Python-applicatie met een echt endpoint, geen Colab-bestand.
• Observability — een screenshot van een trace in je README, LangSmith is het gangbare gereedschap.
• Evaluatie — echte scores op een testset: retrieval-precision en -recall, antwoordgetrouwheid en -relevantie, RAGAS-cijfers in de README.
• Productiekenmerken — rate limiting, API-key-authenticatie, gestructureerde logging met trace-ID's, dashboards en een alert dat afgaat bij foutpieken.
• Kostenbewustzijn — tokenverbruik per request gelogd, een doorlopende kostenschatting, p95-latency bijgehouden.
• Een geschreven post-mortem van één echte productiefout en hoe je die aanpakte.

Die laatste is wat een senior engineer doet knikken: hij toont operationele volwassenheid die een perfecte demo nooit laat zien.

Evals en tracing: de gewoonte die je onderscheidt

Als er één gewoonte is die je snel senior laat ogen, is het evaluatie en observability. Het is ook je grootste productiviteitsvermenigvuldiger: je vangt je eigen fouten voordat gebruikers ze zien. De werkwijze hoort bij elke wijziging te draaien. De meeste mensen lanceren een agent door een paar outputs te bekijken en te hopen; degenen die worden aangenomen, behandelen kwaliteit als een getal dat ze meten en verdedigen. Die overgang — van "ziet er goed uit" naar "scoort 0,9 en hier is het bewijs" — is wat productievolwassenheid betekent. Een vergelijkbare meetcultuur zie je terug op de benchmark-pagina van llmnet, waar modelprestaties tegen harde data worden gelegd.

Een realistisch bouwtraject

Een eerlijk voorbeeld uit de roadmap laat zien wat "gebouwd en live gezet" betekent. Het uitgangspunt: een supportteam beantwoordde elke klantvraag handmatig uit de documentatie, traag in pieken, en herhalingsvragen vraten de dag.

Wat werkte: RAG over de bedrijfsdocumenten, plus een agent-loop die beslist wanneer te zoeken, wanneer een tool aan te roepen en wanneer te antwoorden. Twee tools werden aangesloten — documentzoek en een orderstatus-opvraging — elk met strakke grenzen. Op schone vragen antwoordde de agent accuraat en snel, en de eval-scores gaven het team het vertrouwen om uit te breiden.

Wat brak: Bij rommelige meerluiksvragen ging de agent in een lus, zichzelf herhalend en tokens verbrandend. En af en toe verzon hij een tool-call die niet bestond.

Wat bewust níet werd gebouwd: zonder vrij mandaat om klanten te antwoorden, bleef er een menselijke goedkeuringsstap op uitgaande berichten staan tot eval-scores bewezen dat het veilig was. De lus werd begrensd in plaats van ongelimiteerd, zodat hij niet eindeloos kon draaien.

Het resultaat: schone vragen volledig afgehandeld, rommelige vragen doorgestuurd naar een mens, en elke uitgaande boodschap nog steeds goedgekeurd totdat de scores autonomie verdienen. Die eerlijke boog — wat werkte, wat brak, wat je koos om niet te bouwen — is precies het verhaal dat je aangenomen maakt.

De communicatieve kant

De rol zit tussen een bedrijf dat een resultaat wil en een model dat echte beperkingen heeft. Je werk is uitleggen wat een agent wel en niet betrouwbaar kan, een vage vraag omzetten in een concrete specificatie en de trade-offs uiteenzetten aan mensen die geen code schrijven. In gedragsrondes wordt direct getest hoe je een modelfout aanpakte, hoe je een meningsverschil oploste en hoe je een AI-resultaat uitlegt aan een niet-technische belanghebbende. Een engineer die kan bouwen maar het probleem niet kan kaderen voor een klant, wordt als het grotere risico gezien — niet als het kleinere.

Hoe het sollicitatieproces eruitziet

Bij de meeste bedrijven is het een standaard software- of ML-sollicitatieprocedure met AI-specifieke rondes erin, geen apart exotisch proces. Labs als Anthropic en OpenAI vouwen hun AI-vragen in de gewone rondes. Eerst telefonische screens met standaard technische fundamenten, daarna een onsite waar de AI-specifieke rondes zitten: een ronde systeemontwerp van 35 tot 60 minuten die start vanuit een open prompt. Vervolgens wordt doorgevraagd op de agent loop, tool-interfaces, geheugenontwerp, orchestratie, latentie en veiligheid. De hele tijd letten ze op één ding: niet wat agenten zouden kunnen, maar wat er breekt, wat je daadwerkelijk in productie hebt gebracht en hoe je over trade-offs redeneert.

Waar begin je, afhankelijk van je achtergrond?

• Al software-engineer: je hebt de basis al; voeg model-API's en LangGraph toe en bouw één gedeployed agent met evals en een trace.
• Data scientist of ML-professional: je kent modellen; je gat is productie — leer backend, deployment, observability en de agent loop.
• Frontend- of full-stack-ontwikkelaar: leun op je leveringsvaardigheden, leer RAG en agent-orchestratie, bouw een agent met een echte interface.
• Prompt-engineer of AI-hobbyist: je begrijpt modelgedrag; voeg het engineering-stuk toe — deploy het, meet het met evals, voeg observability toe.
• Van buiten de tech: begin met Python-fundamenten, dan één framework, dan één gedeployed project; reken op zes tot twaalf maanden.
• Backend-engineer zonder AI-ervaring: je bent één specialisatie verwijderd — voeg RAG, de agent loop en één productie-agent toe.

Conclusie

De bottleneck was nooit het model — iedereen heeft die nu. De bottleneck is de handvol mensen die een model dat indruk maakt in een demo kan omvormen tot een agent die standhoudt wanneer echte gebruikers, randgevallen en echt geld het raken. Dat is de hele reden dat het beroep betaalt wat het betaalt: de genoemde salarisbanden lopen van ruwweg 185.000 tot 550.000 dollar voor senior en frontier-lab-functies. De weg naar binnen is geen certificaat, maar één gedeployed agent met evals, een trace en een eerlijk verhaal over wat er brak. Bouw dat ene ding, en je solliciteert niet naar de stoel — je bewijst dat je er al in hoort.