Het bepaalt wat er in het contextvenster blijft, wat wordt samengevat, wat in een sandbox wordt uitgevoerd en nooit in de context terechtkomt, wanneer een ruisachtige deeltaak aan een subagent moet worden overgedragen en wanneer het tijd is om te stoppen en een mens in te schakelen. Het is geen framework: je schrijft nog steeds je eigen tools. Het is geen gateway: het beheert je inloggegevens of je beleid niet. Het is hetgeen dat een agent in leven houdt van iteratie één tot iteratie vijftig.

De loop zelf bestaat uit ongeveer tweehonderd regels code. Iedereen kan het schrijven, en de meeste teams doen dat ook, in een middag. Het harnas is alles wat je de zes maanden daarna bouwt, zodra die loop een echte workload tegenkomt en halverwege tegen obstakels aanloopt.

Onze stelling is dat modellen inwisselbaar zullen worden, dat tools het onderscheidende vermogen van de onderneming worden in plaats van dat van de leverancier, en dat governance onder de agent hoort in plaats van erin. Wat we hadden onderschat, was het harnas. Het Developer Platform Engineering-team van NetApp voerde een werkelijk zware workload uit om die stelling te toetsen, grondig en vooruitlopend op de markt, en liet ons precies zien waar het systeem tegen zijn grenzen aanliep.

In juni 2025 was Rob Rubin, nu Senior Director of Developer Platform Engineering bij NetApp, al voorbij de vraag waar de meeste ondernemingen nog over debatteerden. Zijn team beheert de Kubernetes-omgevingen waarop de rest van het bedrijf bouwt, en self-service provisioning was al volledig geautomatiseerd. De beperking was de interface daarvoor: een aanvraagformulier kan alleen bieden wat iemand vooraf heeft gemodelleerd.

Zijn idee was om daar in plaats daarvan intentie te plaatsen. Beschrijf de stack die je wilt; laat een agent deze samenstellen op basis van automatisering die al bestaat.
Dat betekende twee dingen voor ons.

Geen agent-framework. Geen harness. Daar ging het gesprek toen nog niet over. Zijn reden om te standaardiseren op MCP is waarom dit verhaal eindigt waar het eindigt:

Midden 2025 was dat nog een minderheidsstandpunt. Het is een belangrijke reden waarom TrueForge open source uitbrengt in plaats van als een gesloten managed runtime.

De eerste fase was identiteit, en dat is het onderdeel dat de meeste teams onderschatten.

Geen identiteit waarbij "de agent een API-sleutel vasthoudt". Echte identiteit, waarbij de persoon die de vraag stelt bepaalt wat de tools mogen doen. Een gebruiker authenticeert via de identiteitsprovider van NetApp. Die identiteit wordt via de MCP Gateway doorgegeven aan de MCP-server, die deze verifieert tegen het eigen clusteraccount van de gebruiker en kortstondige, gebruikersgebonden referenties uitgeeft. Elke kubectl-aanroep en elk shell-commando wordt uitgevoerd als die persoon. Vraag naar iets waar je geen toegang toe hebt en je krijgt precies wat een terminal je zou geven: niets.

Vier woorden, en zij zijn de reden dat dit de productieomgeving heeft gehaald. Een agent die draait als serviceaccount met cluster-admin is een demo. Een agent die draait als jij is infrastructuur.

Al het andere bevindt zich in de gateway in plaats van in een individuele agent: aanbiedersreferenties, RBAC op modelniveau, machtigingen op toolniveau, budgetten, snelheidslimieten, guardrails en logging. Agents verwijzen naar modelnamen en servernamen; referenties worden nooit verstuurd. Dat is wat een platformteam in staat stelt om de veertigste agent net zo gemakkelijk goed te keuren als de eerste, omdat een nieuwe agent geen nieuwe kopie van het beveiligingsmodel is.

Begin 2026 was de Kubernetes-agent live voor gebruikers, en de vorm van de workload verklaart alles wat volgt.

Een engineer vraagt "waarom zit mijn pod in CrashLoopBackOff?" Het platform omspant acht Kubernetes-clusters die het hele bedrijf bedienen, dus de eerste taak van de agent is meestal om de workload te lokaliseren voordat er überhaupt iets gediagnosticeerd kan worden. Dan het eigenlijke onderzoek: beschrijf de namespace, lijst pods op, haal events op, grep logs, inspecteer de ingress-laag, bevraag historische metrieken. De MCP-server stelt kubectl, een shell, Prometheus en een cluster-inventarisatietool beschikbaar. Niets van deze reeks is gescript; het model stelt het per probleem samen.

Vijftien tot dertig rondes van echte commando-output, per vraag. Onthoud dat getal, want het is het hele technische verhaal.

Dertig iteraties van ruwe kubectl- en log-output doen iets voorspelbaars met een contextvenster. Onderzoeken begonnen halverwege te sterven.

Wat terugkwam was geen feature-verzoek. Het was een bugrapport, en nog een goed onderbouwd rapport ook:

Hij had de dure verdachten uitgesloten, wat het lastigste deel van elke diagnose is: niet het model, niet de prompt, niet de tools. De laag waar hij naar wees, bleek zich net onder de interface te bevinden; de laag die bepaalt wat in de context blijft, wat wordt samengevat en wat elders wordt uitgevoerd en nooit in de context terechtkomt.

Die laag hadden we niet. We waren er stilletjes vanuit gegaan dat de loop daartussen het probleem van de klant was om op te lossen. Die aanname is wat NetApp heeft doorbroken, en het is de aanname waarvan wij denken dat de meeste partijen in de markt die nog steeds maken.

Een open, zelf-gehoste runtime elimineert de factuur van een beheerd platform per gebruiker. Dat is niet het interessante deel, en het is niet de reden waarom NetApp hier is.

Naast attributie is er het disciplineprobleem: mensen grijpen naar het grootste model terwijl een kleiner model zou volstaan. Beide worden op dezelfde plek opgelost. Elke model- en tool-aanroep wordt gekoppeld aan een persoon en een team, budgetten en limieten die daadwerkelijk werken, en routering die werk naar het juiste model stuurt in plaats van naar het grootste beschikbare model.

We zijn nog niet klaar. Rob wil budgethandhaving per uitvoering in plaats van per week, en hij heeft gelijk: een wekelijks plafond is te grofmazig wanneer één langlopende agent het in een enkel onderzoek kan verbruiken.

Dit is ook de reden waarom de harness en de gateway in één systeem thuishoren. Een harness alleen geeft je een agent. Een harness binnen een beheerd control plane geeft je een agent waar zowel je securityteam als je financiële team hun goedkeuring aan zal geven.