Claude Managed Agents im Code-Review: Was ant apply wirklich ändert

Bei Claude Managed Agents gab es am 3. September 2026 eine handfeste Änderung für den Betrieb: Mit ant apply lassen sich Repository-Dateien nun in aktive Agenten, Umgebungen, Skills, Memory Stores und Deployments überführen. Der eigentliche Fortschritt liegt im Prozess: Agentenkonfigurationen können vor dem Einsatz in Produktion dasselbe Review wie Code durchlaufen.

Bei Claude Managed Agents wird Konfiguration zum prüfbaren Zustand

Claude Managed Agents ist das gehostete Agentensystem von Anthropic für lang laufende und asynchrone Aufgaben. Ein Agent legt Modell, Prompt, Tools und Skills fest. Eine Umgebung bestimmt, wo er ausgeführt wird. Über ein Deployment lässt sich der Agent nach Zeitplan starten.

Das ist etwas anderes als ein Subagent von Claude Code unter .claude/agents/. Die Änderung betrifft die Ressourcen hinter dem Managed-Agent-Service der Claude API.

Wer diese Ressourcen über die Console oder mit einzelnen API-Aufrufen anlegt, verteilt den relevanten Zustand auf zwei Orte. Im Remote-Dienst liegt die eigentliche Ressource; ein Skript, eine Dokumentation oder das Wissen eines Teammitglieds erklärt, wie sie dorthin gelangt ist. Bei einer Übergabe müssen beide Seiten wieder zusammengeführt werden.

ant apply macht das Repository dafür zuständig. Die Ressourcen werden in Markdown, YAML oder JSON beschrieben. Die CLI vergleicht die Dateien mit den Remote-Ressourcen, zeigt einen Plan an, holt eine Freigabe ein und setzt die Änderung anschließend um.

Damit stehen System-Prompt, Tool-Zugriff, Umgebung, Skill-Paket, Memory Store und Zeitplan gemeinsam in einem Pull Request. Das Review zeigt, was sich ändern wird, bevor eine Person oder ein CI-Job mit Deployment-Zugangsdaten den Produktivzustand anpasst.

Dieser Workflow richtet sich an Teams, die Managed Agents bereits in Betracht ziehen. Wer ausschließlich die Claude-App, Claude Code oder eine eigene Schleife auf Basis der Messages API nutzt, für dessen Setup ändert sich durch ant apply nichts.

Das Lockfile macht die Übergabe belastbar

Entscheidend ist nicht nur die Agentendefinition, sondern auch claude-lock.json.

Beim ersten erfolgreichen Apply wird dieses Lockfile in dem Verzeichnis angelegt, aus dem der Befehl ausgeführt wird. Deshalb sollte der Aufruf im Repository-Stammverzeichnis erfolgen und das Lockfile anschließend zusammen mit den Ressourcendateien eingecheckt werden.

Das Lockfile hält API-Origin, Organisation, Workspace und die Remote-ID fest, die aus jeder lokalen Datei entstanden ist. Zusätzlich speichert es einen lokalen und einen Remote-Hash. Der lokale Hash erkennt Änderungen an einer Datei. Der Remote-Hash erkennt, wenn eine Ressource über die Console oder einen anderen API-Weg verändert wurde.

Es ist Adressbuch und Beleg in einem. Die Ressourcendatei beschreibt den gewünschten Zustand. Das Lockfile dokumentiert, welche Live-Ressource zu dieser Datei gehört und wie beide Seiten nach dem letzten Apply aussahen.

Genau das vereinfacht eine Übergabe. Die nächste zuständige Person oder der nächste CI-Runner muss nicht erraten, welche Agenten-ID zu agents/reviewer.md gehört. Die Zuordnung steht im Lockfile, sodass dieselbe Ressource aktualisiert wird, statt ein Duplikat anzulegen.

Ressourcen dürfen über relative Pfade aufeinander verweisen, wo die API normalerweise eine ID verlangt. Apply ermittelt die Reihenfolge der Abhängigkeiten, erstellt oder aktualisiert die Ressourcen und setzt die tatsächlichen IDs ein. Ein Agent kann auf ein Skill-Verzeichnis zeigen. Ein Deployment kann auf Agent, Umgebung und Memory Store verweisen.

Verweise auf Agenten und Skills werden genau auf die Version fixiert, die in diesem Durchlauf angewendet wurde. Ein Skill aus einer GitHub-URL bleibt bis zum Einsatz von --upgrade an den ermittelten Commit gebunden. So bezieht sich das Review auf ein konkretes Ziel und nicht auf den jeweils aktuellen Stand an der Spitze eines veränderlichen Branches.

Wirtschaftlich zählt der Aufwand für Übergaben

ant apply macht den Betrieb von Agenten nicht kostenlos. Es verschiebt den Kostenblock.

Bisher entsteht Aufwand durch wiederholte Konfiguration, Prüfung und Übergabe. Im neuen Modell fallen Repository-Einrichtung, Pull-Request-Review, CI-Verantwortung und Lockfile-Pflege an. Ob das günstiger ist, hängt davon ab, wie häufig sich die Konfiguration ändert und an wie viele Stellen dieselbe Änderung gelangen muss.

Das folgende Rechenbeispiel ist ausdrücklich kein Benchmark und keine Sparzusage von Anthropic.

Angenommen, ein Team nimmt pro Monat vier Konfigurationsänderungen in drei Zielumgebungen vor. Jede manuelle Übergabe dauert pro Änderung und Umgebung 15 Minuten.

Der monatliche manuelle Aufwand beträgt:

4 changes × 3 environments × 15 minutes = 180 minutes

Nun wird angenommen, dass der Repository-Weg pro Änderung 30 Minuten Review sowie 10 Minuten für Apply und Prüfung in jeder Umgebung benötigt.

Der monatliche Repository-Aufwand beträgt:

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

Unter diesen Annahmen ist der Repository-Workflow monatlich 60 Minuten langsamer. Genau das ist das relevante Ergebnis, wenn die manuelle Übergabe ohnehin wenig kostet.

Der Break-even liegt vor Einrichtungs- und Wartungsaufwand bei 20 Minuten pro manueller Übergabe. Dauert die gemessene manuelle Übergabe 30 Minuten, steigt derselbe manuelle Weg auf 360 Minuten, während der Repository-Weg bei 240 Minuten bleibt. Die Differenz beträgt 120 Minuten – bleibt aber ein Tabellenwert, bis das Team den tatsächlichen Aufwand misst.

Neben diese Minuten gehört der interne Vollkostensatz. Hinzu kommen die einmalige Einrichtung und die laufenden Kosten für das Prüfen fehlgeschlagener Pläne, das Auflösen von Drift und die CI-Wartung. Das Tool lohnt sich, wenn diese Gesamtrechnung besser ausfällt als der bisherige Prozess – nicht, weil die Demo aufgeräumt wirkt.

Für wen sich dieser Workflow auszahlt

Plattformteams bündeln alles in einem Review

Die Plattformverantwortlichen eines Softwareunternehmens können einen Agenten samt Skills, Umgebung, Memory Store und geplantem Deployment in einem Pull Request bündeln. Im Review lässt sich die gesamte Betriebsänderung gemeinsam prüfen, statt eine Prompt-Datei mit Screenshots aus einer Remote-Console abzugleichen.

Der Nutzen ist Nachvollziehbarkeit: Eine zusammengeführte Änderung lässt sich mit dem Ressourcenplan und dem danach entstandenen Lockfile-Zustand verbinden.

Agenturen übergeben Kundenprojekte sauberer

Die technische Leitung einer Agentur kann die Dateien jedes Kunden zusammen mit dem Lockfile für dessen Organisation und Workspace verwalten. Übernimmt eine andere Person, bleibt die Zuordnung im Repository erhalten.

Das bedeutet bei der Übergabe weniger Rätselraten um die richtige Ressource. Ein Lockfile wird dadurch nicht zwischen Kunden übertragbar. Apply akzeptiert keine Zugangsdaten, die zu einer anderen Organisation oder einem anderen Workspace gehören – genau diese Trennung sollte eine Agentur beibehalten.

Betriebsteams bekommen einen klar benannten Deployment-Schritt

Ein Betriebsteam kann eine Änderung im Pull Request vorab prüfen und nach dem Merge das Verzeichnis auf dem Standard-Branch mit ant apply --yes . anwenden. Der abschließende Punkt ist wichtig: Ein Apply ohne Pfadangabe gleicht nur Ressourcen ab, die bereits im Lockfile erfasst sind, und kann eine neu hinzugefügte Datei übersehen.

Das Ergebnis ist ein wiederholbarer Deployment-Schritt. Zur Laufzeit braucht es dennoch genau eine zuständige Stelle, denn Apply sperrt das Lockfile nicht. Zwei gleichzeitig laufende Jobs können beim Schreiben desselben Zustands kollidieren.

Sicherheitsverantwortliche können Drift rechtzeitig stoppen

Der Remote-Hash kann eine Änderung in der Console sichtbar machen, bevor der Repository-Zustand sie überschreibt. Apply blockiert, wenn eine verwaltete Ressource außerhalb der Dateien bearbeitet, archiviert oder gelöscht wurde.

Dadurch wird eine bewusste Entscheidung erzwungen: Die Remote-Änderung wird untersucht und abgeglichen oder gezielt mit --force überschrieben. Teams, die Zero Data Retention oder die Abdeckung durch ein HIPAA Business Associate Agreement benötigen, sollten mit Managed Agents selbst noch warten, da der Dienst derzeit für beides nicht zugelassen ist.

Minimalbeispiel: KI-Agenten konfigurieren und anwenden

ant apply erfordert CLI 1.30.0 oder neuer. Der offizielle Schnellstart beschreibt die Installation über Homebrew und die Anmeldung im Browser.

1. 1

   CLI installieren und anmelden

   Die CLI wird installiert, die Version geprüft und anschließend die Anmeldung gestartet:

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

2. 2

   Eine Agentendatei anlegen

   Die dokumentierte Minimaldefinition wird in agents/summarizer.md gespeichert:

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

3. 3

   Einmalig aus dem Repository-Stammverzeichnis anwenden

   Der dokumentierte Befehl für eine einzelne Datei lautet:

   ant apply agents/summarizer.md

   Der Plan wird geprüft und bei Bedarf die Detailansicht für den Vergleich einzelner Felder geöffnet, bevor die Freigabe erfolgt. Nach dem erfolgreichen Lauf ist der Remote-Agent angelegt und claude-lock.json liegt neben dem Projekt.

4. 4

   Vorschau und Anwendung auf getrennte Jobs verteilen

   In Pull Requests kommt der dokumentierte Vorschaubefehl zum Einsatz:

   ant apply --dry-run .

   Nach dem Merge wird der Deployment-Job serialisiert und auf das benannte Verzeichnis angewendet:

   ant apply --yes .

   Das aktualisierte Lockfile sollte am Ende eingecheckt werden – auch nach einem teilweise fehlgeschlagenen Apply. Ein Teillauf kann bereits Ressourcen erstellt und im Lockfile vermerkt haben.

Die Statuscode-Falle in der CI

Das ist relevant, weil Remote-Drift zum normalen Betriebszustand gehört. Zwischen Review und Merge kann jemand einen Agenten in der Console bearbeiten. Die Vorschau sollte daraus eine sichtbare Entscheidung machen, statt den Pull Request grün zu markieren und den Fehler erst im Deployment-Job aufzudecken.

Für den Apply-Job empfiehlt sich Workload Identity Federation statt eines gespeicherten API-Schlüssels. Der Job muss an die im Lockfile hinterlegte Organisation und den Workspace gebunden bleiben; außerdem darf immer nur ein Apply gleichzeitig laufen.

Die Grenzen des Ansatzes

Dateibasierte Konfiguration bedeutet nicht, dass jede Remote-Ressource verwaltbar wird.

ant apply kann keinen Agenten übernehmen, der unabhängig in der Console oder mit ant beta:agents create angelegt wurde. Stammen Dateien und Lockfile aus der Console-Funktion Export as code, kann Apply diese exportierten Ressourcen aktualisieren. Andernfalls erzeugt eine passende Datei eine weitere Ressource.

Auch beim Löschen verhält sich das Tool bewusst zurückhaltend. Wird eine Datei entfernt, bleibt die Remote-Ressource bestehen und es erscheint eine Warnung. --prune entfernt die Remote-Ressource. Das Umbenennen einer Datei deklariert dagegen eine neue Ressource und lässt die alte bestehen, bis sie mit Prune entfernt wird.

Damit sind --force und --prune Produktionskontrollen und keine bequemen Aufräumbefehle. Beide gehören hinter ein Review. Ein automatisches Prune nach einer fehlerhaften Umbenennung kann genau die Ressource entfernen, die das Deployment noch erwartet.

Auch das Lockfile wird zum gemeinsam genutzten Betriebszustand. Es gehört nach jedem Apply ins Repository, der zugehörige Branch muss geschützt sein und Schreibzugriffe müssen serialisiert werden. Scheitert ein Lauf teilweise, darf die Lockfile-Änderung nicht allein deshalb verworfen werden, weil der Job rot ist.

Schließlich handelt es sich weiterhin um einen Beta-Dienst. Claude Managed Agents ist für Claude-API-Konten standardmäßig aktiviert. Für Teams mit Anforderungen an Zero Data Retention oder einen HIPAA BAA bleibt jedoch eine Einschränkung auf Produktebene bestehen, die sich durch Repository-Reviews nicht lösen lässt.

Was am Montag konkret zu tun ist

Ein Einstieg noch in dieser Woche lohnt sich, wenn mehrere Personen dieselben Ressourcen von Managed Agents ändern, dieselbe Konfiguration mehrere Umgebungen durchläuft oder geplante Deployments einen klaren Verantwortlichen und eine nachvollziehbare Review-Historie benötigen.

Abwarten ist sinnvoll, wenn eine Person allein ein stabiles Experiment betreut, die gemessenen Übergabekosten unter den neuen Review-Kosten liegen oder die Datenrichtlinie Zero Data Retention beziehungsweise HIPAA-BAA-Abdeckung verlangt.

Ohne Auswirkungen bleibt die Änderung, wenn Agenten ausschließlich über Claude Code, die Claude-App oder eine eigene Messages-API-Schleife ohne Ressourcen von Claude Managed Agents laufen.

Am Montag beginnt der Test mit einem einzelnen Agenten außerhalb der Produktion. Seine Definition und sein Lockfile durchlaufen einen echten Pull Request. Dabei werden die Minuten für die aktuelle Übergabe und den geprüften Weg erfasst. Anschließend wird in dieser sicheren Umgebung eine Remote-Änderung erzeugt und kontrolliert, ob die Pull-Request-Prüfung einen blockierten Plan nicht durchwinkt. Erst dann gehört ant apply --yes . in den Ablauf nach einem Merge.

Weitere praxisnahe Analysen zu KI-Workflows gibt es im Newsletter.