—Frage
Ein persönlicher Agent, der Mail schreibt, Termine legt und von sich aus meldet, klingt nach einem Fähigkeitsproblem. In der Praxis war es ein Kontrollproblem.
Die Leitfrage, die sich aus dem täglichen Betrieb ergab, lautet:
Welche Kontrollschichten braucht ein persönliches Agentensystem, damit es im Alltag nützlich bleibt und nicht zur Last wird?
Ivy sitzt zwischen mir und einer Reihe von Werkzeugen. Ich schreibe ihr über WhatsApp oder einen Web-Chat, sie ordnet die Anfrage ein, wählt Modell und Tool, handelt und antwortet. Sie läuft nicht als Demo, sondern seit Anfang Q2 2026 produktiv auf eigener Infrastruktur; der Web-Chat kam später als zusätzlicher Kanal dazu. Dieser Text beschreibt die Architektur und danach konkrete Beobachtungen aus dem Betrieb, auch die Fälle, in denen etwas nicht funktioniert hat.
—Setup
Ivy ist die Bezeichnung für das gesamte persönliche Agentensystem. Ein Team-Loop ist der gerichtete Ablauf, in dem Ivy an spezialisierte Agenten delegiert, deren Ergebnis prüfen lässt und erst danach zurückgibt. Ein Ausgangs-Guard ist die zentrale Stelle, über die jede nach außen wirkende Nachricht läuft, unabhängig davon, welcher interne Pfad sie erzeugt hat.
Ivy folgt einem kanonischen Ablauf statt gewachsener Sonderpfade: Eingang mit Auth und Dedupe, strukturierter Kontextbau aus Konversation, Gedächtnis und offenen Objekten, eine zentrale Entscheidung, die Aktion über Tools, eine vom Modell formulierte Antwort, Persistenz und Beobachtung. Jede Nutzeranfrage läuft über denselben Hauptpfad. Ein zweiter, heimlicher Entscheidungsloop ist ausdrücklich verboten.
Zwei Bausteine sind für die Kontrolle zentral. Erstens ein Gedächtnis in mehreren Schichten: kurzfristige Fakten, operatives Material, offene strategische Fäden und ein vernetzter Wissensspeicher. Zweitens ein kleines Team spezialisierter Agenten mit klaren Rollen. Ivy koordiniert, Cody baut am System, Pix erstellt Kreatives, und Ada prüft als Review-Instanz.
Der Weg ist bewusst gerichtet. Ich beauftrage Ivy, Ivy delegiert an Cody oder Pix, diese arbeiten mit Ada hin und her, bis das Ergebnis die Prüfung besteht. Erst dann geht es über Ivy zurück an mich. Cody und Pix deployen nie selbst. Nach außen spricht nur eine Stimme.
—Beobachtung
Die folgenden Beobachtungen stammen aus dem laufenden Betrieb. Die meisten habe ich selbst bemerkt. Subtile Fehler, die im Alltag nicht auffallen, kamen über die Fehlerüberwachung ans Licht. Jede Note endet bei einer allgemeinen Regel, nicht bei einem Einzelfall.
Klein anfangen, sonst überholt dich das Reparieren
Ende April 2026 baute ich Ivy zu einem Mehrmandanten-System aus, damit mehrere Instanzen mit eigenen Zugängen laufen können. Über sieben Tage entstanden gut hundert Commits. Danach war klar, dass zu viele Modi gleichzeitig gebrochen waren: Nachrichten-Routing, Mail-Entwürfe und Kalender hingen an der neuen Isolation. Ich rollte den gesamten Zweig hart auf einen sicheren Stand zurück und holte einzelne saubere Fixes später zurück. Die Regel: Ein persönlicher Agent muss klein anfangen. Wächst die Autonomie schneller, als man Fehler beheben kann, verliert man die Kontrolle über das eigene System.
Kosten sind eine Grenze, keine Fußnote
Ivy konnte früher deutlich mehr von selbst: Lücken in ihren Fähigkeiten erkennen und automatisch einen Bau-Task auslösen, sich selbst erweitern und häufig proaktiv sprechen. Das funktionierte technisch. Ein Live-Test der Fähigkeitslücken-Erkennung Anfang April zeigte, dass Ivy eine fehlende Fähigkeit korrekt erkennt und den passenden Bau-Task selbst anstößt. Trotzdem habe ich Auto-Fix, Selbst-Erweiterung und die proaktiven Sprecheinheiten mit der Zeit wieder reduziert, weil sie im Dauerbetrieb schlicht zu teuer wurden.
An die Stelle der teuren Autonomie trat eine Architektur aus Model-Tiering und Prompt-Caching. In einem Kostenmodell mit rund 400 Modellcalls pro Tag sinkt die rechnerische Modellkostenbasis von etwa 14,40 Dollar auf etwa 1,03 Dollar pro Tag, wenn 95 Prozent der Calls aus dem Frontier-Konsens in günstigere Tier-1/2-Pfade wandern. Das ist ein Architektur-Szenario, kein typischer Produktionsdurchschnitt. Die Regel: Autonomie ist durch Kosten begrenzt. Tiering, Caching und Kosten-Telemetrie sind deshalb keine nachträgliche Optimierung, sondern Teil der Architektur.
Freigeben tut der Mensch, nicht der Agent
Für einen kurzen Zeitraum durfte Ivy Nachrichten nach außen selbst senden. Auch wenn das unter meinem Namen und in meinem Ton lief, war es keine gute Idee. Seitdem gilt eine harte Trennung: Ivy formuliert und legt bereit, die Freigabe nach außen gebe ich. Mails landen nur als Entwurf im Postfach, nicht im Versand. Die Regel: Alles, was nach außen wirkt, braucht einen menschlichen Freigabepunkt. Der Agent bereitet vor, der Mensch entscheidet.
Eine Stimme, ein Ausgang
Ende Juni bekam ich zeitweise dieselbe proaktive Nachricht doppelt, etwa zwei Begrüßungen am Morgen. Der Grund waren drei getrennte Sendewege mit je eigener oder fehlender Entdopplung. Der Fix führte alle ausgehenden Nachrichten durch einen zentralen Ausgangs-Guard mit persistenter Obergrenze pro Stunde, dessen Zustand einen Neustart übersteht. Die Regel: Wenn mehrere Wege dasselbe senden können, braucht es eine zentrale Wahrheit für Entdopplung und Rate, nicht Logik pro Pfad.
Sichtbarkeit für das, was man nicht spürt
Zwei Vorfälle fielen mir im Alltag gar nicht auf, sondern erst über die Fehlerüberwachung. Einmal feuerte jede Minute ein Alarm, weil ausgehende Nachrichten, die absichtlich nicht gesendet wurden, als Fehler behandelt wurden und einen Wiederholungslauf auslösten. Der Fix trennte drei Fälle sauber: geliefert, bewusst übersprungen und echter Fehler. Ein anderes Mal verstieß ein Agent gegen die Provider-Regel und rief ein Textmodell direkt statt über das Gateway auf. Die Suche nach der Ursache zeigte, dass es kein Einzelfall war, sondern über zwanzig Aufrufstellen betraf. Ich habe die ganze Klasse zentral migriert statt nur das sichtbare Symptom. Die Regel: Beobachtbarkeit fängt, was der Nutzer nicht spürt, und ein Fehler wird an der Ursache behoben, nicht an der Meldung.
Schneller, sauberer Rückzug
Ich versuchte, alle Modell-Aufrufe über ein neues, einheitliches Gateway zu leiten. Die Textaufrufe liefen, aber die Aufrufe für die Einbettungen des Gedächtnisses brachen, weil das Gateway diesen Endpunkt nicht hatte. Innerhalb von rund anderthalb Stunden nahm ich die Migration vollständig zurück und blieb beim funktionierenden Stand. Die Regel: Ein Deploy ist erst dann sicher, wenn der Rückweg genauso schnell und sauber ist wie der Hinweg.
Die Plattform diktiert mit
WhatsApp erlaubt proaktive Nachrichten nur innerhalb eines Zeitfensters von etwa einem Tag, nachdem ich zuletzt selbst geschrieben habe. Wenn ich mich nicht melde, verstummt die proaktive Seite von Ivy, unabhängig davon, was sie mir sagen wollte. Auch der Versand von Anhängen folgt den Regeln des Kanals. Die Regel: Ein Agent, der über eine fremde Plattform kommuniziert, erbt deren Grenzen. Man muss den Kanal so genau verstehen wie das eigene System.
—Bewertung
Der rote Faden dieser Notizen ist, dass die Nützlichkeit von Ivy weniger aus zusätzlichen Fähigkeiten kommt als aus den Schichten, die ihre Autonomie begrenzen. Ein menschlicher Freigabepunkt vor jeder Außenwirkung, ein zentraler Ausgang mit Entdopplung, Beobachtbarkeit für das Unspürbare, ein schneller Rückweg und Kosten als harte Grenze. Dazu kommt Disziplin vor dem Livegang: Eine systematische Vorabprüfung fing mehrere kritische Fehler ab, bevor sie mich überhaupt erreichten.
Diese Schichten sind nicht Ivy-spezifisch. Sie gelten für jedes persönliche Agentensystem, das echte Aktionen auslöst. Die Fähigkeit, etwas zu tun, ist heute der einfache Teil. Der schwierige Teil ist, das Tun kontrollierbar, bezahlbar und umkehrbar zu halten.
| Aussage | Evidenzstatus |
|---|---|
| Kontrollschichten halten den Betrieb über Monate stabil | belegt durch Commits, Fehlerüberwachung und Betriebsdauer |
| Model-Tiering kann die Modellkostenbasis deutlich senken | rechnerisches Architektur-Szenario, nicht typischer Live-Betrieb |
| Zentraler Ausgangs-Guard verhindert doppelte Nachrichten | live verifiziert nach dem Fix vom Juni 2026 |
| Fähigkeitslücken-Erkennung kann eigenständig einen Bau-Task anstoßen | einmalig live getestet, seither aus Kostengründen reduziert |
| Kontrollschichten verbessern den Alltag messbar gegenüber weniger Kontrolle | offen, keine Wirkungsmessung durchgeführt |
| Löschung von Vektor-Gedächtnis folgt derselben Frist wie Nachrichten | offen, dokumentierte Lücke, noch nicht behoben |
—Grenzen
Dieser Bericht misst keine Wirkung. Er zeigt Architektur und Betriebsbeobachtungen, keine Erfolgsstatistik mit Fallzahlen, keine Produktivitätssteigerung, keine gesparten Stunden und keinen ROI. Das System läuft für genau einen Nutzer, mich, weshalb sich daraus keine verallgemeinerten Kennzahlen ableiten lassen. Die Beobachtungen sind durch Commits, Berichte und Fehlerüberwachung belegt, aber es ist keine kontrollierte Studie.
Eine konkrete Lücke ist offen. Nachrichten werden nach einer Frist gelöscht, die zugehörigen Vektoren im semantischen Gedächtnis bleiben jedoch bestehen. Diese Löschlücke ist in internen Audits dokumentiert und noch nicht behoben. Auch die Balance zwischen Autonomie und Kosten ist keine gelöste Frage, sondern eine laufende Abwägung; die genannten Kosten sind als Szenario zu lesen, nicht als stabiler Tageswert des Produktivbetriebs. Modellstände, Preise und Plattformregeln sind eine Momentaufnahme aus Mitte 2026, und einzelne Beobachtungen hängen an den Eigenheiten von WhatsApp.
—Nächster Schritt
Der nächste Schritt ist, die dokumentierte Löschlücke zu schließen, damit Gedächtnis und Löschung in einer Kette liegen. Danach folgt die Frage, welche der zurückgefahrenen autonomen Funktionen sich gezielt zurückholen lassen, dort wo der Nutzen die Kosten trägt. Die Kontrollschichten bleiben die Bedingung dafür, dass das System mitwachsen kann, ohne unübersichtlich zu werden.
Offen bleibt die Messung selbst. Bisher belegt dieser Bericht, dass die Kontrollschichten den Betrieb stabil halten. Er belegt noch nicht, um wie viel sie den Alltag messbar besser machen. Das wäre der Schritt vom Engineering-Bericht zur Wirkungsmessung.
—Quellenregister
Interne Primärquellen (Commit-Historie, Betriebs- und Fehlerüberwachungslogs, interne Audits, nicht öffentlich verlinkt):
- Commit-Historie des Mehrmandanten-Rollbacks (Ende April 2026)
- Live-Test der Fähigkeitslücken-Erkennung (Anfang April 2026)
- Kostenprotokolle Model-Tiering und Prompt-Caching
- Fehlerüberwachungs-Logs zu Ausgangs-Guard, Provider-Gateway-Migration und Rollback
- Interner Audit zur Löschlücke im semantischen Gedächtnis
Externe Referenzen: keine für diese Fassung. Der Bericht beschreibt ausschließlich Architektur und Betriebsbeobachtungen aus einem einzelnen produktiven System.