Was die Plattformen um Agenten herum liefern, was sie offenlassen und wo der Prüfpunkt hingehört.

Anthropic beschreibt, was in mehreren Unternehmensprojekten passiert ist: Jedes Team baute seinen eigenen Subagenten, die Architektur wurde zur Kopie des Organigramms, und jeder fügte dem Systemprompt einen Satz hinzu. Ein einzelner Agent mit Skills schnitt dort häufig besser ab, oft auch günstiger und schneller; bei einem Kunden lief er rund doppelt so schnell. Subagenten bleiben für drei Fälle: messbar zu viel Kontext, parallele Arbeit, Probleme bei der Werkzeugwahl. Der wichtigste Satz ist für mich organisatorisch: Ein kleines zentrales Team verantwortet Systemprompt und Qualität von Anfang bis Ende, die Fachteams liefern Skills und Werkzeuge zu. Das ist eine Frage der Entscheidungsrechte, bevor es eine der Architektur ist. Anthropic verkauft die Plattform dazu, das sollte man mitlesen.

Mit der Code-API legen Agenten in Slack eigene Code-Kanäle an: Der Agent holt die richtigen Leute und Dateien dazu, meldet seinen Fortschritt und archiviert den Kanal am Ende. Alle sehen, was der Agent tut und wer es freigegeben hat, und der Agent erbt die Rechte des Kanals, in dem er arbeitet. Der entscheidende Satz ist leiser: Eine Person „kann“ jede Änderung mit hohem Risiko freigeben. Ob sie es muss und wer festlegt, was hohes Risiko ist, regelt das Werkzeug nicht. Das bleibt eine Entscheidung im Unternehmen.

Am selben Tag hat Microsoft das Gerüst vorgestellt, auf dem seine Copilot-Produkte laufen: Microsoft betreibt die Agentenschleife und die Sandbox, die Kunden bringen Anweisungen, Werkzeuge und die Modellwahl mit. GitHub Copilot Fusion entscheidet je Anfrage, welche Modelle arbeiten; Administratoren legen fest, welche Modelle Fusion nutzen darf und ob es der Standard ist. GitHub meldet für Fusion Max 60 Punkte im Coding Agent Index von Artificial Analysis bei etwa halben Kosten je Aufgabe. Wichtiger als die Zahl ist, wo die Modellwahl jetzt liegt: in einer Richtlinie der IT. Zu Freigabe oder Prüfpfad steht in beiden Texten nichts.

David Cramer beschreibt, wie er Junior steuert, den Agenten, den er bei Sentry gebaut hat. Seine Erfahrung: Wer einem Agenten Freiheit nimmt, bekommt einen deutlich schwächeren Agenten, und Anweisungen im Systemprompt oder in AGENTS.md halten selten. Er setzt die Regeln deshalb außerhalb des Agenten durch, in einem Proxy zwischen Sandbox und Netz. Der Proxy prüft jede Anfrage gegen eine Richtlinie und ergänzt erst dann die Zugangsdaten. Legt der Agent einen Pull Request über die Kommandozeile an, bekommt er eine Ablehnung mit dem Hinweis auf das richtige Werkzeug. So kann Junior keinen Pull Request freigeben, obwohl sein GitHub-Token es erlauben würde. Zahlen gibt es keine, Cramer berichtet aus dem eigenen Betrieb. Welche Rechte der Agent hat, legt hier eine Richtlinie im eigenen Haus fest. Die Rechte des Tokens sind nur die Obergrenze.

Hanjing Shi und Dominic DiFranzo haben 63 öffentliche Dokumente zu Agentensystemen danach durchgesehen, welche Kontrollen darin klar beschrieben sind. Werkzeugzugriff und Protokolle fanden sie oft, in 40 und 37 Fällen. Einen Prüfpunkt vor einer folgenreichen Handlung fanden sie in 6, einen Weg zur Rücknahme in 2. Ihr Satz dazu: Ein Agentensystem ist nicht schon deshalb rechenschaftsfähig, weil seine Handlungen protokolliert werden. Ein Prüfpunkt nach der Zahlung oder der versandten Nachricht hält die Zustimmung zu spät fest. Die Auswahl ist bewusst getroffen und sagt nichts darüber, wie verbreitet Kontrollen in laufenden Systemen sind. Neben den Ankündigungen dieser Woche liest sich die Studie trotzdem wie eine Prüfliste: Das Protokoll liefert die Plattform. Wo der Prüfpunkt sitzt, legt das Unternehmen fest.