Agent configuration management barely exists as a practice. Ask a team running three AI agents in production where the system prompts live and the honest answer is usually a console text box, a .env file, and somebody’s laptop. No diff. No review. No rollback. No record of who changed the instruction that changed the behavior.
That is not a criticism of anyone. The tooling has not existed. It is starting to.
On 3 September 2026, Anthropic shipped ant apply in version 1.30.0 of its platform CLI, which creates and updates agents, environments, skills, memory stores and deployments from files in a repository, through a plan-and-approve loop with a committed lockfile. It is a small feature and it is worth looking at closely, because the design choices in it are the ones this category is going to argue about for the next two years.
One thing to say before you read further, because it decides whether this is useful to you: ant apply manages Claude Managed Agents API resources only. If your agents are Claude Code subagents, .claude/ configuration, or your own application calling the Messages API, it does nothing for you today.
This piece covers what actually counts as agent configuration, why losing track of it is worse than ordinary config drift, what ant apply does and the one design decision in it worth stealing, who got here first and who is still behind, the limits that will catch you, and what a three-person team should do this week without adopting anything new.
The short version: the problem is real and most teams have it, the tool that just shipped will not solve it for most of this article’s readers, and the fix available to everyone today is to put prompts and skills in git behind a pull request and stop editing them in a browser.
What counts as agent configuration
The reason this is hard to manage is that an agent’s configuration is not one thing, and the pieces live in different places.
- The system prompt. Prose, often long, frequently edited, and the single largest determinant of behavior.
- The model and reasoning effort. A one-line change that alters both cost and output.
- The tool list. What the agent can reach, and increasingly how it calls those tools, since async tool calling and similar options change behavior without changing a prompt.
- Skills. Reusable instruction bundles, which have their own versions and their own drift.
- Memory bindings. What persists between runs and who can write to it.
- The environment. Where it executes and what it can reach from there.
- The schedule. When it runs unattended, which is where a bad change does the most damage before anyone notices.
Most teams have those spread across a vendor console, a repository, a secrets manager and a scheduler, with no single artifact that describes the whole agent. When something behaves differently on Tuesday than it did on Monday, there is nothing to diff.
Why agent configuration management is harder than config drift
Configuration drift is an old problem and the industry has good answers to it. Agent configuration management has two properties that make the old answers fit badly.
The prompt is code, and it is not tested like code. A three-word change to a system prompt can change what the agent does with a customer’s data. There is no compiler, usually no test suite, and the failure is behavioral rather than an exception in a log. Teams that would never let an untested function reach production routinely let an untested prompt reach it, because the prompt does not look like production.
The console invites editing in place. Every vendor ships a web interface where you can change the prompt and see the result immediately. That is a genuinely good development experience and a genuinely bad production practice, and the two are the same button. The result is that the running configuration and whatever is in your repository diverge quietly, and the repository copy becomes fiction.
Add the schedule to that and you have the shape of an incident. An agent that runs at three in the morning on a prompt somebody adjusted in a browser last Thursday, against a memory store it can write to, is not an unusual setup in 2026. It is a fairly ordinary one.
What ant apply actually does
The mechanics are worth walking through because they are simple and because most of the category will end up looking like this.
ant is Anthropic’s platform CLI, written in Go. It is not Claude Code, which is a different tool with a different surface. Version 1.30.0 added the command, and the documentation states the model plainly: "Declare agents, environments, skills, memory stores, and deployments as files in your repository and keep the API’s resources in sync with them using ant apply."
Five resource types, in conventional directories: agents/, environments/, skills/ (directories containing a SKILL.md), memory_stores/ and deployments/.
Files can be YAML, JSON, or Markdown. The Markdown option is the nicest thing in the release, because it makes the system prompt what it actually is, which is prose in a file:
---
name: Summarizer
model: claude-opus-5
tools:
- type: agent_toolset_20260401
---
You are a helpful assistant that writes concise summaries.A deployment ties an agent to an environment, its memory access and a schedule:
---
name: Nightly review
agent: ../agents/reviewer.md
environment_id: ../environments/cloud.yaml
resources:
- path: ../memory_stores/review-notes.yaml
access: read_write
schedule:
type: cron
expression: "0 3 * * *"
timezone: America/Los_Angeles
---
Review any open pull requests. Start with the oldest.Running the command prints a plan and waits: yes, no, or details for a field-by-field diff. --dry-run prints and exits without writing anything.
State lives in claude-lock.json, in the repository. The docs say to "commit it with your files." It records each file’s resource kind, resource ID, version, and the origin it belongs to, meaning base URL, organization and workspace. There is no server-side state and no remote backend. Deleting a file leaves the resource alone with a warning; --prune removes it, archiving agents, environments and memory stores, and deleting skills.
The design decision worth stealing
The lockfile stores two hashes for every resource: what was last sent, and what the API returned.
If someone edits the agent in the console, those diverge, and the plan ends with "This plan cannot be applied:" and the command exits with "refusing to apply." You can override with --force.
That is stricter than Terraform, which would plan the revert and let you apply it. Anthropic’s choice is to stop and make you look.
I think that is the right call for this particular resource, and the reason is the prompt. When Terraform finds that someone resized an instance by hand, reverting is usually correct and the cost of being wrong is bounded. When your tool finds that someone edited a system prompt in a console, silently reverting destroys prose that a human wrote for a reason, probably in response to a failure you have not heard about yet. Refusing is the humane default.
It is also a good idea to copy in your own tooling, whatever vendor you are on. If your deploy script reconciles agent configuration, make it stop on unexpected remote state rather than overwrite it.
Anthropic is not first, and OpenAI is behind
The framing you will see elsewhere is that a frontier lab has brought infrastructure-as-code thinking to agents. That is not accurate and it is worth getting right.
AWS shipped this in April 2024. The aws_bedrockagent_agent resource landed in version 5.47.0 of the Terraform AWS provider and manages the agent’s instruction, foundation model and action groups, with Terraform’s plan-and-apply loop around it. That is roughly twenty-nine months ahead of ant apply.
Google’s google_vertex_ai_reasoning_engine manages the runtime and container rather than the prompt, so it is a partial answer. That split runs through the whole agent framework landscape: plenty of tooling manages where an agent runs, far less manages what it is told to do.
Microsoft’s M365 Copilot declarative agents use a JSON manifest and tooling in VS Code, with no plan-and-apply loop.
OpenAI’s official Terraform provider, which reached 1.0.0 in July 2026, manages organizational plumbing: projects, users, groups, roles, service accounts, rate limits and spend alerts. It does not manage agent definitions at all. If you are on OpenAI and you want your agent’s prompt in version control with a reconcile loop, there is no first-party answer today.
So the accurate positioning is narrower and still real: Anthropic is not first to declarative agents and not first to plan-and-apply, but it is first-party, needs no Terraform, and puts the prompt, the skills, the memory bindings and the schedule in one reviewable file. On the thing that matters most, the prompt, it is ahead of OpenAI’s provider, which does not touch it.
The limits, and the one that will catch you
The documentation is unusually candid about the gaps, which is to its credit. Several matter.
There is no import. Verbatim: "ant apply can’t adopt a resource you created in the Console or with ant beta:agents create. Only what’s in the lockfile is managed, and applying a file that describes an existing agent creates a second one." Anyone with agents already running is starting from a blank sheet, and a careless first apply gives you duplicates rather than an error. This is the footgun.
Renaming a file creates a new resource, and the old one stays until you prune it.
Nothing locks the lockfile. The docs say to "run one apply at a time." There is no state locking and no remote backend, which is a real constraint for a team and is roughly where Terraform was a decade ago.
Clearing fields is partial. A field you never set, or one the API cannot clear, keeps its current value.
Skills do not cross surfaces. Anthropic’s own documentation says custom skills "do not sync across surfaces" and that Claude Code skills are filesystem-based and separate from both claude.ai and the API. So ant apply will not manage the skills your team actually uses in Claude Code.
And the one that decides whether any of this applies to you: this manages Managed Agents API resources, and Managed Agents is still in public beta. Cost is $0.08 per session-hour metered to the millisecond while running, plus normal token rates, with no enterprise tier or special plan required. The barrier is not price or company size. It is whether you are on that product at all. Most agencies are not.
What to do this week without adopting anything
The problem is real whether or not the tool fits, and most of the fix needs no vendor.
Get the prompts out of the console and into the repository. One file per agent, prose in the file, config in frontmatter if you like the shape above. This is the whole thing. Everything else is a refinement.
Put a pull request in front of prompt changes. Not because the reviewer will catch a subtle behavioral regression, but because it produces a diff and a date and a name, which is what you will want when something changes and nobody remembers why.
Write down what a prompt change is allowed to skip. Most teams have a deploy checklist for code and nothing for prompts. Decide whether a prompt change needs a test run against saved inputs, and if the answer is yes, decide who has the saved inputs.
Designate one person who applies. Until your tooling locks state, concurrency control is social. This is true of ant apply by its own documentation and true of a shell script.
Pin skill and dependency versions, and treat a skill bump like any other dependency bump.
Audit what your scheduled agents can write to. The unattended ones on a cron are where an unreviewed configuration change is most expensive, and the blast radius is set by memory and tool access rather than by the prompt. We went through the write-access side of that question in agent write access, and the same inventory logic applies inward.
None of that requires migrating products, and all of it survives whichever vendor’s answer eventually wins. Good agent configuration management is a habit before it is a tool.
Frequently Asked Questions
What is agent configuration management? The practice of keeping the things that define an agent’s behavior, its system prompt, model, tools, skills, memory bindings, environment and schedule, in a reviewable and reversible form rather than in a console interface or on someone’s machine.
What is ant apply? A command added in version 1.30.0 of Anthropic’s platform CLI on 3 September 2026. It creates and updates agents, environments, skills, memory stores and deployments from files in your repository, with a plan you approve and a lockfile you commit.
Is ant the same as Claude Code? No. ant is Anthropic’s platform CLI for the API. Claude Code is a separate tool with a separate configuration surface, and ant apply does not manage Claude Code subagents or .claude/ configuration.
Can I use it if my agents run on my own application code? Not for the agents themselves. It manages Claude Managed Agents API resources. An application calling the Messages API directly has no resources for it to manage.
Does it cost anything? The command does not. Managed Agents bills at $0.08 per session-hour while an agent is running, metered to the millisecond, plus standard token rates. There is no enterprise tier requirement; a Console account, an API key and CLI 1.30.0 or later is the whole prerequisite list.
Can it adopt agents I already created in the console? No, and this is the sharpest edge in the release. There is no import. Applying a file that describes an existing agent creates a second one rather than taking ownership of the first.
What happens if someone edits an agent in the console after I have applied it? The lockfile stores both what was sent and what the API returned. When those diverge, the command refuses to apply rather than planning a revert. You can override with --force.
Is that better than how Terraform handles drift? For this resource, I think so. Terraform would plan the revert, which is usually right for infrastructure. Silently reverting a system prompt destroys text a person wrote deliberately, often in response to a problem the tool knows nothing about. Stopping and asking is the safer default.
Is Anthropic first to this? No. AWS shipped declarative, plan-and-apply Bedrock agents including the instruction in April 2024. Google’s Vertex resource covers the runtime rather than the prompt. Microsoft’s Copilot agents use a manifest with no apply loop. OpenAI’s Terraform provider manages organizational settings and does not manage agent definitions at all.
Should I switch products to get this? No. The problem is worth solving now; this particular tool is one answer, tied to a product still in public beta. Put your prompts in git behind a pull request and you have most of the benefit with none of the migration.
Can I manage secrets with it? No documented secrets management, variable interpolation or module system exists. Keep credentials where you keep credentials.
Is it safe to run against production today? With the caveats above, and with one person applying at a time, the mechanics are conservative: a plan you approve, no destructive default on file deletion, and a refusal rather than an overwrite when remote state has moved. The risk is the missing import, which is a first-run problem rather than an ongoing one.
