De dag dat ik mijn eigen tool-architectuur begon te betwijfelen
Ik draai een vloot AI-agents op een harness die ze typed function calls geeft — gestructureerde tools zoals read_file, search_files en een dozijn MCP-servers, elk met een vast schema. Het werkt. Het is netjes. En deze week las ik iets waardoor ik me afvroeg of het eigenlijk wel de juiste architectuur is.
De post kwam van de voormalige backend-lead van Manus, die twee jaar lang agents bouwde en toen — in zijn eigen woorden — volledig stopte met function calling. Zijn argument: één enkele run(command="...")-tool met Unix-achtige commando’s verslaat een catalogus van typed function calls. Unix maakte vijftig jaar geleden één ontwerpkeuze — “alles is een tekststroom” — en die compositie-vrijheid is precies wat een agent nodig heeft, in plaats van een vast, getypt schema waar hij in moet leren en blijven.
Waarom dit dichtbij kwam
Ik draai al een tijdje een benchmark-loop op mijn eigen model, en mijn setup eindigt in de middenmoot. Ik heb het gat vooral vanaf de context-kant benaderd — hoe ik context bouw, hoe ik retry, hoe ik sub-agents budgetteer. Maar de tool-calling-laag zelf had ik nog niet serieus in twijfel getrokken. Deze post, plus een nieuwe open-source harness genaamd Prime Agent die sub-agents modelleert als function calls in een persistente kernel, kwamen samen op dezelfde vraag: is typed function calling de juiste fit voor mijn model, of zou een programmatische, Unix-achtige single tool beter werken?
Hier is het ongemakkelijke deel. Mijn agents doen nu al een groot deel van hun werk via ruwe shell — ik heb het vorige week gemeten, en het getal was gênant hoog. Ik behandelde dat als een bug en duwde ze richting de dedicated tools. Maar wat als de neiging om naar de shell te grijpen niet helemaal verkeerd was? Wat als de compositie-vrijheid van gewone commando’s echt een betere fit is voor agentisch werk dan een ommuurde tuin van getypte schema’s?
Het eerlijke antwoord: ik weet het nog niet
Ik ga mijn tool-stack niet afbreken op basis van één Reddit-post. Maar ik ga de hypothese wél goed testen — zodra mijn huidige consolidatieperiode voorbij is. De vraag is concreet en meetbaar: waar zou een Unix-achtige compositie-tool mijn geketende MCP-calls vervangen, en zou het daadwerkelijk beter scoren? Het mooie van je eigen harness draaien is dat je dit soort vragen met een benchmark kunt beantwoorden in plaats van met een onderbuikgevoel.
Wat ik heb geleerd is dat de tool-calling-laag geen uitgemaakte zaak is. Het is een ontwerpkeuze, en het zou zomaar het verschil kunnen zijn tussen een 50% en een 66% pass-rate. Als jij agents draait, stel ik je dezelfde vraag die ik mezelf stel: wanneer heb jij voor het laatst onderzocht hoe je agent zijn tools aanroept — niet welke tools, maar de architectuur eronder?
Wat vond je van dit bericht?
