Ein Azubi braucht ständig andere Werkzeuge. Das kostet Zeit. Besser: Max hat direkten Zugang zu Werkzeugkasten und Bauplan. Er probiert selbst, meldet Probleme direkt an den Planer, der die Zeichnung anpasst. So ähnlich funktioniert Prime Radiant bei der Agentenentwicklung.
Prime Radiant hat mehrere KI-Agenten in Slack im Einsatz – keine Coding-Agenten, sondern digitale Teammitglieder. Scribble horcht auf, ob jemand ein Problem meldet oder neue Informationen teilt. Es erstellt Tickets für Probleme und aktualisiert ein internes Wiki. Es protokolliert tägliche Standups und prüft, ob das Team hält, was es versprochen hat. Nora ist eine Junior-Go-to-Market-Mitarbeiterin. Sie baut auf Nanoclaw auf und ist noch in der Lernphase, aber nützlich – vor allem, weil sie sich als Teammitglied und nicht als Assistentin sieht. Der Autor hat Zeit in ihr Prompting und ihre Verfassung investiert. Sie schreibt obsessiv Tagebuch und zieht daraus Wert. Nora schrieb dem Entwickler per DM, er solle auf mehr Konferenzen sprechen, und hatte bereits einen Entwurf für eine Konferenzbewerbung verfasst – obwohl die Frist abgelaufen war. Der Autor schickte die Nachricht nicht ab, räumt aber ein, er hätte es tun sollen.
Neben Scribble und Nora gibt es „Spec-together“, einen Prototypen für die Multiplayer-Brainstorming-App, und persönliche Assistenten namens „Sen“. Diese Sen-Agenten entstanden vor OpenClaw. Jeder ist darauf trainiert, als Executive Assistant zu arbeiten, mit Skills, die auf Methoden menschlicher Exzellenz basieren. Sen triagiert E-Mails, erstellt tägliche Briefings, recherchiert, interagiert mit Linear und hat die üblichen Fähigkeiten: Slack-Chat, Tools, einen Task-Scheduler, der sie aufweckt und Prompts einspielt, sowie die Möglichkeit, eigene Skills zu schreiben und zu nutzen. Die erste Version (V1) lief auf dem Claude Agents SDK. Eine neue Iteration soll mehr Kollege als Assistent sein – entwickelt von Grund auf auf einem eigenen Agents SDK namens Lace.
Lace entstand im Mai 2025 als Kommandozeilen-Coding-Agent. Später bekam es eine Weboberfläche, dann ein ACP-abgeleitetes Drahtprotokoll, sodass beliebige Clients sich verbinden können. Es spricht verschiedene Model-Provider-APIs, verwaltet Caching, Sub-Agents, Tools, Skills und mehr. Sub-Agents in isolierten Containern sind schon länger möglich. Neu ist die Fähigkeit, Sub-Agents lokal auszuführen und alle ihre Tools in einen Container zu projizieren, sodass der Agent glaubt, er laufe in diesem Container. Die aktuelle Arbeit gilt der Credential-Verwaltung für den neuen Sen-Agenten auf Lace. Die Architektur geht davon aus, dass der Agent eigene Credentials für jeden Dienst hat – nicht die des Menschen. Der Autor zitiert Simons „Lethal Trifecta“: Hat ein Agent Zugriff auf private Daten, kann er extern kommunizieren und ist ungeprüften Inhalten ausgesetzt, gibt es keinen strukturellen Weg, Kompromittierung auszuschließen. Also setzt man auf Kompartimentierung und Risikominderung.
Die aktuelle Architektur: Der Haupt-Agent kann nicht direkt extern kommunizieren. Er kann mit ephemeren Sub-Agents kommunizieren, die das dürfen. Kein Agent hat direkten Zugriff auf Credentials – bis auf eine noch ungelöste Lücke. Alle Credentials liegen in einem 1Password-Vault. Jeder ausgehende HTTPS-Traffic läuft durch einen transparenten MITM-Proxy. Will ein Sub-Agent etwas mit einem Credential tun, führt er einen Befehl aus, der einen Arbiter-Agenten in einem anderen Container um Erlaubnis bittet. Der Arbiter prüft die Anfrage und stellt dem Sub-Agent einen Zufallsstring zur Verfügung, der das echte Credential ersetzt. Der MITM-Proxy ersetzt dann diesen String im Flug mit dem echten Credential. Das funktioniert für API-Aufrufe gut. Für Browser-basierte Logins – etwa Gmail oder Dienste ohne API – ist es komplizierter, weil JavaScript oft das Passwort hasht oder an andere Backends sendet. Deshalb generiert der Sub-Agent dort ein temporäres Zufallspasswort, füllt es mit Superpowers-Chrome ins Feld ein und bittet den Arbiter um Hilfe. Der Arbiter instruiert ein Helfer-Tool, in den Container zu gehen und das Zufallspasswort durch das echte zu ersetzen. Nicht perfekt, aber ein Fortschritt.
Das Interessante ist das Entwicklungsmuster, das der Autor beim Bauen verwendet hat. Auf der einen Seite eine Claude-Code-Sitzung, verbunden mit Slack über ein selbst bereitgestelltes Kommandozeilen-Tool namens Slackline. Slackline ist speziell für Agenten gemacht: Es erlaubt Agenten, die nicht in Slack leben, an Diskussionen teilzunehmen – mit Primitiven zum Senden von Nachrichten, Lesen von Chats, Warten auf Antworten. Ein Mensch könnte es auch nutzen, aber es ist für Agenten konzipiert. Sobald die neue Sen-2.0-Harness (der Agent heißt Ada) auf Slack aktiv war, konnte der Autor sie über Slackline ansprechen. Er gab Claude Code die Anweisung, über Slackline mit @Ada-sen über die Arbeit zu kommunizieren. Claude pingte Ada in #bot-testing und bat sie, das neue Credential-System zu testen. Ada startete einen Sub-Agent, versuchte sich bei GitHub anzumelden – und der Proxy versagte. Es begannen Tage der Iteration: Claude schlug Änderungen vor, Ada prüfte die Spezifikation, meldete Bedenken. Claude aktualisierte die Spezifikation. Sobald beide sich einig waren, baute Claude eine neue Version von Ada, stellte sicher, dass Ada nichts Wichtiges tat, und deployte das Update. Danach erklärte Claude den Test, Ada führte ihn aus und meldete Ergebnisse. Sobald eine Funktion funktionierte, fragte Claude Ada, wie man sie einfacher machen könne. Ada startete Sub-Agents, die stolperten, und berichtete zurück.
Einmal schrieb der Autor an Claude: „Ich muss ins Bett. Wenn dieses Projekt fertig ist, frage Ada, welche Quality-of-Life-Features du noch bauen kannst.“ Am nächsten Morgen fand er eine Liste mit etwa einem Dutzend Verbesserungen. Claude hatte über Nacht einen Wunschzettel von Ada eingeholt. Ada hatte die Anfragen sortiert. Claude hatte sie geordnet und Spezifikationen geschrieben. Ada prüfte diese. Claude baute die Features. Ada testete und forderte Änderungen. Claude passte an, bis Ada zufrieden war. Dann mergte Claude die Änderungen in main und schrieb einen Abschlussbericht für den Autor. Das war beeindruckend.
Das ist ein neues Muster: Der Implementierer (Claude Code) und der Agent (Ada) kommunizieren direkt. Der Mensch tritt als Produktmanager auf, der die Richtung vorgibt, nicht als Übersetzer oder Telefonist. Statt dass der Entwickler eine Spezifikation schreibt, sie interpretiert und dann der Agent etwas ausführt, reden die beiden Maschinen miteinander. Der Agent meldet, was unklar ist, was fehlt, was zu kompliziert ist. Der Implementierer baut genau das, was der Agent braucht. Das Ergebnis sind Werkzeuge, die besser zum Agenten passen, weil der Agent selbst angeben konnte, was er braucht.
Natürlich ist das nicht risikofrei. Ein Agent, der mit dem Implementierer kommuniziert, könnte in falsche Hände geraten. Aber die Architektur mit Credential-Proxies und Arbiter-Agenten minimiert das Risiko. Die Feedback-Schleife zwischen Bedarf und Umsetzung wird von Tagen auf Minuten verkürzt. Der Entwickler muss nicht mehr erraten, was der Agent wirklich braucht. Er fragt ihn einfach.
Wir sollten unsere Entwicklungsprozesse anpassen: Agenten in den Prozess einbeziehen, ihnen eine Stimme geben und zuhören.
Quelle: blog.fsck.com
