ant apply turns your Claude agents into reviewable code

Agents as code stopped being a pattern you improvise and became a command. Anthropic shipped ant apply in version 1.30.0 of its CLI on September 3. You write an agent as a Markdown file, run one command, approve the plan it prints, and commit the lockfile it writes. The next run updates the same agent instead of creating a second one.

What actually happened

Per the CLI documentation, ant apply manages five resource kinds from files in your repository: agents, environments, skills, memory stores, and deployments. An agent is a Markdown file under agents/ — frontmatter is the config, the body is the system prompt. An environment or memory store is YAML. A skill is a directory with a SKILL.md. A deployment is Markdown whose frontmatter carries a cron expression and whose prose becomes the message that starts each scheduled session.

The mechanics are borrowed straight from Terraform, and that is the point. The command prints a plan, waits for y, then writes claude-lock.json recording each resource's ID plus two hashes — what was last sent, and what the API returned. That is how a later run notices you edited a file, or that somebody edited the agent in the Console instead. When it detects drift, the plan ends with This plan cannot be applied: and the command exits refusing to apply. --force overrides it.

Resources reference each other by relative path. An agent lists ../skills/pr-summary; a coordinator lists ./reviewer.md; a deployment names its agent, environment, and memory store by path. ant apply resolves dependency order and substitutes real IDs. Skills can also point at a GitHub URL, pinned to a resolved commit until you pass --upgrade.

For CI, the documented shape is ant apply --dry-run . on pull requests and ant apply --yes . on the default branch after merge, authenticating with Workload Identity Federation rather than a stored key. ant apply refuses credentials that resolve to a different organization or workspace than the lockfile records.

Why agents as code matters for your business

Most teams we meet have their agent configuration in a web console. One person edited the prompt in March, nobody knows why, and there is no diff. That is not a tooling gap — it is an outage waiting for the person who made the edit to leave.

Put the prompt in the repo and the whole problem collapses into problems you already solved. A prompt change becomes a pull request. A bad change becomes a revert. Staging and production become two lockfiles. Who changed what becomes git log.

Two caveats worth planning around. ant apply cannot adopt an agent you already created in the Console — applying a file that describes it creates a second one, so migrate deliberately. And renaming a file declares a new resource and leaves the old one running until you --prune. Both are the kind of thing you find out once, in production, if nobody read the docs.

This is also a portability signal. The files are yours and the format is plain Markdown and YAML. The lockfile is the only Anthropic-shaped artifact in the tree.

Sources: Manage resources as code with ant apply, Claude Platform release notes.