AI agents are increasingly moving from experiments into production workflows. They can inspect systems, call tools, change infrastructure, open pull requests, and trigger operational actions. Yet many teams still manage the most important parts of an agent—its system prompt, tool permissions, output contract, and safety rules—as scattered text in notebooks, environment variables, or application code.
That is not just inconvenient. It is a governance problem.
If agent configuration influences production behavior, it should be managed like any other form of production configuration: declarative, versioned, reviewed, testable, and reversible. This is where GitOps becomes relevant—not as another fashionable label, but as a practical operating model for agentic systems.
Agent configuration is production behavior
For a conventional service, teams already treat deployment manifests, network policies, resource limits, and feature flags as controlled artifacts. An AI agent adds another behavioral layer:
- the system prompt defines role, boundaries, and decision priorities;
- the tool list determines which actions the agent can perform;
- the output schema defines what downstream systems may trust;
- policy bundles decide which actions are allowed, denied, or escalated;
- model and routing settings affect cost, latency, and risk;
- confidence and blast-radius thresholds determine when a human must intervene.
A change to any of these elements can alter production outcomes without changing a single line of traditional application code. Treating them as informal configuration creates an audit gap: teams may know which container image ran, but not which instructions or tool permissions shaped the agent’s decision.
What GitOps adds
The OpenGitOps principles describe desired state as declarative, versioned and immutable, automatically pulled, and continuously reconciled. Applied to agents, these principles create a clear chain from intent to runtime behavior.
A practical model looks like this:
- Agent configuration is stored in Git as structured data.
- A pull request shows the exact behavioral change.
- Automated checks validate schemas, policies, permissions, and evaluation results.
- Reviewers approve the change based on ownership and risk.
- A GitOps controller reconciles the approved state into the runtime platform.
- Telemetry confirms which version is active and how it behaves.
- A rollback restores the last known-good configuration when required.
This is already being applied in real cloud-native agent platforms. In a CNCF case study from Orange Innovation, each agent’s system prompt, tool list, and output schema is represented as a Kubernetes Custom Resource and reconciled from Git through Argo CD. Safety policies live in the same repository, making promotion code-reviewed, auditable, and reversible.
What should live in Git?
The goal is not to put every piece of runtime context into a repository. Git should contain the stable desired state that governs the agent.
Good candidates
- system prompts and instruction templates;
- allowed and denied tool definitions;
- input and output schemas;
- policy-as-code bundles;
- model selection and fallback rules;
- human-approval thresholds;
- resource limits and deployment settings;
- evaluation datasets and acceptance thresholds;
- ownership metadata and escalation routes.
What should not live in Git?
- API keys, tokens, and credentials;
- personal or customer-sensitive conversation data;
- short-lived runtime context;
- unfiltered model traces containing confidential data;
- mutable operational state that belongs in a database or event stream.
Secrets should be referenced through a secret-management system. Dynamic context should be retrieved through controlled tools with explicit identity, authorization, and audit trails.
An illustrative Kubernetes resource
Kubernetes Custom Resources provide one possible way to model agent desired state. The following example is illustrative rather than a proposed standard:
apiVersion: agents.platform.it-stud.io/v1alpha1
kind: AgentConfiguration
metadata:
name: incident-reviewer
spec:
promptRef: prompts/incident-reviewer-v12
modelPolicy:
primary: approved-enterprise-model
fallback: approved-low-latency-model
tools:
allow:
- read-observability-data
- create-incident-ticket
deny:
- execute-production-change
outputSchemaRef: schemas/incident-review-v3.json
policyBundleRef: policies/soc-reviewer-v8
humanApproval:
requiredFor:
- customer-facing-assets
- identity-systems
- actions-above-blast-radius-threshold
The value is not the YAML itself. The value is that the desired behavior becomes visible, reviewable, and reconcilable. A platform controller can translate this resource into runtime configuration while policy engines validate what teams are allowed to change.
The pull request becomes a governance control
A prompt review should not be treated like a copy-editing exercise. It is closer to reviewing infrastructure or authorization policy.
Different changes need different reviewers:
- domain owners review whether instructions reflect the intended business process;
- platform teams review runtime, deployment, and operational impact;
- security teams review tool permissions, policy rules, identity, and blast radius;
- AI engineers review model behavior, schemas, and evaluation results.
Branch protection and CODEOWNERS can turn this responsibility model into an enforceable workflow. A tool-permission change may require security approval, while a wording clarification within an existing boundary may only require the domain owner.
CI must test behavior, not just syntax
Schema validation is necessary but insufficient. An agent configuration can be valid YAML and still create unsafe or ineffective behavior.
A useful CI pipeline should combine:
- schema and policy validation;
- checks for forbidden tools or excessive permissions;
- prompt-injection and adversarial test cases;
- regression evaluations against representative scenarios;
- cost and latency budgets;
- output-schema conformance;
- evidence that required human escalation still occurs.
The result should be an evaluation report attached to the pull request. Reviewers then see not only what changed, but how the agent’s measured behavior changed.
Deployment needs progressive delivery
GitOps makes rollback possible, but production agent changes should still be introduced gradually. A prompt or policy update can pass offline evaluations and fail under real operational conditions.
Platform teams can apply familiar delivery patterns:
- shadow mode, where the new version makes decisions without executing them;
- canary rollout to a limited workload or user group;
- automatic rollback on quality, safety, latency, or cost regression;
- version labels in traces so behavior can be tied to the exact Git revision;
- human approval for changes that expand tool access or blast radius.
This is where agent operations begin to look less like prompt experimentation and more like mature platform engineering.
A practical operating model
Teams do not need a new organizational silo for every agent. They need clear contracts between existing responsibilities.
- Domain teams own desired outcomes and business constraints.
- AI engineering owns agent contracts, evaluations, and model behavior.
- Platform engineering owns the runtime, GitOps reconciliation, observability, and deployment controls.
- Security and risk own policy requirements, privileged actions, and evidence.
Machine-readable contracts—schemas, policies, Custom Resources, and evaluation thresholds—reduce coordination overhead. Teams can evolve their area without relying on undocumented meetings or hidden configuration.
A 30-day starting plan
- Inventory: identify production agents and locate their prompts, tools, policies, and schemas.
- Structure: move stable behavioral configuration into a versioned repository without migrating secrets or sensitive runtime data.
- Protect: add CODEOWNERS, branch protection, and approval requirements for high-risk fields.
- Validate: introduce schema checks, policy tests, and a small regression evaluation suite.
- Reconcile: automate deployment through an existing GitOps controller or equivalent reconciliation process.
- Observe: attach configuration version, model version, tool calls, cost, latency, and escalation outcomes to telemetry.
- Roll back: test restoration of the last known-good configuration before the first production incident.
Conclusion
AI agents should not be governed through scattered prompts and tribal knowledge. The configuration that shapes their behavior belongs in the same disciplined operating model used for other production systems.
GitOps provides a practical foundation: declared intent, version history, peer review, automated validation, continuous reconciliation, and fast rollback. Combined with policy-as-code, behavioral evaluations, progressive delivery, and human approval boundaries, it gives platform teams a credible way to scale agentic systems without losing control.
The core principle is simple: if a configuration change can alter what an agent is allowed to decide or do, it deserves the same engineering rigor as a production code change.