Verwaltete Agenten unterstehen jetzt dem Harness

Um vier Uhr nachmittags öffnet die Claude-Code-Session eines Entwicklers eine Arbeitssitzung auf der Billing API, um Planwechsel anteilig abzurechnen. Zwanzig Minuten später, während diese Sitzung noch arbeitet, übernimmt ein geplanter Archyl-Run mit dem Profil backend-fixer ein Ticket zur Rundung von Rechnungen, das ebenfalls in der Billing API liegt.

Bis diese Woche hat der geplante Run Folgendes getan. Er hat seine eigene Arbeitssitzung geöffnet, wie verwaltete Runs es schon taten. Das Preflight-Gate hat warn zurückgegeben, mit der Begründung 1 target element(s) are being worked on by other active sessions — coordinate before changing them. Dieses Urteil erschien im Ereignis-Feed des Runs. Dann ist der Run trotzdem gestartet, weil nichts auf das Urteil reagiert hat und niemand einen geplanten Run beobachtet hat, mit dem man sich hätte abstimmen können.

Ich sage es lieber offen: Bei gehosteten Runs war die Hülle größtenteils Kosmetik. Das Gate wurde angezeigt und ignoriert. Die Dateien, die der Agent geändert hat, wurden nie seiner Sitzung zugeordnet, also landete Gedächtnis auf den Elementen, die der Aufgabentext zufällig erwähnte. Und die Sitzung wurde mit einer einzeiligen Zusammenfassung geschlossen, aus der der nächste Agent kaum etwas lernen konnte.

Das hat sich diese Woche geändert. Das Harness steuert jetzt verwaltete Runs, und gehostete Runs und lokale Coding-Agenten stimmen sich auf demselben Modell ab.

Einen Agenten laufen zu lassen wird zum einfachen Teil

Drei der größten Namen der Branche bieten inzwischen einen gehosteten Ort an, an dem Agenten laufen. Die Dokumentation von Anthropic beschreibt Claude Managed Agents als "ein vorgefertigtes, konfigurierbares Agent-Harness, das auf verwalteter Infrastruktur läuft", mit Sandboxes in der Cloud oder selbst gehostet, persistenten Sessions und geplanten Runs per Cron. Die Agents API von OpenAI, am 10. September als öffentliche Beta angekündigt, führt den Agent-Loop auf der Infrastruktur von OpenAI aus und übernimmt "Orchestrierung, lang laufende Sessions und Kontextverwaltung". Cursor Projects, am selben Tag angekündigt, setzt einen Koordinator-Agenten auf eine eigene Cloud-Maschine, der an Subagenten delegiert und nach Zeitplan laufen oder deinen Pull Requests folgen kann.

Das sind gute Produkte, und sie zeigen in dieselbe Richtung: Sandbox, Tool-Loop, Sessions und Zeitpläne werden zu etwas, das man aus einer Liste auswählt.

Was eine Runtime von sich aus nicht wissen kann, ist dein System. Zu welchem Container der Rechnungscode gehört. Wem er gehört. Der Contract, auf den sich seine Konsumenten verlassen. Die Entscheidung, die eine Grenze bewusst gezogen hat. Und der Teil, auf den es ankommt, wenn niemand hinschaut: welcher andere Agent, auch einer, den diese Runtime nicht gestartet hat, gerade an welchem Teil davon arbeitet.

Dieses Wissen kann nicht in einer Runtime liegen, weil deine Agenten nicht alle in einer laufen. Manche laufen auf einem Laptop, manche in der CI, manche in einem gehosteten Worker. Deshalb sehen wir es so: deine Runtime, unsere Architektur. Egal, was den Agenten ausführt, das Modell, dem er untersteht, ist dasselbe.

Archyls eigene Managed Agent Runs, im April gestartet, sind eine Runtime unter diesen. Diese Woche haben sie angefangen, sich auch so zu verhalten. Sie können einen Run auch live verfolgen und steuern.

Ein Run kann jetzt abgelehnt werden, mit Begründung

Koordination ist opt-in. Jedes Agentenprofil hat unter Koordination eine neue Einstellung, Arbeit anderer Agenten berücksichtigen, standardmäßig aus. Ist sie aktiv, öffnet der Run seine Arbeitssitzung exklusiv, und das Urteil des Gates entscheidet, was als Nächstes passiert.

Hält ein anderer Agent einen Lease auf dieselben Elemente, wird der Run abgelehnt, ob dieser Agent nun Claude Code auf dem Laptop von jemandem ist oder ein anderer verwalteter Run. Der Run endet, bevor irgendetwas geklont wird, das Gate-Event lautet Ausführung abgelehnt, und die Begründung nennt, wer dort woran arbeitet. Für den Nachmittag von oben:

session denied by preflight gate: "Billing API" is being worked on by
claude-code/vincent (add proration to plan changes)

Das Format ist echt, die Aufgabe ein Beispiel. Wer den Run am Morgen liest, weiß genau, mit wem zu reden ist.

Warnt das Gate nur, etwa weil eine Leitplanke der Stufe Error auf die Aufgabe zutrifft, startet der Run weder, noch schlägt er fehl. Er wartet im Status Wartet auf Freigabe, ohne einen der gleichzeitigen Run-Slots deiner Organisation zu belegen. Die Run-Seite listet die Gründe auf, mit Freigeben und starten und Ausführung abbrechen.

Freigeben winkt das alte Urteil nicht einfach durch. Das Gate wird erneut ausgewertet: Hat ein lokaler Agent einen Lease auf diese Elemente genommen, während der Run gewartet hat, wird der freigegebene Run trotzdem abgelehnt. Ein Run, den innerhalb von 24 Stunden niemand freigibt, wird abgebrochen.

Warum ein wartender Run nichts hält

Während ein Run wartet, wird seine Sitzung verworfen. Die Sitzung, die die Warnung ausgelöst hat, wird abgebrochen, ihre Leases gehen mit ihr, und die Freigabe öffnet eine neue. Die Leases zu behalten klänge vorsichtiger und wäre schlechter: Ein Run, den nie jemand freigibt, würde jeden anderen Agenten einen Tag lang von diesen Elementen fernhalten und jedem von ihnen sagen, dort arbeite etwas, obwohl dort nichts arbeitet.

Das folgt einer Linie, die wir im August gezogen haben. Leases sind Hinweise, keine Sperren. Exklusivität ist etwas, das ein Profil anfordert, nicht etwas, das die Plattform erzwingt, und ein Run, der auf einen Menschen wartet, beansprucht nichts.

Der Guard ist in den Worker gewandert

Die Sitzung deckt die Absicht ab. Der Guard deckt ab, was geschrieben wird. Lokale Agenten haben ihn seit August als Claude-Code-Hook, und verwaltete Runs haben jetzt dieselbe Prüfung im Worker.

Hat das Projekt ein verknüpftes Repository, wird jeder write_file- und edit_file-Aufruf des Agenten gegen die Konformitätsregeln des Projekts geprüft, bevor die Änderung übernommen wird. Ein kritischer Verstoß lehnt den Schreibvorgang ab, und der Agent liest, welche Regel betroffen ist und warum:

blocked by Archyl Guard: 1 critical architecture violation(s) in
backend/internal/adapter/http/handlers/invoice.go. Change the content so it
conforms, then write again:
- [critical] No direct database access from HTTP handlers — move the query behind a service

Der Agent verschiebt die Abfrage und schreibt erneut. Ein Verstoß mit hoher Schwere lässt den Schreibvorgang mit einer Warnung durch. Schlägt die Prüfung selbst fehl oder läuft in einen Timeout, geht der Schreibvorgang durch: Der Guard blockiert einen Agenten nie wegen eigener Fehler, denn eine Governance-Prüfung, die genau die Arbeit kaputt macht, über die sie wacht, wird abgeschaltet.

Jede Prüfung trägt außerdem die Session-ID, die die Datei der Sitzung des Runs zuordnet, während der Agent arbeitet. Das wird zwei Abschnitte weiter wichtig.

Der Agent kennt seine Sitzung, aber sie gehört ihm nicht

Der Prompt des Runs nennt jetzt seine Sitzung und sagt dem Agenten, dass die Plattform sie geöffnet hat und schließen wird, "es gibt also keine Session-Tools aufzurufen". Der Agent kann keine zweite Sitzung öffnen und diese nicht vorzeitig beenden. Der Lebenszyklus gehört der Plattform, der einzigen Partei, die weiß, wann ein Run zu Ende ist.

Was dem Agenten gehört, ist sein Bericht über die Arbeit. Kurz vor dem Ende ruft er einmal report_outcome auf, mit einer ehrlichen Zusammenfassung, den Entscheidungen, die einen ADR wert sind, Follow-ups für liegengebliebene Arbeit und den Gedächtniseinträgen aus dem Briefing, auf die er sich gestützt hat. Die Beschreibung des Tools sagt ihm, situative Befunde aus den Entscheidungen herauszuhalten, weil Entscheidungen künftigen Sitzungen wieder vorgelegt werden und eine Debugging-Notiz niemanden binden sollte.

Das Ergebnis landet dort, wo die Arbeit gelandet ist

Wenn der Run endet, ordnet Archyl zuerst die Dateien, die der Run geändert hat, der Sitzung zu. Das schließt die unauffälligste der drei Lücken. Die Elemente, auf die eine Sitzung Leases nimmt, werden aus dem Aufgabentext abgeleitet, und Aufgabentext ist eine Vermutung. Die geänderten Dateien sind das, was passiert ist. Gedächtnis geht jetzt an die Elemente, die echte Arbeit berührt hat, nicht an alles, was das Ticket erwähnt hat.

Dann schließt Archyl die Sitzung, speichert die Zusammenfassung als Gedächtnis an diesen Elementen und schreibt den Gedächtniseinträgen gut, die der Agent nach eigener Aussage genutzt hat. Genau aus diesem Signal lernt das Ranking des Gedächtnisses.

Entscheidungen werden nur festgehalten, wenn der Run erfolgreich war. Sie werden zu Projektgedächtnis und öffnen einen Architecture Change Request als Draft, damit ein Mensch prüft, wie das Modell nachziehen soll. Ein fehlgeschlagener Run behält seine Zusammenfassung und Follow-ups, also das, was der nächste Versuch braucht, hält aber keine Entscheidungen fest. Arbeit, die nicht fertig geworden ist, hat nichts, wofür sie einstehen könnte.

Die Run-Seite zeigt all das in einer Karte Ergebnis der Arbeitssitzung: Zusammenfassung, Entscheidungen, Follow-ups, die berührten Elemente, die zitierten Gedächtniseinträge und ein Link zum Change Request. Ein Element, das eine andere Sitzung hält, ist als Von einer anderen Arbeitssitzung belegt markiert, damit ein Run, der Code innerhalb des Leases eines anderen bearbeitet hat, nicht unbemerkt bleibt.

Zwei Arten von Agenten, ein Modell

Das ist das Stück, nach dem Viele Agenten, eine Architektur gegriffen hat: Koordination zwischen Agenten, die sich nie einen Prozess teilen, in beide Richtungen.

Ein verwalteter Run öffnet seine Sitzung als managed-agent/<profile name>. Dreh die Szene vom Anfang dieses Posts um: Der geplante Run ist in der Billing API, als ein Entwickler dort Claude Code startet. Dessen Briefing führt den Run jetzt als Konflikt:

- **Conflicts** (someone else is already working here):
  - Billing API — held by managed-agent/backend-fixer: fix rounding on prorated invoices

Der lokale Agent wird angewiesen, sich abzustimmen, bevor er dieses Element ändert, die Fleet-Konsole zeigt beide Sitzungen, und wer von beiden fertig wird, hinterlässt Gedächtnis, das der andere beim nächsten Mal liest.

Diese Woche außerdem ausgeliefert

Kurz, weil der Rest darauf aufbaut. Profile bringen jetzt eingebaute Skills und Tool-Allowlists mit, sodass ein Read-only-Reviewer auf read_file, list_* und get_* beschränkt werden kann. Worker-Heartbeats erkennen tote Runs und räumen sie ab, der API-Key jedes Runs wird widerrufen, wenn der Run endet, und ein fehlgeschlagener Run veröffentlicht seine Arbeit trotzdem als Draft-Pull-Request. Runs laufen immer im eigenen Worker von Archyl, mit dem KI-Anbieter deiner Organisation, wenn Bring-your-own aktiviert ist.

Was es nicht tut

Koordination sieht nur Agenten, die das Harness nutzen. Ein Lease existiert, weil ein Agent eine Sitzung geöffnet hat. Ein Agent, der das Repository ohne Sitzung bearbeitet, ist für das Gate unsichtbar, und ein Run, der die Arbeit anderer Agenten berücksichtigt, startet direkt neben ihm.

Der Worker führt deine Tests nicht aus. Er hat Datei-Tools für den Workspace (lesen, schreiben, bearbeiten, auflisten, grep) und keine Shell. Er kann das Projekt nicht bauen und die Testsuite nicht ausführen, eine saubere Ergebniskarte bedeutet also, dass die Schreibvorgänge den Guard passiert haben, nicht dass der Code kompiliert. Diesen Job macht weiterhin die CI.

Die Entscheidungen eines Agenten sind ungeprüft. Eine Entscheidung in der Ergebniskarte ist eine Behauptung des Agenten, bis jemand den Change Request prüft. Dieses Review ist der eigentliche Zweck, keine Formalität.

Der Guard braucht etwas, wogegen er prüfen kann. Ohne verknüpftes Repository gibt es keine Schreibprüfung, und ein leerer Satz an Konformitätsregeln lässt jeden Schreibvorgang durch.

Wo du anfängst

Nimm das eine Profil, das nach Zeitplan an Code arbeitet, den Menschen auch von Hand ändern, und schalte Arbeit anderer Agenten berücksichtigen unter Koordination ein. Lass die anderen, wie sie sind.

Lehnt es einen Run ab, nennt die Begründung den Agenten und die Aufgabe, die sich mit ihm überschnitten hat. Bisher wäre diese Überschneidung durchgegangen, ohne dass irgendjemand davon erfahren hätte.

Managed Agent Runs, Arbeitssitzungen, der Guard und das Gedächtnis sind Teil von archyl. Jede oben genannte Einstellung steht in der Dokumentation zu Managed Agent Runs, und die lokale Seite im Harness-Leitfaden. Weiterlesen: Viele Agenten, eine Architektur, Arbeitssitzungen für Coding-Agenten, Memory für KI-Coding-Agenten und der Start der Managed Agent Runs.