Claude Managed Agents Bring Config Changes Into Review

Claude Managed Agents got a practical operating change on September 3, 2026: ant apply can now turn repository files into live agents, environments, skills, memory stores, and deployments. The real shift is that agent configuration can pass through the same review as code before it reaches production.

The change is reviewable state, not another CLI shortcut

Claude Managed Agents is Anthropic's hosted agent system for long-running and asynchronous work. An agent defines the model, prompt, tools, and skills. An environment defines where it runs. A deployment can put that agent on a schedule.

That is separate from a Claude Code subagent living in .claude/agents/. This change is about the resources behind the Claude API's managed agent service.

If a team creates those resources through the Console or one-off API calls, the useful state lives in two places. The remote service has the actual resource, while a script, document, or teammate's memory explains how it got there. A handover has to reconnect the two.

ant apply gives the repository that job. You describe the resources as Markdown, YAML, or JSON. The CLI compares the files with the remote resources, prints a plan, asks for approval, and then applies the change.

That puts the system prompt, tool access, environment, skill bundle, memory store, and schedule inside a pull request. A reviewer can see what will change before the person or CI job with deployment credentials changes it.

This is a workflow article for teams already considering Managed Agents. If you only use the Claude app, Claude Code, or your own loop on the Messages API, ant apply does not change your setup.

The lockfile is the handoff

The important file isn't only the agent definition. It is claude-lock.json.

The first successful apply writes that lockfile in the directory where you run the command. Run it from the repository root, then commit the lockfile with the resource files.

The lockfile records the API origin, organization, workspace, and the remote ID created from each local file. It also stores a local hash and a remote hash. The local hash notices that a file changed. The remote hash notices that somebody changed the resource through the Console or another API path.

Think of it as an address book joined to a receipt. The resource file says what you want. The lockfile says which live object that file owns and what both sides looked like after the last apply.

That is what makes a handover cleaner. The next operator or CI runner does not guess which agent ID belongs to agents/reviewer.md. It reads the mapping and updates the same resource instead of creating another copy.

Resources can refer to one another by relative path wherever the API would normally need an ID. Apply works out the dependency order, creates or updates each resource, and fills in the real IDs. An agent can point to a skill directory. A deployment can point to its agent, environment, and memory store.

Agent and skill references are pinned to the version applied in that run. A skill pulled from a GitHub URL is pinned to the resolved commit until you use --upgrade. That gives review a concrete target instead of whatever happens to sit at the end of a moving branch.

The business math is handoff labor

ant apply does not make agent work free. It moves the budget line.

The old line is repeated configuration, verification, and handoff work. The new line is repository setup, pull-request review, CI ownership, and lockfile maintenance. Whether that is cheaper depends on how often configuration changes and how many places need the same change.

Here is a labeled example, not a benchmark and not an Anthropic savings claim.

Assume a team makes four configuration changes per month across three target environments. A manual handoff takes 15 minutes for each change in each environment.

Manual monthly work is:

4 changes × 3 environments × 15 minutes = 180 minutes

Now assume the repository path needs 30 minutes of review for each change, plus 10 minutes to apply and check each environment.

Repository monthly work is:

4 changes × (30 review minutes + 3 × 10 apply minutes) = 240 minutes

At those inputs, the repository workflow is 60 minutes slower each month. That is the useful answer if the manual handoff is already cheap.

The break-even point is 20 minutes per manual handoff before setup and maintenance. If the measured manual handoff takes 30 minutes, the same manual path becomes 360 minutes while the repository path stays at 240 minutes. The difference is 120 minutes, but it is still only a spreadsheet result until your team measures the work.

Put your loaded labor rate beside those minutes. Then add the one-time setup and the recurring cost of reviewing failed plans, resolving drift, and maintaining CI. The tool earns its place when that full number beats the process you have, not when the demo looks tidy.

Who gets value from this workflow

A platform team gets one review surface

A platform lead at a software company can put an agent, its skills, its environment, its memory store, and its scheduled deployment into one pull request. Reviewers can inspect the whole operating change together instead of comparing a prompt file with screenshots from a remote console.

The payoff is traceability. The team can point from a merged change to the resource plan and the lockfile state that followed it.

An agency gets a cleaner client handover

An agency technical lead can keep each client's files with the lockfile for that client's organization and workspace. When another operator takes over, the mapping travels with the repository.

The payoff is fewer identity guesses during handover. It does not make one lockfile portable across clients. Apply refuses credentials that resolve to a different organization or workspace, which is exactly the boundary the agency should keep.

An operations team gets a named deployment step

An operations lead can preview a change on a pull request and apply the merged directory on the default branch with ant apply --yes .. The final dot matters because a bare apply reconciles only resources already tracked in the lockfile and can miss a newly added file.

The payoff is a repeatable deployment step. It still needs a single owner at runtime because apply does not lock the lockfile. Two concurrent jobs can race over the same state.

A security lead gets a drift stop

A security lead can use the remote hash to surface a Console edit before repository state overwrites it. Apply blocks when a managed resource was edited, archived, or deleted outside the files.

The payoff is an explicit decision. Investigate and reconcile the remote change, or use --force to overwrite it deliberately. Teams that require Zero Data Retention or HIPAA Business Associate Agreement coverage should wait on Managed Agents itself, because the service is not currently eligible for either.

A minimal repository you can apply

ant apply requires CLI 1.30.0 or later. The official quickstart documents Homebrew installation and browser-based login.

1. 1

   Install and authenticate

   Install the CLI, confirm the version, and sign in:

   brew install anthropics/tap/ant
   ant --version
   ant auth login

2. 2

   Create one agent file

   Create agents/summarizer.md with the documented minimal definition:

   ---
   name: Summarizer
   model: claude-opus-5
   tools:
     - type: agent_toolset_20260401
   ---
   
   You are a helpful assistant that writes concise summaries.

3. 3

   Apply it once from the repository root

   Run the documented single-file command:

   ant apply agents/summarizer.md

   Review the plan, ask for details if you need the field-by-field diff, then approve it. The successful run creates the remote agent and writes claude-lock.json beside your project.

4. 4

   Put preview and apply in different jobs

   Use the documented preview command on pull requests:

   ant apply --dry-run .

   After merge, serialize the deployment job and apply the named directory:

   ant apply --yes .

   Commit the updated lockfile at the end, including after a partial apply failure, because the partial run can already have created resources and recorded them.

The CI status-code catch

This matters because remote drift is normal operating state. Somebody can edit an agent in the Console between review and merge. The preview should turn that into a visible decision, not a green box that the deployment job discovers later.

Use Workload Identity Federation for the apply job instead of a stored API key. Keep the job tied to the organization and workspace recorded in the lockfile, and allow only one apply at a time.

The honest limits

Files as code do not make every remote resource manageable.

ant apply cannot adopt an agent that was independently created in the Console or with ant beta:agents create. If the Console's Export as code flow produced the files and lockfile, apply can update those exported resources. Otherwise, applying a matching file creates another resource.

Deletion is also conservative. Removing a file leaves the remote resource in place and prints a warning. --prune removes the remote resource, while renaming a file declares a new one and leaves the old one until you prune it.

That makes --force and --prune production controls, not cleanup conveniences. Put both behind review. A bad rename followed by an automatic prune can remove the resource your deployment still expects.

The lockfile also becomes shared operational state. Commit it after every apply, protect its branch, and serialize writers. If a run fails partway, do not throw the lockfile change away just because the job is red.

Finally, this is still a beta service. Claude Managed Agents is enabled by default for Claude API accounts, but teams with Zero Data Retention or HIPAA BAA requirements have a product-level blocker that repository review does not solve.

What to do Monday

Act this week if more than one person changes the same Managed Agents resources, if the same configuration moves across environments, or if scheduled deployments need an owner and a review trail.

Wait if one operator owns a stable experiment, the measured handoff cost is lower than the new review cost, or your data policy requires Zero Data Retention or HIPAA BAA coverage.

You are unaffected if your agents run only through Claude Code, the Claude app, or a custom Messages API loop without Claude Managed Agents resources.

On Monday, pick one non-production agent. Put its definition and lockfile through a real pull request. Record the minutes for the current handoff and the reviewed path. Then create a remote edit in that safe environment and prove that your pull-request check treats the blocked plan as blocked. Only after that should ant apply --yes . sit behind a merge.

Get the next practical AI workflow breakdown in the newsletter.