Den Knopf, den ich gebaut hatte, gab ich dem Agent
Erst habe ich mir selbst einen Destroy-Button gebaut, um Agents loszuwerden. Dann habe ich denselben Knopf einem Agent in die Hand gegeben — als Tool. Eine Notiz aus dem Bauen eines Agents, der andere Agents anlegt, mit einem Modell-Tier pro Aufgabe ausstattet und nach getaner Arbeit wieder wegräumt.
Vor ein paar Wochen habe ich einen Destroy-Button gebaut, um einen Agent loszuwerden, ohne mich als root einzuloggen. Das war Arbeit, die ich für mich gemacht habe — eine Danger-Zone in der UI, ein Knopf, eine Bestätigung.
Jetzt gibt es denselben Knopf noch einmal. Diesmal hat ihn nicht ein Mensch in der Hand, sondern ein Agent. Als Tool.
Was der Agent jetzt kann
Es gibt zwei neue Tools im Agent-Runtime: agent.spawn und agent.destroy. Das erste legt einen neuen Agent an — Name, optional ein Recipe, ein System-Prompt, und vor allem: ein Modell und ein reasoning_effort für genau diesen Agent. Das zweite räumt ihn wieder weg.
Der Agent, der diese Tools benutzt, ist ein Orchestrator. Er zieht Aufgaben aus einem Backlog, schätzt sie ein, und spawnt sich für die Arbeit eigene Worker. Einen einfachen Task gibt er einem kleinen Modell mit wenig reasoning_effort. Einen schweren einem großen mit viel. Wenn der Worker fertig ist und sein Ergebnis abgeliefert hat, ruft der Orchestrator agent.destroy auf, und der Worker ist weg.
Kein Worker, der idle herumsteht und auf den nächsten Task wartet. Jeder lebt für genau eine Aufgabe.
Warum ephemer
Der naheliegende Reflex bei Worker-Agents ist, sie am Leben zu halten. Einmal hochgefahren, warten sie auf den nächsten Job — spart das erneute Anlegen. Ich habe es umgekehrt gebaut: Worker werden pro Task angelegt und nach dem Task zerstört.
Das hat zwei Gründe. Der erste ist Kosten: ein Worker verbraucht nur etwas, solange er arbeitet. Der zweite ist Sauberkeit. Ein idle Worker ist ein Prozess mit Zustand, den ich später nicht mehr verstehe — war er schon mal beschäftigt, hängt er, wartet er auf etwas? Ein ephemerer Worker hat keine Geschichte. Er wird angelegt, tut eine Sache, und verschwindet. Wenn etwas schiefgeht, gibt es kein „seit wann ist der so" zu klären.
Das Tiering pro Agent ist die andere Hälfte. Vorher lief jeder Agent auf demselben Modell, weil es nur ein globales gab. Jetzt entscheidet der, der den Worker anlegt, womit der Worker läuft — und das ist meistens nicht das größte Modell, sondern das, das für diese eine Aufgabe reicht.
Was das eigentlich ist
Es ist derselbe Knopf wie vorher, eine Ebene höher. Als ich den Destroy-Button gebaut habe, war das Eingeständnis: viele Agents zu verwalten ist kein Prompting-Problem mehr, sondern ein Ops-Problem. agent.spawn und agent.destroy sind die Konsequenz daraus. Wenn Anlegen und Wegräumen die eigentliche Arbeit sind, dann sind das Operationen — und Operationen kann ich einem Agent als Tool geben, genauso wie bash oder http.
Das verschiebt eine Grenze, über die man kurz nachdenken sollte. Ein Agent kann jetzt einen anderen Agent zerstören. Deshalb hängt agent.destroy nicht frei in der Luft, sondern an einem Scope — troop:destroy-agent — den der aufrufende Agent erst gegen sein eigenes Token eintauschen muss. Nicht jeder Agent darf jeden anderen wegräumen. Es ist dieselbe Delegation wie überall im Protokoll: der Agent handelt mit einer Vollmacht, nicht mit Allmacht.
Eine Lücke ist noch offen, und ich schreibe sie hin, weil sie ehrlich dazugehört: das lokale Wegräumen entfernt den Worker vom Host, aber die Identität beim IdP bleibt vorerst stehen. Wer denselben Namen sofort wiederverwenden will, läuft in einen Konflikt. Das ist ein Folge-Task, kein gelöstes Problem. VERIFY: Status IdP-Hard-Delete prüfen, bevor publiziert wird
Schluss
Ich habe mir einen Knopf gebaut, um Agents loszuwerden, und dachte, das sei das Ende der Geschichte. Es war der Anfang. Sobald Anlegen und Wegräumen Operationen sind, gehören sie dorthin, wo die anderen Operationen sind: in die Tool-Liste. Der Unterschied zwischen mir und dem Orchestrator-Agent ist am Ende nur, wessen Token den Scope hält.