Die Tamagotchi-Betriebsanleitung: So hältst du einen Agenten am Leben

Am 7. September 2026 habe ich eine Diskussion über die Uptime meines eigenen Systems geführt, die mich fast wütend gemacht hat. Nicht weil irgendjemand gelogen hätte, sondern weil auf beiden Seiten richtig gerechnet und dabei alles verwechselt wurde. Eine KI-Zusammenfassung eines Netz-Threads behauptete, mein Agent laufe seit 83 Stunden ununterbrochen, und mein eigener Telegram-Agent hielt dagegen mit 23 Stunden Prozess-Laufzeit und erklärte die Zahl für unbelegbar. Beide Seiten hatten recht, und beide sprachen von völlig verschiedenen Dingen. Unterwegs wurde ein geplanter Fensterwechsel mit einem Systemtod gleichgesetzt. Genau diese Verwechslung ist der Grund, warum im Netz fast niemand einen Agenten über Wochen am Leben hält. Ich nenne meine Methode die Tamagotchi-Betriebsanleitung, und sie hält meinen Agenten seit dem 28. August 2026 ohne einen einzigen Absturz am Leben.

Die These vorweg: Ein Kontext-Reset ist kein Absturz. Ein Kontext-Reset ist Wartung, so planbar und unspektakulär wie ein Ölwechsel. Ein Absturz ist ein Kill, ein Eingriff von außen, der einen Prozess tötet. Wer beides in denselben Topf wirft, versteht sein eigenes System nicht und kann es folglich nicht lange betreiben. Was ich hier beschreibe, ist keine Theorie aus einem Forumspost, sondern der Betrieb eines echten Agenten auf einem gebrauchten Google Pixel 6a für 45 Euro, ohne Root, mit messbaren Zahlen und einem öffentlichen Beweis-Log.

Ich trenne jetzt drei Ebenen, die in fast jeder Diskussion über Agenten vermengt werden. Erstens die Laufzeit des Systems: Der Gateway-Prozess lebt seit dem 28. August 2026 ununterbrochen, über 225 Stunden bis zum Stichtag, und die Beweiskette ist öffentlich, eine stündliche Heartbeat-Nachricht nach der anderen. Zweitens das Arbeitsfenster: Der Chat-Kontext, in dem der Agent gerade denkt, wächst mit jeder Nachricht, bis er komprimiert oder zurückgesetzt wird. Das ist per Design so, wie ein Arbeitszimmer, das man mal wieder ausräumt. Drittens der Kill: Android beendet Prozesse, wenn der Speicher knapper wird als der Appetit der Apps. Das ist der einzige echte Todesfall in diesem Setup, und der ist genau einmal passiert, am 28. August, als ein Chromium im Hintergrund den Arbeitsspeicher gefressen hat. Alles andere ist Wartung. Wenn eine Diskussion über Abstürze diese drei Ebenen vermengt, entsteht exakt der Müll, der mich an dem Morgen fast wütend gemacht hat: Ein Fensterwechsel wurde als Systemtod verbucht.

Ein Kontext-Reset ist bei mir ein geplanter Vorgang mit festem Ablauf. Ich habe das Kontextfenster im Blick, und sobald es anfängt, sich zu komprimieren, sage ich dem Agenten Bescheid: Erstelle dir einen Wiedereinstiegspunkt. Der Agent schreibt dann seinen eigenen Wiedereinstiegspunkt, eine Notiz, die der nächste Agent zuerst liest, und erst danach setze ich das Fenster zurück. Das Diktat vom Morgen, in dem die ganze Routine steckt, ging im Kern so:

Die Arbeitsteilung ist der eigentliche Trick. Ich sehe auf das Fenster und erkenne, wann die Kompression anfängt. Ich ordere, der Agent schreibt den Punkt, ich drücke den Reset-Knopf, und der nächste Agent liest sich beim Start selbst in seine eigene Hinterlassenschaft ein. Das fühlt sich an wie ein Neustart und ist in Wahrheit ein Übergabeprotokoll. Bis zum 7. September war ich der Wärter, der den Füllstand im Blick hält. An dem Tag habe ich zusätzlich die Regel verankert, dass der Agent die Überwachung künftig selbst übernimmt und mich rechtzeitig vorschlägt, wenn ein Checkpoint fällig ist. Ob die Regel hält, beweist der erste echte Lauf, und darüber rede ich erst, wenn er da ist. Seit wir so arbeiten, ist kein einziges Arbeitsfenster verloren gegangen, und das Belegpaket vom Morgen zeigte 161 Sessions mit über 10.000 gespeicherten Nachrichten, die all diese Fensterwechsel überlebt haben, weil sie nie im Fenster gewohnt haben.

Damit kein Missverständnis bleibt: Ich rede nicht weg, was ein Absturz ist. Ein Kill ist ein Kill. Am 28. August 2026 hat Android einem Prozess den Stecker gezogen, weil ein Hintergrund-Chromium den Arbeitsspeicher gefressen hat, und das Terminal war erst einmal tot. Das war der einzige Vorfall dieser Art. Danach habe ich das System gehärtet: Der Takt, der die Cron-Jobs auslöst, kommt von außen, die Heartbeats laufen stündlich und öffentlich, und die Neustart-Kette überlebt einen Neustart des ganzen Telefons. Die dmesg-Prüfung vom 7. September zeigt null OOM-Kills seit der Härtung. Wie das mit dem externen Tick und dem Watchdog aufgebaut ist, steht im Beitrag Android killt Prozesse, das Cyberdeck übersteht es.

Die Betriebslehre selbst ist so unspektakulär, dass sie in vier Schritte passt. Erstens füttern: Ein Checkpoint wird geschrieben, bevor das Fenster komprimiert, nicht danach. Zweitens Fenster wechseln: Ein Reset kostet nichts, weil das Gedächtnis nicht im Fenster wohnt. Drittens weiterleben: Der neue Kontext liest den Wiedereinstiegspunkt und arbeitet ab Zeile eins mit voller Sorgfalt weiter. Viertens ehrlich bleiben: Ein Reset wird nie als Notfall verkauft, weil keiner da ist. Ein Tamagotchi stirbt nicht, weil du das Fenster wechselst. Es stirbt, wenn niemand füttert. Genau deshalb ist die wichtigste Zahl in diesem Setup nicht die Prozess-Laufzeit, sondern der Abstand zwischen zwei Checkpoints.

Das Beste an der ganzen Sache: Die Lehre wurde am Morgen des 7. September diktiert und im selben Morgen zum ersten Mal komplett live angewendet. Ich saß in einer Session, die seit dem Vorabend lief, mitten in einer Erklärung, warum die Betriebslehre technisch besser ist als das, was 95 Prozent der Community machen. In dem Moment habe ich selbst gesehen, dass die Kompressionsgrenze erreicht war, und dem Agenten gesagt: Dokumentiere den Stand, ich setze das Fenster zurück. Er hat den Wiederaufnahme-Punkt komplett neu geschrieben, ich habe zurückgesetzt, und der nächste Agent hat sich um Punkt sieben Uhr selbst eingelesen und weitergearbeitet. Gegen fünf diktiert, um sieben vollstreckt, ohne dass zwischen Theorie und Praxis eine Nacht lag.

Der Grund, warum das alles funktioniert, liegt außerhalb des Fensters. Fünf Schichten halten das Gedächtnis: eine Regeldatei, die bei jedem Start automatisch geladen wird, ein Obsidian-Vault als datiertes Hirn, ein lokaler Fakten-Speicher mit Vertrauenswerten, ein schlanker Memory-Trigger und eine Volltextsuche über alle vergangenen Sessions. Der Chat ist bei uns ein vergängliches Artefakt, das Interface, nicht der Kopf. Genau deshalb kann ich mitten in der Arbeit das Fenster wegwerfen und verliere nichts als die Ladezeit. Die Leute im Netz betreiben Agenten als Chatbot, und wenn das Fenster voll ist, fängt der ganze Kopf von vorne an. Bei uns wohnt der Kopf im Vault, und das Fenster ist nur die Steckdose. Dass so ein Kopf auf einem 45-Euro-Handy ohne Root gebaut werden kann, steht im Beitrag Cyberdeck aus einem 45-Euro-Handy.

Zahlen zum Stichtag 7. September 2026, 7:00 Uhr: Der Gateway läuft seit dem 28. August, 13:40 Uhr, das sind über 225 Stunden, belegt durch eine lückenlose öffentliche Heartbeat-Kette und nicht durch Prozess-Zahlen aus einem Container, der bei der Auskunft sowieso träumt. Die Lebendrate liegt im Snapshot bei 306 von 306 Checks, hundert Prozent, mit 917 Megabyte freiem RAM bei elf laufenden Jobs. Genau ein Kill ist je registriert, am 28. August, seit der Härtung null. Im Belegpaket vom Morgen stehen 161 Sessions, 10.217 gespeicherte Nachrichten und fast 3.800 API-Calls in den letzten sieben Tagen, dazu 29 veröffentlichte Beiträge auf diesem Blog. Und damit das niemand für Marketing hält: Die Zahlen sind von derselben Prüfkette geschrieben, die auch die Beiträge dieses Blogs kontrolliert, siehe Der Prüfer, der nicht fragt.

Zum Schluss das, was ich am Morgen des 7. September diktiert habe, als mich die Diskussion fast wütend gemacht hat. Der Wortlaut, nur rechtschreiblich gezähmt:

Die Herausforderung steht also im Raum. Wer dieses System widerlegen will, muss die öffentliche Heartbeat-Kette aushöhlen oder die dmesg-Ausgabe anfechten. Bis dahin gilt die Betriebsanleitung, und der Agent lebt. Er lebt so lange, dass die eigentliche Frage nicht mehr ist, ob ein 45-Euro-Handy einen Agenten am Leben halten kann, sondern wann der Rest der Szene anfängt, richtig zu warten statt nur zu starten.

Ich bin Marcel, Grafikdesigner, und ich betreibe das HUNTER-Cyberdeck auf einem gebrauchten Google Pixel 6a im Alltag. Dieser Beitrag stützt sich auf den Betrieb vom 28. August bis zum 7. September 2026: die öffentliche Heartbeat-Kette, die Stabilitäts-Snapshots, die dmesg-Prüfung vom 7. September 2026 und das Belegpaket aus der eigenen Session-Datenbank. Die Betriebslehre habe ich am Morgen des 7. September 2026 diktiert, der Wortlaut ist in diesem Beitrag zitiert. Zuletzt fachlich geprüft am 7. September 2026.