How to version, review, test and roll out the settings that shape how an AI agent behaves, so a quiet edit never becomes a loud incident.
Identity as Codetold us who an agent is.Policy as Codedecided what it may do. But two agents with the same identity and the same policies can still behave very differently, because behavior lives somewhere else: in the model, the prompt and dozens of settings around them.
In most organizations, those settings change in a console, a notebook or a shared document, with no reviewer and no record. That is the gap Configuration as Code closes.
In this article, you will learn:
The risk: why configuration is the quietest and most underestimated risk in agentic AI
The concept: what belongs in an agent's configuration file, and what never should
The release mindset: how to match the review to the size of the change
The practices: seven practices that keep agent behavior stable and explainable
The first steps: how to start in any organization
1. Why Configuration Is the Quiet Risk
A one-line prompt edit can change an agent more than a thousand lines of code.
Traditional software changes when someone changes the code. AI agents can change when nobody touches the code at all.
Prompts are instructions: rewording a single sentence in a system prompt can change what an agent refuses, what it shares and which tools it calls.
Models drift: Stanford and UC Berkeley researchers found that GPT-4's accuracy on identifying prime numbers fell from 84% to 51% between its March and June 2023 versions.
Safety does not carry over: practitioners report that resistance to prompt injection, refusal rates and output formats can all shift when a model version changes.
Settings multiply: temperature, tool descriptions, retrieval sources and guardrail thresholds each shape behavior, and each can be edited separately.
Regulators are watching this space. In April 2026, the Federal Reserve, the OCC and the FDIC issued SR 26-2, replacing SR 11-7 as the core model risk guidance for banks. It places generative and agentic AI outside its formal scope, but that is not a free pass:banks are still expected to govern these tools through their broader risk management. Every regulated industry faces the same question: can you show what changed, when, who approved it and how it was tested?
If you cannot say which prompt and which model an agent was running yesterday, you cannot explain what it did yesterday.
2. What Configuration as Code Means
Everything that shapes how an agent behaves should live in one file that anyone can review.
Configuration as Code means every setting that shapes an agent's behavior is written in a versioned file, reviewed like code, tested before release and deployed only through a pipeline. If a setting is not in the file, it does not reach production.
What belongs in an agent's configuration file
Model and exact version: a pinned version, never a floating alias that silently moves to whatever is newest.
System prompt and templates: the full instructions, stored as text so every word change is visible.
Generation settings: temperature, output length and the required output structure.
Tool descriptions: the text the model reads to decide when to call a tool, which makes it an instruction in its own right.
Retrieval settings: which sources the agent searches and how much it retrieves.
Guardrail settings: thresholds, blocked topics and escalation triggers.
Memory settings: what the agent may remember, and for how long.
Evaluation gates: the minimum scores a change must reach before it can ship.
What never belongs in it
Secrets: credentials are issued at runtime, never stored in configuration.
Personal data: examples and test cases use synthetic or approved data only.
When behavior lives in a reviewed file, a change is a decision someone made, not an accident someone discovers.
3. Treat Every Change as a Release
Not every change is equal, so not every change deserves the same review.
Fixing a typo in a prompt and switching to a new model are both configuration changes. Treating them the same way either slows everything down or lets risky changes slip through.
A simple tiering model solves this:
Cosmetic changes: formatting and typo fixes. Automated checks and the agent owner's approval are enough.
Behavioral changes: new instructions, new tool descriptions or new retrieval sources. These need the full evaluation suite and a second reviewer.
Material changes: a new model version, a new tool that can write or move money, or a change in autonomy level. These need risk sign-off, a gradual rollout and, in regulated firms, the same review a model change would get.
A safe path to production
Evaluate offline: run the change against a golden dataset of real scenarios, with pass marks set before anyone sees the results.
Test the edges: include prompt injection attempts, refusal checks and output format validation.
Run in shadow: compare the new configuration's answers with the current one on live traffic, without acting on them.
Release gradually: start with a small share of traffic, with automatic rollback triggers agreed in advance.
Match the scrutiny to the impact, and you get both speed for small changes and safety for big ones.
4. Seven Practices for Managing Agent Configuration
Stable behavior is not luck. It is the result of discipline applied to every setting, every time.
Pin everything: model versions, prompt versions and tool versions. Upgrades happen on purpose, not by surprise.
Keep one source of truth: remove console editing in production, and compare what is running with what is declared to catch drift.
Review by materiality: route each change to the right reviewers based on its tier.
Test behavior, not just syntax: a configuration file can be valid and still make the agent worse. Golden datasets and safety tests catch what syntax checks cannot.
Roll out gradually: shadow first, then a small share of traffic, then everyone, with rollback one click away.
Record the version with every action: log the configuration version alongside the agent identity and policy version, so any decision can be traced to the exact setup behind it.
Watch after release: monitor refusal rates, output length, format errors and evaluation scores, because providers can change model behavior even when your configuration has not changed.
An agent you can roll back in one click is an agent you can afford to improve every week.
5. Getting Started in Any Organization
Find where your prompts live today. The answer usually explains your next incident.
This works whether the agent drafts credit memos at a bank, summarizes patient notes at a hospital or answers customers at a retailer.
Find every prompt: list where prompts and settings live today: code, consoles, documents and individual laptops.
Move one agent into a repository: start with your highest-risk agent and put its full configuration under version control.
Pin the model: replace floating aliases with exact versions and plan upgrades as projects.
Build a golden dataset: collect real scenarios, including the ones that went wrong, and agree pass marks with the business owner.
Lock the console: once the pipeline works, remove manual editing rights in production.
Link the logs: add the configuration version to every trace, next to the identity and policy versions.
Version one agent's configuration properly, and you have built the template for every agent that follows.
Key Takeaways
Identity says who, policy says what, and configuration decides how the agent actually behaves.
Configuration is behavior: prompts, models and settings shape what an agent does as much as code does.
One file, one truth: every behavioral setting lives in a versioned, reviewed file, with secrets kept out.
Tier the review: cosmetic, behavioral and material changes deserve different levels of scrutiny.
Test and release like software: golden datasets, shadow runs and gradual rollouts with automatic rollback.
Trace every action: log the configuration version with the identity and policy versions.
When every prompt and model change is versioned, tested and traceable, you can explain an agent's behavior on any day you are asked.
How are prompts and model versions managed in your organization today:in a repository with reviews, or in a console anyone can edit? Share your experience in the comments.
This is Part 3 of the five-part series Governing AI Agents as Code.
Previous:
Next: Infrastructure as Code for AI.
Explore more: Start Here · Topics · Archive · About