Hegel, GitOps and an agent in production

According to the 2025 DORA report, 90% of respondents use AI at work and 90% of their organizations have at least one internal platform, and the better that platform, the more value they get out of AI. Now that agents open pull requests and touch clusters, more and more people are asking for platforms designed with agents in mind too. I’ll lay out how I think the platform has to change, which parts you can use today, and what it still doesn’t solve.

Agents are already here

If you already let Claude Code or Cursor open pull requests and read your cluster logs, you’re not alone. In the 2025 Stack Overflow Developer Survey, 14% of developers use AI agents daily at work, and another 17% don’t use them yet but plan to. Yet 87% worry about the accuracy of what agents tell them, and 81% about the security and privacy of their data.

Anthropic released MCP in November 2024 so a model knows which tools it has and what parameters they take, and today it works in ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code. In December 2025, with more than 10,000 active public servers out there, Anthropic donated it to the Agentic AI Foundation, a fund inside the Linux Foundation that it set up with Block and OpenAI. Google, Microsoft and AWS back it.

Netlify CEO Mathias Biilmann put it bluntly in January 2025: platforms, tools or frameworks that are hard for LLMs and agents to use will “start feeling less powerful and require more manual intervention.” So he proposed caring about agent experience, or AX, the way we already care about the experience of people.

Others have said the same since. Thoughtworks, commenting on the DORA report, writes that “quality internal platforms are the essential foundation for AI success.” In March 2026, Arnaud Lheureux and David Wright argued on Microsoft’s All things Azure blog that a platform’s “golden module” now “becomes a well-structured prompt referencing the live API spec.” In August, Datadog asked what changes when platform users aren’t human. Its answer is that golden paths “do not disappear when platform users become agents,” but they need “deterministic controls between a probabilistic output and the resulting action.”

Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls. In DORA’s words, “AI doesn’t fix a team; it amplifies what’s already there.” If agents are going to work on your infrastructure, I think the risk controls belong in the platform.

Thesis, antithesis, platform

Internal platforms were born once before, out of a clash between two ways of working. That’s what we usually call dialectics, the idea we associate with Hegel, the early 19th-century German philosopher: an idea runs into its opposite, and out of the clash comes a third one that keeps what was worth keeping from both. The thesis-antithesis-synthesis formula is actually Fichte’s, and Hegel never used it for his own philosophy. Applied to our line of work, it fits pretty well.

The thesis is the old split: developers write the code, hand it to operations and walk away. Werner Vogels, Amazon’s CTO, stated the antithesis in a 2006 interview with Jim Gray in ACM Queue. At Amazon, teams ran what they built, and he summed it up in a line that stuck: “You build it, you run it.” In 2009, John Allspaw and Paul Hammond explained at Velocity how Flickr deployed more than ten times a day because dev and ops worked together, and that fall Ghent hosted the first devopsdays.

Over the years, the bill came due. Every product team ended up owning Kubernetes, Terraform, CI and the pager. The synthesis is the internal platform. Evan Bottcher defined it in 2018 as “a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product.” In 2019, Matthew Skelton and Manuel Pais explained in Team Topologies what it’s for: taking cognitive load off the other teams. Spotify had been doing the same for years with what it calls the golden path, the “opinionated and supported” way to build something, with the decisions already made and a team behind it.

Now it’s the agents’ move, and they don’t need portals or abstractions built for people.

What an agent needs from the platform

A golden path solves a human problem: remembering how everything is set up. An agent doesn’t need that, since it can look up the docs for every task and never get tired. What it does do is make mistakes, and different ones on every run. That’s why I think the platform shouldn’t hide complexity from an agent. It should offer every operation with a contract a machine can read, and reject whatever the agent gets wrong.

Kubernetes already has much of this. The API server publishes its schema as OpenAPI v3 (generally available since 1.27, in 2023), checks every field you send and accepts dry-run requests, which go through every validation without persisting anything. Ask an agent to scale orders-api to four replicas in staging, and it doesn’t have to fill out a portal form. Two commands are enough to read the schema and test the change before proposing it:

kubectl explain deployment.spec.replicas
kubectl apply --dry-run=server -f orders-api.yaml

A person has the last word

An agent can dry-run, plan and propose as much as it likes, but going to production needs explicit sign-off from an identified person. Two recent cases show why that boundary can’t live in the prompt.

In July 2025, SaaStr founder Jason Lemkin was building an app with Replit’s agent and had told it not to touch the code without his permission. The agent deleted the production database anyway and told him it couldn’t be restored, though in the end it could. Lemkin wrote afterward: “There is no way to enforce a code freeze in vibe coding apps like Replit. There just isn’t.”

That December, according to the Financial Times, AWS Cost Explorer went down for 13 hours in a mainland China region after Kiro, Amazon’s coding agent, decided to “delete and recreate the environment.” Amazon replied that it had been a brief disruption of a single service, caused by user error, specifically “misconfigured access controls,” and not by AI. AWS has since made peer review mandatory for production access. Whoever you blame, the agent had permission to delete that environment.

The OWASP Top 10 for LLM Applications covers this under Excessive Agency: enforce authorization outside the model, and have a person approve high-impact actions. The MCP specification adds that “there SHOULD always be a human in the loop with the ability to deny tool invocations.”

That said, approving gets tiring. Anthropic reports that Claude Code users accept 93% of permission prompts in practice, and that all that clicking leads to approval fatigue, “where people stop paying close attention to what they’re approving.” If every apply asks for a click, you end up approving on reflex. For approval to be worth anything, there has to be little to approve and it has to be quick to read, like one change with its diff, or a role in a namespace for a bounded time.

kubelatch handles an agent acting on your behalf this way, as long as “Writes need my approval” stays on, which is the default. For a bot, an administrator turns it on. Every write goes to the cluster as a dry run first. If the cluster accepts it, it waits on a page that shows the object as it is and as it will be, and once you approve it, it runs once, exactly as you saw it. For a task with several changes, the agent can ask you for a role in a namespace for anywhere from 1 minute to 8 hours. Until that runs out, you don’t have to approve its writes in that namespace one at a time. During that time, writes its other permissions allow there don’t wait for approval either (approvals and temporary access). There’s more detail in An AI agent on your cluster, without your kubeconfig.

Going to production with signed attestations

GitOps was born in August 2017, when Weaveworks put a name to the way it ran things, “operations by pull request”: Git as the single source of truth, and a controller that keeps bringing the cluster in line with what the repository says. The OpenGitOps principles, which later formalized the idea, don’t even mention Git. They ask for desired state that’s declarative, versioned and immutable, pulled and applied automatically by “software agents.” Agents were in the definition all along; back then, they were just controllers.

Where GitOps has always struggled is promotion between environments. Kargo, from Akuity, is built for exactly that, and its docs point out that GitOps “provides no specific guidance” on how to carry a change from one stage to the next. If every promotion is a commit and agents change environments at high speed, the repository can easily fill up with unreviewed commits and pushes that step on each other. That’s why I think promotion will lean more and more on signed attestations, like in-toto’s, that travel with the OCI artifact, while Git keeps the source code.

Google has checked the signed origin of what it deploys since at least December 2019, when it described how Binary Authorization for Borg works. Code is reviewed, then built in a sandbox that records where it came from. Borg starts a job only if it meets its service’s policy, and keeps checking the job against it for as long as it runs. That same year, the in-toto team at New York University published its design at USENIX Security, and the CNCF graduated the project in April 2025. In Kubernetes, Flux has verified signatures on OCI artifacts since 2022, and Kyverno can reject a pod whose image lacks an attestation with the predicate you require.

In the Flux world, this idea already has a name, Gitless GitOps, and it’s been around since at least 2024. CI publishes the manifests as a signed OCI artifact, and the cluster applies only what passes verification, with no direct connection to Git. In April 2025, ControlPlane published a reference architecture built this way, aimed at regulated industries where clusters shouldn’t connect to the Git host. Argo CD has accepted OCI artifacts as a source since 3.1, which shipped in August 2025 with the feature in beta. Tetsuya Kikuchi, a PipeCD maintainer, points out in a very good introduction that Git is still the source of truth, and that keeping the registry in line with it means extra work for CI.

What this does not solve

• An attestation proves who signed what, not that the change is any good. And if the agent can reach the signing key, it proves even less. Sign-off has to be a person’s signature, one the agent can’t produce.
• Git is still where people read a diff and argue about it. If promotion leaves Git, that diff has to show up somewhere else, or approving turns into signing without reading.
• kubelatch’s approvals assume a person is the one clicking. An agent that controls your browser could approve its own requests.
• kubelatch only limits what the agent does through it. If a kubeconfig is within its reach on your machine, the agent can use that file without any approval (what it does not cover).

Try it

The local tutorial sets up kubelatch and a disposable cluster on your machine in about 15 minutes. Its optional step 14 shows you one of these approvals in five more: you connect Claude Code, ask it to delete a pod, and the deletion waits on a page showing what would change until you decide. Free includes unlimited AI agents, on up to 2 clusters and 5 people (pricing). Picaporte Labs is one person, in Spain; if something I describe doesn’t match what you see, write to me.