It decides what stays in the context window, what gets summarised away, what executes in a sandbox and never enters context at all, when to hand a noisy sub-task to a subagent, and when to stop and ask a human. It is not a framework: you still write your own tools. It is not a gateway: it does not hold your credentials or your policy. It is the thing that keeps an agent alive from iteration one to iteration fifty.

The loop itself is about two hundred lines of code. Anyone can write it, and most teams do, in an afternoon. The harness is everything you build over the following six months, once that loop meets a real workload and starts facing roadblocks halfway through.

Our thesis is that models will become interchangeable, and that tools become the enterprise's differentiator rather than the vendor's, and that governance belongs underneath the agent rather than inside it. What we had underestimated was the harness. NetApp's Developer Platform Engineering team ran a genuinely hard workload against that thesis, at depth, ahead of the market, and showed us exactly where it bent.

In June 2025, Rob Rubin, now Senior Director of Developer Platform Engineering at NetApp, was already past the question most enterprises were still debating. His team runs the Kubernetes environments the rest of the company builds on, and self-service provisioning was already fully automated. The constraint was the interface in front of it: a request form can only ever offer what someone modeled in advance.

His idea was to put intent there instead. Describe the stack you want; let an agent assemble it from automation that already exists.
That meant two things from us.

No agent framework. No harness. That is not what the conversation was about yet.His reason for standardizing on MCP is why this story ends where it does:

In mid-2025 that was a minority position. It is a large part of why TrueForge ships open source rather than as a closed managed runtime.

The first phase was identity, and it is the part most teams underestimate.

Not "the agent holds an API key" identity. Real identity, where the person asking determines what the tools may do. A user authenticates through NetApp's identity provider. That identity is carried through the MCP Gateway into the MCP server, which resolves it against the user's own cluster account and issues short-lived, user-scoped credentials. Every kubectl call and every shell command executes as that person. Ask about something you don't have access to and you get exactly what a terminal would give you: nothing.

Four words, and they are the reason this reached production. An agent running as a service account with cluster-admin is a demo. An agent running as you is infrastructure.

Everything else lives in the gateway rather than in any individual agent: provider credentials, model-level RBAC, tool-level permissions, budgets, rate limits, guardrails, logging. Agents reference model names and server names; credentials never travel. That is what lets a platform team approve the fortieth agent as easily as the first, because a new agent is not a new copy of the security model.

By early 2026, the Kubernetes agent was live with users, and the shape of the workload explains everything that follows.

An engineer asks "why is my pod in CrashLoopBackOff?" The platform spans eight Kubernetes clusters serving the whole company, so the agent's first job is usually to locate the workload before it can diagnose anything. Then the investigation proper: describe the namespace, list pods, pull events, grep logs, inspect the ingress layer, query historical metrics. The MCP server exposes kubectl, a shell, Prometheus and a cluster-inventory tool. None of the sequence is scripted; the model composes it per problem.

Fifteen to thirty rounds of real command output, per question. Hold that number, because it is the whole engineering story.

Thirty iterations of raw kubectl and log output does something predictable to a context window. Investigations began dying mid-run.

What came back was not a feature request. It was a bug report, and a well-argued one:

He had ruled out the expensive suspects, which is the hard half of any diagnosis: not the model, not the prompt, not the tools. The layer he was pointing at turned out to sit just below the interface, the one deciding what stays in context, what gets summarised, and what executes elsewhere and never enters context at all.

We did not have that layer. We had quietly assumed the loop in between was the customer's problem to solve. That assumption is what NetApp broke, and it is the assumption we think most of the market is still making.

An open, self-hosted runtime removes a per-seat managed-platform bill. That is not the interesting part, and it isn't why NetApp is here.

Alongside attribution, the discipline problem: people reach for the largest model when a smaller one would do. Both are solved in the same place. Every model call and tool call tagged to a person and a team, budgets and rate limits that actually bind, routing that sends work to the appropriate model rather than the biggest one available.

<INSERT: NetApp Approved estimate - cost per investigation before/after Context Engineering, or % of investigations completing that previously died mid-run.>

We are not finished. Rob wants budget enforcement per execution rather than per week, and he's right: a weekly cap is blunt when one long-running agent can consume it in a single investigation. That lands in <quarter?>.

This is also why the harness and the gateway belong in one system. A harness alone gives you an agent. A harness inside a governed control plane gives you an agent that both your security team and your finance team will sign off on.