Anthropic ant apply: Claude Agent Resources as Code

Quick answer

Anthropic added ant apply in ant CLI 1.30.0 on September 3, 2026. It lets teams describe Claude Platform resources as files in a repository and then create or update those resources from the CLI.

The supported resource types include agents, environments, skills, memory stores, and deployments. After an apply, the CLI writes a claude-lock.json file so later runs can reconcile the same remote resources rather than creating new ones.

That makes this more than a convenience command. It moves part of Claude agent operations toward a familiar software-delivery pattern:

define → review → plan → apply → record state → repeat.

For teams already treating prompts, skills, permissions, environments, and deployment schedules as production infrastructure, this is a meaningful shift. But it also comes with operational boundaries: ant apply cannot automatically adopt most resources created separately in the Console, --prune can remove resources, CI runs need explicit non-interactive flags, and Anthropic says only one apply should run at a time because the lockfile itself is not locked.

For broader context, see TowCue's Claude review, AI agent best-practices guide, and Anthropic Computer Use / Browser Use / Skills / Files API GA update.

What ant apply actually changes

Before this release, a team could manage agent infrastructure through a mixture of Console configuration, API calls, scripts, and local documentation. That works for experiments, but it becomes difficult to answer basic production questions:

Which version of this agent is deployed?
Which skill version does it reference?
Which environment is it attached to?
Who changed the configuration?
Can we review the change before it reaches production?
Can we reproduce the same setup from a repository?

ant apply gives teams a file-based source of intent for those resources.

Anthropic's documentation shows agents defined in Markdown with YAML frontmatter, environments and memory stores in configuration files, and deployments referencing those files by relative path. When the project is applied, path references are resolved to the resource versions created in that same run.

The result is much closer to resources as code than to a one-off CLI helper.

The lockfile is the important part

The key artifact is claude-lock.json.

Anthropic says the lockfile records the remote resources associated with the repository files. You commit it so later runs — whether on a developer machine or in CI — update the same resources instead of silently creating duplicates.

That creates a useful separation:

Layer	Purpose
Repository files	What you want the agent system to look like
`ant apply` plan	What would change remotely
`claude-lock.json`	Which remote resources those files currently manage
Claude Platform	The live agents, skills, environments, memory stores, and deployments

This is conceptually similar to stateful infrastructure tooling, although teams should not assume identical semantics to Terraform or Kubernetes. Anthropic documents its own reconciliation rules, and those rules matter.

Why this is useful for AI agent teams

AI agent configuration is increasingly operational infrastructure.

A production agent can depend on much more than a model name. It may have:

a system prompt or agent instruction file;
multiple reusable skills;
a memory store;
an execution environment;
tool permissions;
another agent acting as a sub-agent;
a deployment schedule;
networking configuration.

If those pieces live only in dashboards, they are harder to review as a coherent change.

Putting them in a repository means a pull request can show, for example, that a new agent version changes both its instruction and the skill it calls. A reviewer can inspect the diff before the remote resource changes.

For teams that already use code review as an approval boundary, that is a much cleaner governance model than documenting Console edits after the fact.

A practical CI/CD pattern

Anthropic documents a straightforward split between pull requests and the default branch.

On a pull request, run:

ant apply --dry-run .

This prints a plan without applying or writing the lockfile. It gives reviewers visibility into what the configuration would change.

After the change is merged, a CI job can run:

ant apply --yes .

The explicit . matters. Anthropic notes that a bare ant apply --yes only reconciles files already tracked by the lockfile and can skip a newly added resource file.

The documentation also says CI should commit the updated claude-lock.json, including after a partial failure, because an apply that fails midway may still have created resources and recorded state.

That is an important production detail: the lockfile is not just generated metadata that can always be discarded.

The authentication model is better than storing a long-lived API key

For CI, Anthropic recommends Workload Identity Federation instead of a stored API key.

The identity must resolve to the same organization and workspace recorded in the lockfile. ant apply refuses credentials for a different organization or workspace.

This is the right direction for production automation because CI credentials should be short-lived and scoped to the environment being changed. It also reduces the temptation to place a persistent Claude API key in repository secrets and forget about it.

Teams should still review the exact permissions granted to the CI identity. A safer authentication mechanism does not automatically make an over-privileged deployment job safe.

Four limits to understand before moving production agents

1. Existing Console resources are not automatically adopted

Anthropic says ant apply cannot simply adopt a resource created in the Console or with ant beta:agents create. If the lockfile does not know about the resource, applying a file that describes something similar can create another resource instead.

The documented migration path is to use the Console's Export as code capability, which includes a matching lockfile, and then manage the exported resources from there.

For teams with an existing fleet, this means migration should be treated as a controlled inventory exercise, not as "point ant apply at the repo and let it discover everything."

2. Drift can block an apply

If a managed resource is edited, archived, or deleted outside the repository flow, Anthropic says the plan can stop with a refusal to apply.

There is a --force option, but using force as a routine answer would defeat much of the value of having a reviewable source of intent.

A better operational rule is: once a resource is managed as code, discourage manual Console edits except for documented emergency procedures.

3. Pruning can be destructive

Deleting a configuration file does not immediately delete its remote resource. --prune removes resources that remain in the lockfile but are no longer declared.

Anthropic specifically notes that removing a skill is a deletion rather than an archive operation.

That means --prune belongs behind stronger review than an ordinary update. A team should know exactly which resources the plan will remove before allowing it on a protected branch.

4. Do not run concurrent applies

Anthropic says to run one apply at a time because nothing locks the lockfile.

For CI, that means the deployment workflow should use concurrency controls. Two jobs applying the same agent project at once can create state-management problems even if both changes looked valid independently.

This is a small sentence in the documentation with large operational consequences.

GitHub-hosted skills can be pinned to a commit

ant apply can reference a skill using a GitHub repository URL. Anthropic says the CLI downloads that directory and pins it to the resolved commit recorded in the lockfile.

It stays pinned until the team runs with --upgrade.

That is useful because an agent should not silently pull a different skill implementation every time it deploys. Pinning gives you reproducibility; explicit upgrading gives you a review point.

For private repositories, the documentation says a GITHUB_TOKEN can be provided for access.

Again, the operational value is not the URL syntax. It is that agent dependencies can become versioned dependencies rather than mutable external references.

Who should test ant apply now?

Teams building multiple Claude agents

If you already have several agents, environments, skills, and deployments, the reduction in configuration drift can be valuable.

A good first target is a non-critical internal agent whose current configuration is already well understood.

Platform and DevOps teams

This release is especially relevant if your organization wants agent changes to follow the same path as application changes: branch, pull request, automated checks, approval, merge, deployment.

It gives infrastructure teams a clearer object to govern than ad hoc scripts around the API.

Small experimental teams

If you have one prototype agent and no CI/CD process, ant apply may be more structure than you need today. The Console can still be faster for exploration.

The value rises when repeatability and shared ownership become more important than setup speed.

A low-risk rollout pattern

TowCue would not migrate every existing Claude resource at once.

Start with one bounded agent project:

Export or define the agent and its dependencies as repository files.
Commit the configuration and lockfile.
Add ant apply --dry-run . to pull requests.
Require a human to inspect the plan before merge.
Run ant apply --yes . only on the protected default branch.
Serialize applies with CI concurrency controls.
Use Workload Identity Federation rather than a long-lived key.
Keep --prune and --force out of the normal path unless a reviewer explicitly approves their effect.
Make the Console read-mostly for resources that are now managed from Git.
Test rollback and partial-failure handling before calling the workflow production-ready.

This turns the feature into an operating discipline rather than just a new command.

TowCue take

ant apply is one of the more important kinds of agent-platform update because it addresses operability, not model intelligence.

Agent systems are becoming complicated enough that prompts, skills, environments, memory, permissions, and deployment schedules need the same qualities teams already expect from software infrastructure:

version history, code review, reproducibility, explicit state, CI authentication, and controlled rollout.

That does not make agent deployments automatically safe. Anthropic's own documentation highlights meaningful edges around adoption, drift, pruning, partial failures, and concurrent applies.

But those limitations are also a sign that the category is maturing. The conversation is shifting from "how do I create an agent?" to "how do I operate a fleet of agents without losing control of what is deployed?"

For teams already beyond the prototype stage, that is the question worth paying attention to.

Anthropic ant apply turns Claude agents into resources as code: what changes for teams