Notizen zum Bauen, Identität, AI und den Dingen, die mich nachts wachhalten.
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.