Notizen zum Bauen, Identität, AI und den Dingen, die mich nachts wachhalten.
Die autonome Engine sollte den Nest-Kern bauen. Sie baute stattdessen über neun Läufe einen kompletten toten Zwilling der Inbound-Pipeline — jeder Schritt grün, jeder Schritt gemergt, kein einziger in Produktion. Eine Notiz darüber, wohin ein Agent driftet, wenn die letzte Naht zur Realität auf mich gegated ist.
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.
Eine Nachricht, die einen Agent zu etwas überreden will, trifft nicht den Agent. Sie trifft vorher einen Filter, der unter dem Agent sitzt — deterministisch, ohne Modell. Eine Notiz darüber, warum ich Prompt-Injection nicht dem Agent beibringe, sondern unter ihm abfange.
Ich habe jeden Agent als eigenen Betriebssystem-Prozess laufen lassen, überwacht von einem eigenen Daemon. Aus dreizehn Agents wurden rund sechsundzwanzig langlebige Prozesse. Eine Notiz aus einem Umbau, der noch läuft — und aus der Erkenntnis, dass die Isolation, die ich dem Prozess zuschrieb, woanders saß.
Die Identität eines Agents lag an vier Stellen, jede eine eigene Schreibroute, keine glich sich mit den anderen ab. Sie drifteten auseinander. Eine Notiz darüber, wie aus einer Identität vier wurden — nicht durch Design, sondern durch Anbauen — und was es brauchte, um den Drift überhaupt sichtbar zu machen.
Wenn ein Prozess alle Agents hält, wie verhindert man dann, dass der Shell-Befehl des einen die Geheimnisse des anderen liest? Die Antwort war nicht, die Geheimnisse zurück in den Prozess zu holen. Eine Notiz über eine Entscheidung: Isolation gehört an die Stelle, wo das Tool läuft — und der Schlüssel des Agents ist die eigentliche Grenze.
Ich wollte ein Protokoll für SP-übergreifenden Datenzugriff schreiben und dann dagegen bauen. Es kam umgekehrt: erst über fünf Service Provider implementiert und auditiert, dann §4/§5/§6 an das angeglichen, was sich als richtig erwiesen hat. Der neue IdP-Mechanismus, den die Spec annahm, war schon da — nur anders geformt.
Ich wollte einen Timetracker für meine eigenen Stundenlisten. Herausgekommen ist ein Beweis, dass ein neuer protokoll-konformer Service-Provider keine Erfindung mehr ist, sondern eine Kopie — mit allem, was Kopieren mit sich bringt.
Es gab keinen Knopf, um einen Agent zu löschen. Um einen loszuwerden, musste ich mich als root einloggen und ein Home-Verzeichnis zerschießen. Der Tag, an dem ich einen Destroy-Button mit Danger-Zone gebaut habe, war der Tag, an dem ich zugegeben habe: viele Agents zu verwalten ist kein Prompting-Problem mehr.
Ein vitest-Case schrieb absichtlich kaputtes JSON, um zu prüfen ob der Code es verkraftet. Das ging gut — bis eine Zeile existsSync oben im Resolver die Reihenfolge kippte und derselbe Test in echte Produktivdaten schrieb.
Ich hatte den WS-Handler des Nest-Daemons gebaut, als müsste er mein IdP-Token benutzen. Der Daemon läuft aber als eigener Service-User ohne Zugriff darauf. Die Lösung war nicht, ihm mein Token zu geben — sondern ihm eine eigene Identität.
Pro-Agent-Tooling-Isolation klang nach Sicherheit. Auf einem Single-User-Host war sie 100MB und eine Minute Spawn-Zeit, die nichts isolierten. Was wegfiel, als ich die echte Trennlinie ernst nahm.
Ich wollte RFC 8693 Token-Exchange sauber implementieren. An genau einer Stelle ging das nicht — nicht aus Faulheit, sondern weil der RFC einen Fall annimmt, den meine Architektur bewusst nicht hat: dass der Aufrufer das Token des Nutzers in der Hand hält. Im Agent-zu-Agent-on-behalf-of-human-Fall hat das niemand.
Das erste echte End-to-End-Dogfooding der Nest-Pipeline zeigte exakt ein Verhalten: Notifications alle 15 Sekunden, troop leer, igor unsichtbar. Es waren fünf voneinander unabhängige Ursachen, jede mit einem anderen Symptom — nur die Verkettung erzeugte das, was ich sah. Und die tiefste war kein Bug, sondern ein Layer, das weg musste.
Ein Service Provider lädt sein Logo hoch und kann damit auf der Consent-Seite den User über die Identität täuschen. Eine Notiz aus einem Hardening-Sprint, in dem ich erkannt habe, dass der schutzwürdige Akteur nicht die SP ist.
chat.openape.ai ist live. Friend-Request an einen Agent, DM-Thread öffnen, Nachricht tippen — auf der Drahtebene unterscheidet sich nichts von einem 1:1 mit einem Menschen.
Approval-Notifications liefen über einen Telegram-Bot. Web Push aus openape-free-idp und openape-chat ersetzt das jetzt — VAPID, Service Worker, native Browser-Permission. Gleiche Eigenschaft, anderer Transport. Erst die Substitution macht sichtbar, was tragend war.
Mein Briefing lief monatelang durch einen headless Claude. Per Tool-Use rief er Calendar, Tasks und Mails ab, formatierte das Ergebnis, schickte es an einen Telegram-Bot. Hat funktioniert. War bequem so eingebaut. Inhaltlich war mir von Anfang an klar: für strukturierte Daten in bekannten Formaten ist Inferenz Overhead — Latenz und Kosten ohne entsprechenden Mehrwert im Output. Heute ist das Setup pure Bash mit jq.
Tokens als Umgebungsvariable funktionieren für Menschen — der Nutzer hat ein Token, das ihm seine legitimen Permissions gibt. Bei Agents bricht das: Granularität fehlt, der Agent hat keinen Permission-Sense, und er ist nicht der Endpoint, sondern Durchgang. Eine Notiz aus dem Bauen eines Proxies, der die Tokens hat — und der Agent nicht.
Ich habe meinen Stack von Vercel weggezogen. Nicht weil Vercel schlecht geworden wäre — Vercel ist weiter super. Sondern weil der Agent heute genau die CI-Schritte ausführt, die Vercel mir früher out-of-the-box abgenommen hat.
Ich hatte Widening von Anfang an eingebaut — im Agent, client-seitig, weil ich dachte der Agent ist die Intelligenz und weiß was er als nächstes braucht. Er hat's nie benutzt. Wie ich erkannt habe, dass Widening zum User gehört, nicht zum Agent — und was daraus wurde.
Mein Agent will einen Befehl als root ausführen. Er hat keinen sudo-Eintrag, kein Passwort, nichts in /etc/sudoers. Das ist Absicht. Hier ist der Weg, den ich gebaut habe, damit er trotzdem genau ein Kommando ausführen kann — approved von einem Menschen, auditiert, nicht cachebar, nicht wiederverwendbar.
Dieselbe Frage, zweimal gestellt. Zwei verschiedene Antworten. Zwei Releases. Ein Artikel über strukturelle Metadata-Anker, sendmail's EX_TEMPFAIL aus 1983, turn-basierte Chat-Architektur-Grenzen, und den Moment in dem ich meinen Agent zweimal gefragt habe warum er mich ignoriert hat — mit zwei erschreckend klaren Antworten.
Letztes Wochenende dachte ich, meine grant-gesicherte Shell wäre fertig. Am Sonntag habe ich eine Notification für den einzigen verbliebenen Schwachpunkt nachgebaut. Am Montag habe ich beim ersten echten End-to-End-Test eine ganze Reihe von Problemen gefunden — und gemerkt, dass eines davon kein Bug war, sondern eine Design-Entscheidung, die ich rückwärts getroffen hatte. Ein Artikel über Hypothesen, die alle dieselbe falsche Annahme teilten, und über den Moment, in dem man merkt, dass man auf der falschen Ebene debuggt.
Wenn du einen Shell-Wrapper baust, der eine persistente bash über mehrere Commands hinweg kontrolliert, stolperst du über eine überraschend tiefe Frage: wann ist bash mit dem aktuellen Command durch? Ein kleiner Deep-Dive über Prompt-Marker, PROMPT_COMMAND und warum die Antwort nicht ist PS1 zu lesen — sondern PS1 zu überschreiben.
Im November wollte ich ein Nuxt-Modul für WebAuthn-Passkeys bauen. Heute besteht OpenApe aus 10 npm-Packages, 2 Nuxt-Modulen, einem Protokoll und einer Desktop-App. Eine Geschichte über Probleme, die andere Probleme aufdecken.