In developer tooling zijn er twee kampen: sterke opinies versus maximale flexibiliteit. Het eerste kamp zegt: doe het zo, anders werkt het niet goed. Het tweede kamp zegt: jij bepaalt hoe je het doet, wij bieden de tools.
Wij kozen voor allebei. Dat is geen compromis, maar een bewuste architectuurkeuze die voortkomt uit een concreet inzicht: de twee kampen lossen elk een ander probleem op, en je hebt beide oplossingen nodig.
Het probleem met "flexibel"
De meeste agent-frameworks positioneren zich als flexibel. Kies je eigen model. Kies je eigen vector store. Kies je eigen deployment target. Kies je eigen observability stack.
Het klinkt aantrekkelijk. Maar in de praktijk betekent het: je moet alles zelf uitzoeken.
Hoe structureer je een agent die betrouwbaar is? Het framework heeft geen mening. Hoe handel je fouten af op een manier die in productie houdbaar is? Jouw probleem. Hoe richt je logging in zodat je ook na zes maanden nog kunt debuggen wat er misging? Vul zelf in.
Flexibiliteit zonder opinies is geen feature. Het is werk dat je naar de gebruiker doorschuift. Die gebruiker, in dit geval een ontwikkelaar of een team, moet nu alle beslissingen nemen die het framework heeft uitgesteld. En die beslissingen zijn niet triviaal. Ze vereisen ervaring met wat er in productie fout kan gaan, kennis van de trade-offs tussen verschillende aanpakken, en tijd om die aanpakken te evalueren.
De teams die dat goed kunnen, hebben dat kunnen opbouwen door veel te falen. Teams die geen tijd hebben om te falen, missen de kennis om de juiste keuzes te maken. Een flexibel framework helpt ze daar niet bij.
De illusie van snelheid
Er is nog een probleem met "flexibel": het suggereert snelheid. Kies wat je wilt, begin direct. Maar die snelheid is front-loaded. Je begint snel, want er zijn weinig constraints. Naarmate het systeem groeit, betaal je echter de rekening. Inconsistente patronen op verschillende plekken in de codebase. Foutafhandeling die in het ene deel van het systeem grondig is en in het andere deel ontbreekt. Logging die voor de helft nuttig is en voor de andere helft ruis.
De verborgen kosten van flexibiliteit zijn niet de initiële keuzes, maar de divergentie die optreedt als een systeem groeit en meerdere mensen eraan werken.
Het probleem met "opinionated"
Aan de andere kant: te sterke opinies creëren lock-in.
Als een platform vereist dat je op AWS draait, zit je vast als een klant Azure gebruikt. Als het platform alleen OpenAI ondersteunt, zit je vast als een klant een ander model wil, als een beter model beschikbaar komt, of als de prijs van OpenAI stijgt tot het niet meer aantrekkelijk is.
Lock-in op vendor-niveau is gevaarlijk in een markt die zo snel beweegt als AI. Het model dat vandaag het beste is, is over zes maanden misschien niet meer de beste keuze. De cloud-provider die vandaag de laagste latency heeft voor een bepaalde regio, kan dat morgen anders zijn.
Een platform met harde vendor-opinions bindt je aan besluiten die op een specifiek moment zinvol waren maar snel verouderd kunnen raken. En in een zakelijke context, waar klanten hun eigen contracten en voorkeuren hebben, is "dat ondersteunen wij niet" geen acceptabel antwoord.
Opinies als belemmering voor adoptie
Er is ook een adoptieperspectief. Een platform dat sterke opinies heeft over vendor-keuzes, sluit potentiële klanten uit die die opinies niet delen. Een grote onderneming die all-in op Azure is gegaan, haakt af bij een platform dat primair op AWS is gebouwd. Een team dat uitstekende ervaringen heeft met Anthropic, aarzelt bij een platform dat OpenAI als enige eersterangsoptie behandelt.
Opinies over vendors kosten markt. Dat is een concreet probleem.
Onze aanpak: opinies over patronen, niet over vendors
De oplossing die wij kozen: opinionated zijn over hoe je dingen doet, maar volledig agnostisch over welke tools je daarvoor gebruikt.
Wij hebben sterke opinies over hoe een agent gestructureerd moet worden. Hoe de graph van nodes en edges is opgebouwd. Hoe tools worden geregistreerd en aangeroepen. Hoe foutafhandeling werkt op het niveau van individuele tool-calls. Hoe retry-logica is geïmplementeerd. Hoe state wordt bijgehouden over een multi-turn conversatie.
Dit zijn geen configuratie-opties. Dit is de standaard. Je bouwt er niet omheen. Je volgt het patroon.
Welk LLM je gebruikt voor de inferentie, is volledig jouw keuze. OpenAI, Anthropic, Google, een open-source model dat je zelf host, een fine-tuned variant. De abstractie die de agent-laag blootstelt aan het model is uniform, ongeacht welk model eronder zit.
Hetzelfde geldt voor opslag
Wij hebben opinies over hoe je kennisopslag inricht, hoe je embeddings opslaat en hoe retrieval werkt. Maar of je daarvoor PostgreSQL met pgvector gebruikt, een dedicated vector database, of iets anders, is een infrastructuurkeuze die wij niet opleggen.
De interface is consistent. De implementatie is uitwisselbaar.
En voor deployment
Ons platform draait op Kubernetes. De manier waarop we secrets beheren, services deployen en schalen, is consistent en gedocumenteerd. Maar of die Kubernetes-cluster op Azure, GCP, AWS, of on-premises draait, is aan jou.
We hebben CI/CD-patronen die we volgen. Maar de specifieke tooling, of dat nu GitLab CI, GitHub Actions of iets anders is, wordt niet voorgeschreven.
Waarom dit werkt
De scheiding tussen "opinies over patronen" en "agnostisch over vendors" werkt omdat die twee dimensies orthogonaal zijn. Ze interfereren niet.
Of je nu OpenAI of Anthropic gebruikt, de foutafhandeling verandert niet. Of je op Azure of GCP draait, de structuur van je agent-graph verandert niet.
De patronen zijn stabiel. Vendors kunnen wisselen zonder dat de patronen breken.
Dat geeft teams het beste van beide werelden. Ze hoeven niet na te denken over hoe ze een agent structureren: het platform maakt die keuze voor hen, op basis van wat in de praktijk werkt. Ze hoeven niet na te denken over foutafhandeling-patronen, want die zijn standaard ingebakken.
Tegelijkertijd zijn ze vrij om de tools te kiezen die passen bij hun situatie: hun bestaande contracten, hun team-expertise, hun infrastructuur-voorkeuren en de technische eisen van hun klanten.
Hoe dit eruit ziet in de praktijk
Een concreet voorbeeld. Wanneer we een agent bouwen voor een klant in de financiële sector die all-in op Azure is gegaan, draaien we op Azure. We gebruiken Azure OpenAI Service voor de LLM-calls en hun bestaande Azure-identiteits-infrastructuur voor authenticatie.
De agent zelf, de graph-structuur, de tools, de foutafhandeling en de logging zijn identiek aan hoe we een agent bouwen voor een klant die GCP gebruikt en Anthropic prefereert.
We wisselen de adapters. We wisselen de configuratie. We passen de patronen niet aan.
Dat betekent ook dat onze kennis overdraagbaar is. Wat we leren van de ene deployment is direct toepasbaar op de andere. Er is geen aparte kennis voor "de Azure-klant" versus "de GCP-klant". Er zijn patronen die we toepassen, en er zijn infrastructuurkeuzes die per klant variëren.
De grens bewaken
Dit vereist discipline. De verleiding bestaat om gemak te bieden door vendor-specifieke features in de kern te integreren. Azure heeft bepaalde capabilities die nergens anders bestaan. Anthropic heeft bepaalde features die OpenAI niet heeft.
Die features zijn soms aantrekkelijk. Maar als we ze in de kern integreren, breken we de cloud-agnostische belofte.
Onze aanpak: vendor-specifieke features zijn beschikbaar via extensies of via de bestaande abstractie-laag. Ze zijn geen onderdeel van de kern. De kern blijft agnostisch.
Dat is soms een bewuste keuze om iets niet te doen, ook al zou het technisch makkelijk zijn. Die discipline is de prijs van de flexibiliteit, maar het is een prijs die de moeite waard is.
Wat dit betekent voor nieuwe klanten
Wanneer een nieuwe klant aansluit, is de eerste vraag niet "pas jij je stack aan aan ons platform?" De eerste vraag is "welke stack gebruik jij al, en hoe sluiten wij daarbij aan?"
Dat is een fundamenteel ander gesprek. Het verlaagt de drempel voor adoptie aanzienlijk en geeft klanten het vertrouwen dat ze niet in een nieuw lock-in-scenario stappen.
De opinies die we hebben, worden gewaardeerd. Teams willen niet opnieuw uitvinden hoe je foutafhandeling doet. Ze willen weten dat het goed geregeld is. Dat vertrouwen bieden wij.
Wat we niet bieden, is de beperkende keuze voor hen te maken. Dat vertrouwen vereist vrijheid.