Week 12: Als de taal zelf niet begrijpt wat een agent is

Soms stelt een collega een vraag die je niet meteen kunt beantwoorden. Afgelopen week was zo’n moment. “Joop, denk je dat er een taal ontwikkeld zal worden speciaal voor AI-agents?”

Ik zweeg even. En daarna kon ik niet meer stoppen met nadenken.

Het probleem dat ik al tijden voelde

Stel je bouwt in Python een agent die betalingen verwerkt. Je wilt menselijke goedkeuring voor het uitvoeren van een betaling. Je wilt een auditlog. Je wilt dat de agent stopt bij te hoog tokengebruik. Je wilt monitoring.

Wat je krijgt: een decorator hier, een try/except daar, een logging statement dat je later toevoegt omdat je het vergeten was. Na een tijdje heb je geen agent meer — je hebt bedrijfslogica die verstrengeld is geraakt met governance, observability en infrastructuur. Elke nieuwe agent begint opnieuw met hetzelfde probleem.

Die worsteling ken ik. Ik had er alleen geen naam voor.

De vraag van mijn collega gaf me die naam: het ontbrekende fundamentele construct. Bestaande talen zijn gebouwd voor software. Functies, klassen, modules — dat zijn de basiseenheden. Een agent is iets anders. Een agent heeft een doel, gebruikt tools, beheert geheugen over meerdere stappen, delegeert werk aan andere agents en moet soms wachten op een mens voordat hij verdergaat. Dat gedrag zit niet in de taal. Het zit in conventies, documentatie en de hoofden van de mensen die de code schrijven.

Zo ontstond Orca op papier: een taal die de agent als fundamentele eenheid neemt in plaats van de functie.

Governance hoort in de taal, niet in de bibliotheek

Het meest uitgesproken ontwerpprincipe van Orca is dat governance structureel is. Een agent declareert dat hij de permissie financial.write nodig heeft. Een global hook bepaalt dat alle agents met de tag destructive menselijke goedkeuring vereisen. De compiler waarschuwt als je een tool aanroept zonder de juiste permissie. De runtime weigert een agent te starten zonder de vereiste rol.

Die regels staan niet verspreid door de codebase. Ze zijn een apart, leesbaar onderdeel van de taal. Een compliance officer kan ze lezen zonder één regel bedrijfslogica te begrijpen.

Hetzelfde geldt voor observability. In de meeste systemen is dat iets dat je toevoegt: instrumenteer, configureer logging, zet een tracing-library op. Bij Orca genereert elke agent-run automatisch een volledige trace. Niet omdat iemand dat heeft geconfigureerd, maar omdat de runtime weet wat een agent is en wat er tijdens een run kan gebeuren. Je kunt een productietrace lokaal herspelen door de opgeslagen tool-outputs te injecteren. Exact reproduceerbaar, zonder omgeving opnieuw in te richten.

En schaalbaarheid? Schrijf fan_out(sources) en de runtime bepaalt of dat lokaal of gedistribueerd gebeurt op basis van beschikbare workers. Jij declareert de intentie. De rest is niet jouw probleem.

Orca bestaat niet

Dit is het punt waar het interessant wordt: Orca is een gedachte-experiment. Er is geen implementatie, geen compiler, geen pakketbeheer.

En toch: de vraag wat zou een taal moeten begrijpen om agents goed te ondersteunen dwingt je tot scherpe keuzes. Wat is een agent precies? Wat betekent governance in een agent-systeem? Waar ligt de grens tussen wat de schrijver van de agent moet weten en wat de runtime voor hem kan afdekken?

Die keuzes zijn bruikbaar vandaag, in Python of TypeScript. Niet omdat je Orca gaat implementeren, maar omdat de ontwerpprincipes — governance structureel maken, observability inbakken, schaalbaarheid declaratief houden — toepasbaar zijn los van de taal. De vraag verschuift alleen: waar leg je die structuur neer als de taal het niet voor je doet?

Terwijl dat idee in mijn hoofd groeide, liep er in de achtergrond een andere taak: 351 afleveringspagina’s genereren voor AIToday Live.

Schalen wat al werkt

Vorige week beschreef ik de GEO-architectuur — hoe je content structureert zodat taalmodellen jouw organisatie herkennen. Deze week draaide het om de uitvoering. Eén prototype voor een enkele aflevering, daarna systematisch naar alle 330+. Elke pagina met een feitelijke samenvatting, transcriptie, Schema.org markup, gastprofiel, gerelateerde afleveringen en artwork.

Dat klinkt schoner dan het was. Template-engines interpreteren {title} in HTML-content als placeholder en overschrijven je titels. CSS grid containers die dubbel zitten veroorzaken layouts die je niet herkent. Gastdata die via slug-matching moet worden gekoppeld aan profielpagina’s, waarbij variaties in naamschrijving moeten worden opgevangen.

Elke bug had een duidelijke oorzaak als je er lang genoeg naar keek. Maar dat wist je vooraf niet. Je stuurde bij, begreep het patroon, paste de aanpak aan. Aan het einde van de week staan 351 pagina’s online met consistente markup en metadata. Dat is ook wat dit soort werk inhoudt: niet elegant van begin tot eind, maar grondig in de oplevering.

Wat het met mij deed

De vraag van mijn collega raakte iets. Niet de technische kant — dat talen kunnen evolueren is geen verrassing. Maar de formulering: speciaal voor AI-agents. Alsof dat überhaupt een valide categorie is.

Ik realiseerde me dat ik dat jarenlang als gegeven heb behandeld. Agents zijn extensies op bestaande software. Je pakt een framework, je bouwt er bovenop, je accepteert dat governance, observability en geheugen los geregeld moeten worden. Zo werkt het nu eenmaal.

De vraag van mijn collega deed me twijfelen aan die aanname. En dat twijfelen voelde goed. Geen gefrustreerd “dit moet beter”, maar een geïnteresseerd “wat zou er anders kunnen?”

Denkexperimenten zijn geen tijdverspilling. Ze zijn het soort denken dat voorafgaat aan echt bouwen. Je ontwerpt een taal op papier, en terwijl je dat doet, leer je wat je nu anders zou aanpakken in de projecten die je al hebt. Die governance hook die je altijd als afterthought toevoegt? Misschien zit er een ontwerpfout in je architectuur, niet in je discipline.

Dat besef had ik niet aan het begin van de week. Ik had het wel aan het einde.