GitOps is the deployment model agents were waiting for

Strip an agent down to what actually determines its behavior and you find configuration: a system prompt, a tool manifest, a policy file, a model pin, a set of eval thresholds. All of it text. All of it diffable. All of it changing weekly — sometimes daily — because prompts get tuned, tools get added, models get swapped under you. A workload whose behavior is defined entirely by fast-moving declarative text, where an unreviewed change can alter behavior in ways nobody predicted: that is not just compatible with GitOps, it is the workload GitOps was unknowingly designed for.

The four OpenGitOps principles read like an agent governance checklist. Declarative: the agent's desired state is those files, not the memory of whoever last edited a console. Versioned and immutable: every behavior change has a commit, an author, and a review trail — which is precisely what a compliance team asks for the first time an agent does something surprising. Pulled automatically and continuously reconciled: the running agent converges on what git says, not on what someone hand-patched at 2 a.m.

Drift matters more for agents than for services

Here's why I'd argue agents need this discipline more than conventional workloads. When someone kubectl-edits a Deployment, the drift is at least mechanically visible — replica counts, image tags. When someone console-edits a system prompt, nothing looks different. The agent keeps answering. The change surfaces days later as a behavioral regression nobody can trace, because the deployed prompt no longer matches anything in version control. Continuous reconciliation with self-heal turns that class of incident into a non-event: the hand edit gets reverted on the next sync, and the only path to production is a reviewed commit. Argo CD's drift detection was built to catch manifest divergence; pointed at agent configuration, it catches personality divergence.

The rest of the ArgoCD toolbox maps just as cleanly. Sync waves order the bootstrap — policies and guardrails reconcile before the agents that depend on them. ApplicationSet generators stamp out per-tenant or per-environment agent instances from one template instead of forty hand-maintained copies. And the agent CI/CD pipeline plugs in as gates on the same flow: evals checked in as code, an integration eval gate with thresholded judge scores, shadow deployment, then a canary taking a small slice of live traffic before promotion. Rollback — the operation agent teams need most often and have least — becomes git revert: instant, atomic, auditable.

What doesn't belong in git

The concession, because GitOps orthodoxy has known exceptions and agents add one. Production Argo CD deployments already carry a break-glass pattern — suspend sync, patch by hand during an incident, reconcile git afterward — and self-heal can storm when it fights a mutating webhook; agents inherit those sharp edges. More fundamentally: an agent's memory — conversation state, learned preferences, accumulated context — is runtime data, not desired state. Declaring it in git would be a category error, the same one the multi-tenant SaaS world already codified as "GitOps exceptions" for DB-backed artifacts. The discipline applies to the agent's configuration, not its cognition. Knowing where that line sits is most of the design work.

But everything on the configuration side of the line deserves the full treatment. Teams currently tune production prompts in web consoles, and they are accumulating exactly the incident reports that pushed Kubernetes teams to GitOps a decade ago — only with a blast radius measured in customer conversations rather than pods. The tooling already exists. Agents just need to be declared.