Er is een moment in elk softwareproject waarop je beseft dat je het verkeerde aan het bouwen was. Je hebt weken besteed aan het schrijven van een berichtenrouter, een tool-uitvoeringsengine, een gespreksstatusbeheerder en een retry-systeem — en dan ontdek je dat de AI-provider dit allemaal al afhandelt, beter dan jij zou kunnen, in één enkele API-aanroep.
Dat moment leidde tot NanoClaw's architectuur. De volledige kern — het deel dat een WhatsApp-bericht omzet in een AI-agentrespons met toolgebruik, webbrowsing, bestandstoegang en meervoudige gespreksturnussen — is ruwweg 500 regels TypeScript. Geen 500 regels lijmcode die 50.000 regels framework importeert. Vijfhonderd regels, totaal, gebouwd bovenop Anthropic's Claude Agent SDK.
De reactie van ontwikkelaars die de broncode voor het eerst lezen is meestal ongeloof, gevolgd door de vraag die ertoe doet: "Waar is de rest?"
Wat Claude Agent SDK werkelijk doet
De meeste AI-agent-frameworks bestaan omdat taalmodel-API's historisch gezien stateless en eenvoudig waren. Je stuurde een prompt, je kreeg een antwoord. Als je toolgebruik wilde, moest je de tool-uitvoeringslus zelf bouwen. Als je meervoudige gespreksturnussen wilde, moest je de berichtgeschiedenis zelf beheren. Als je wilde dat het model koos tussen meerdere tools, moest je de routeringslogica zelf bouwen.
Claude Agent SDK verandert die vergelijking fundamenteel. De SDK roept niet alleen de Claude API aan — het draait een agentlus. Je geeft het een systeemprompt, een set tools en een gebruikersbericht. De SDK handelt al het andere af: het stuurt het bericht naar Claude, ontvangt het antwoord, controleert of Claude een tool wil gebruiken, voert de tool uit, stuurt het resultaat terug naar Claude, en herhaalt dit totdat Claude een definitief antwoord produceert. De volledige tool-use-lus — datgene waar de meeste frameworks duizenden regels aan besteden — is één enkele functieaanroep.
Dit is geen dunne wrapper. De SDK handelt streaming, retry-logica, tokentelling en gespreksstatus af. Het beheert het heen-en-weer tussen Claude en tools over meerdere turnussen, inclusief randgevallen zoals mislukte tooluitvoeringen en context window-limieten. De complexiteit die NanoClaw niet hoeft te implementeren ontbreekt niet — het is verplaatst naar een goed geteste SDK die wordt onderhouden door Anthropic's eigen engineeringteam.
Wat NanoClaw daadwerkelijk bouwt
Als de SDK de agentlus afhandelt, wat doen NanoClaw's 500 regels dan eigenlijk? Het antwoord is alles eromheen — de delen die specifiek zijn voor het draaien van een persoonlijke AI-assistent in plaats van alleen een API aanroepen. De eerste verantwoordelijkheid is kanaalintegratie. NanoClaw verbindt met WhatsApp via de Baileys-bibliotheek, ontvangt berichten en routeert ze naar de juiste agent-container. Dit is de lijm tussen "iemand stuurde een bericht op WhatsApp" en "een agent moet dit bericht verwerken." Het is geen ingewikkelde code, maar het is essentiële code — zonder dit heeft de agent geen manier om gebruikers te bereiken waar ze al zijn.
De tweede verantwoordelijkheid is containerorkestratie. Elk agentgesprek draait in zijn eigen Linux-container — Apple Container op macOS, Docker op Linux. NanoClaw start containers, mount de juiste mappen, geeft secrets door via stdin en verzamelt antwoorden. Dit is de beveiligingsgrens die voorkomt dat een gecompromitteerde agent iets buiten zijn sandbox kan benaderen. Het levenscyclusbeheer van containers is misschien 80 regels code, maar die 80 regels zijn het verschil tussen een agent die je kunt vertrouwen met echte credentials en een die dat niet kan.
De derde verantwoordelijkheid is persistent geheugen. NanoClaw onderhoudt een SQLite-database van gesprekken, groepsstatus en geplande taken. Elke WhatsApp-groep krijgt zijn eigen CLAUDE.md-bestand dat dient als het langetermijngeheugen van de agent voor die groep. Het geheugensysteem is eenvoudig — bewust zo — omdat het complexe deel van geheugen (bepalen wat relevant is, wat op te halen, hoe context te gebruiken) wordt afgehandeld door Claude zelf.
De vierde verantwoordelijkheid is geplande taken. Gebruikers kunnen de agent vragen om dingen op specifieke tijden te doen — "herinner me om 15:00" of "controleer deze website elke ochtend." NanoClaw's cron-achtige planner triggert agent-containers op de juiste tijden, wat een kleine maar oprecht nuttige feature is die een reactieve chatbot omzet in een proactieve assistent.
Waarom 500 regels ertoe doet
Het aantal regels is geen ijdelheidscijfer. Het is een directe maat voor het onderhoudsoppervlak, het bugoppervlak en de cognitieve belasting die nodig is om het systeem te begrijpen.
Wanneer er een bug verschijnt in NanoClaw's kern, zijn er 500 regels waar deze kan zitten. Een ontwikkelaar kan de volledige codebase in minder dan een uur lezen en elke gemaakte beslissing begrijpen. Vergelijk dat met frameworks met 50.000 regels kerncode — een bug vinden betekent navigeren door abstracties, pluginsystemen begrijpen en uitvoering traceren door lagen van indirectie die bestaan om features te ondersteunen die je misschien niet eens gebruikt.
De beveiligingsimplicaties zijn even concreet. Elke regel code is een potentiële kwetsbaarheid. NanoClaw's 500-regelige kern heeft een kleiner aanvalsoppervlak dan de configuratieparsers van de meeste frameworks. De containerisolatie, het doorgeven van secrets via stdin, de mount-allowlists — deze beveiligingsfeatures zijn geïmplementeerd in code die klein genoeg is om in een middag volledig te auditen.
En het upgradeverhaal is eenvoudig. Wanneer Anthropic een nieuwe versie van Claude Agent SDK uitbrengt met beter toolgebruik, snellere streaming of nieuwe mogelijkheden, krijgt NanoClaw die verbeteringen door één dependency bij te werken. Er is geen framework-abstractielaag die bijgewerkt moet worden om nieuwe SDK-features beschikbaar te maken. De SDK is het framework. ## De filosofie van niet bouwen
Het moeilijkste deel van NanoClaw's architectuur was niet het bouwen — het was beslissen wat niet te bouwen. De verleiding om een eigen tool-uitvoeringsengine toe te voegen, een geavanceerd geheugenophaalsysteem, een multi-provider-abstractielaag, een plugin-marktplaats — dit zijn allemaal dingen die andere frameworks hebben gebouwd, en het zijn allemaal dingen die NanoClaw bewust niet heeft.
Elk van die features zou duizenden regels code toevoegen, tientallen potentiële bugs en weken aan onderhoudslast. En elk zou functionaliteit dupliceren die Claude Agent SDK al biedt of die Claude zelf beter afhandelt dan handgeschreven code ooit zou kunnen.
Het resultaat is een project waar de interessante beslissingen architecturaal zijn, niet implementationeel. Hoe moeten containers geïsoleerd worden? Hoe moeten secrets worden doorgegeven? Hoe moet geheugen per groep worden afgebakend? Dit zijn de vragen die ertoe doen voor een persoonlijke AI-assistent, en het zijn de vragen waaraan NanoClaw's 500 regels gewijd zijn.
De volgende keer dat je een AI-agent-framework evalueert, tel geen features. Tel regels. Het framework met de minste regels is niet het minst capabele — het is misschien degene die het probleem goed genoeg begreep om de AI-provider het zware werk te laten doen.