Acht Claude-Spezialisten in einem Telegram-Chat übernehmen den Arbeitsalltag
Ein Entwickler steuert eine Claude Code Session per Text- oder Sprachnachricht über Telegram an. Die Session verteilt Aufgaben an acht weitere Claude-Instanzen mit eigenen Zuständigkeiten und liefert am Abend messbare Experimente und aufgeräumte Postfächer.
Veröffentlicht am 10. Oktober • Zuerst erschienen auf nulltensor.com
In der vergangenen Woche lief der Großteil meiner Arbeit außerhalb von Meetings über eine einzige Konversation. Ich sende einen Text oder eine Sprachnachricht an eine Claude Code Session auf Telegram, und diese gibt die Arbeit an eine von acht weiteren Claude Sessions weiter, die jeweils eine eigene Aufgabe haben. Am Abend ist ein Experiment ausgewertet, ein Posteingang in eine Aufgabenliste und eine Forschungsnotiz umgewandelt, und ich habe kein einziges Terminal geöffnet.
Das klingt geordneter, als es war. Das Setup brach fast täglich auf neue Weise, und das meiste, was ich darüber weiß, stammt aus diesen Brüchen. Dieser Beitrag erklärt die Agentenarchitektur, was sie kostet und die Fehler, die sie geprägt haben, in einem Detailgrad, mit dem man sein eigenes bauen könnte.
Alles läuft auf einer einzigen Azure VM mit einem dauerhaft angemeldeten Desktop, weil ein Teil der Arbeit einen echten Browser braucht. Darauf laufen drei Arten von Prozessen:
Die erste Version ließ den Chief of Staff bei kleinen Aufgaben helfen. Claude Code bearbeitet jeweils nur einen Durchlauf, sodass jede Minute, die es mit dem Durchsuchen eines Logs verbrachte, eine Minute war, in der meine nächste Anfrage in der Warteschlange wartete.
Deshalb wurde die Regel streng. Bei jeder eingehenden Aufgabe macht es höchstens eine kurze Lektüre, um zu entscheiden, wer sie erledigen soll, sendet das Briefing an diesen Spezialisten und beendet seinen Durchlauf. Passt kein Spezialist, startet es einen. Auch die Verifikation wird delegiert: Bei der Behauptung "fertig" gibt es eine Anfrage nach Belegen oder eine Prüfung durch einen zweiten Spezialisten.
Ein Nebeneffekt, den ich nicht geplant hatte: Der Kontext jedes Spezialisten bleibt bei seiner eigenen Domäne. Die Content Session kennt das Content Experiment Ledger im Detail und nichts über Datenbankmigrationen, was ihre Durchläufe kurz hält und ihre Fehler leicht nachvollziehbar macht.
Ich sitze selten am Terminal der VM, also erreicht mich alles, was nur dort auftaucht, nie. Claude Codes Channels Funktion verbindet eine Session mit einem Telegram Bot, und dieser Bot wurde zur einzigen Art, wie das System mit mir kommuniziert.
Telegram erlaubt genau einen Poller pro Bot Token, und das Claude Code Plugin erzwingt das, indem es jeden bestehenden Poller beendet, wenn ein neuer startet. Das ist für eine Session vernünftig und für eine Maschine mit neun gefährlich. In den ersten zwei Tagen fiel die Telegram Bridge auf vier Arten aus:
Der Watchdog ist ein systemd Timer, der alle zwei Minuten ein kurzes Shell Skript ausführt: 30 bis 40 Millisekunden CPU und etwa 5 MB Speicher pro fehlerfreiem Durchlauf. Er prüft, ob der Poller lebt, aus dem Plugin Verzeichnis läuft und die Chief of Staff Session als Vorfahren hat. Diese letzte Prüfung stammte aus Fehler 1: Drei Durchläufe lang war der Poller am Leben, gesund und gehörte zur falschen Session. "Ein Poller existiert" und "meine Session besitzt den Poller" sind unterschiedliche Gesundheitssignale, und nur das zweite verrät, ob Nachrichten mich erreichen.
Nach zwei fehlgeschlagenen Prüfungen startet er die Chief of Staff Session neu, mit einem Lock und Abklingzeiten. Der Neustart hat seine eigene Falle: claude --bg --resume <session-id> weckt die Session nur an Ort und Stelle ohne weitere Flags. Übergibt man irgendein Flag, auch die ursprünglichen, erhält man eine Kopie mit neuer ID, ohne Namen und ohne Telegram Channel.
Jede Schleife läuft in zwei Stufen. Die erste ist einfaches bash ohne Modell: prüfen, ob etwas fällig ist, die Eingaben sammeln und abbrechen, wenn es nichts zu tun gibt. Erst danach startet der Runner claude -p auf einem günstigeren Modell, wobei die Eingaben bereits im Prompt stehen.
Die Lektion, die wir immer wieder lernten: Alles Deterministische gehört in ein Skript, nicht in die Instruktionen des Modells.
Jede Session liest ein gemeinsames Verzeichnis mit Markdown Dateien, eine Fakta pro Datei mit einem Namen, einer Einzeilige-Beschreibung und einem Typ, verknüpft mit [[name]] zu einem kleinen Graphen. Ein Index mit einer Zeile pro Memory wird bei jedem Session Start geladen.
Zwei Regeln verhindern, dass es verrottet: Spezialisten dürfen Fakten in ihrer eigenen Domäne korrigieren, müssen das aber kenntlich machen, und niemand löscht ein Memory ohne Zustimmung des Chief of Staff, weil ein scheinbar veraltetes Memory oft der einzige Beleg dafür ist, warum eine Regel existiert. Die Schwachstelle war das Decision Log, das in fünf Tagen auf 188 KB anwuchs und bei jedem Session Start neu gelesen wurde. Es ist jetzt eine kurze Live Queue plus ein Archiv.
An einem frühen Tag zeigte das Anthropic Dashboard etwa 195 Dollar an, und ich wusste nicht warum. Die Prüfung ergab, dass 88 % der Ausgaben darauf entfielen, dass das Modell seinen eigenen Kontext erneut las: 48 % Cache Reads und 40 % Cache Writes, mit unter 12 % Output. Der Chief of Staff las bei jedem Durchlauf rund 440.000 Token neu, weil bei einem 1-Million-Token-Fenster die Auto-Kompaktierung nie auslöste.
Was half, waren Kontext und Durchläufe, keine cleveren Prompts. Ein Standardfenster senkte die Kosten pro Durchlauf des Chief of Staff von etwa 28 auf 13 Cent. Er läuft auf Claude Opus 5.5, und ich habe sein Kontextfenster von Hand auf 256.000 Token begrenzt, sodass die Auto-Kompaktierung früh auslöst, was die Durchläufe günstiger und den Thread reaktionsschnell hält.
Die Spezialisten laufen ebenfalls auf Claude Opus 5.5, die geplanten Jobs auf Claude Sonnet 5.5 bei wenigen Cent pro Durchlauf, und nichts nutzt Fable. Und ein vollständiges Briefing pro Aufgabe, denn die Kosten folgen den Durchläufen enger als allem anderen, was wir gemessen haben. Billig ist es trotzdem nicht: Die täglichen Ausgaben schwanken zwischen etwa 30 Dollar an einem ruhigen Tag und etwa 200 Dollar an einem intensiven Bautag.
Die meisten Fehler in diesem System traten lautlos auf: saubere Logs, Exit Code 0, und nichts geschah.
Die Gewohnheit hinter all dem: Einer Regel vertrauen wir erst, wenn sie gegen den echten Zustand gelaufen ist, und einem Bericht vertrauen wir erst, wenn das Ergebnis auf der Festplatte liegt.
Es gibt gute Fertiglösungen: xAIs Grok Bot, Metas Muse, OpenAIs Codex, Anthropics Claude Cowork sowie Open-Source-Alternativen zu jedem davon. Jede einzelne hat mich irgendwie eingeschränkt.
Ich wollte etwas, das vollständig um meine Arbeitsweise herum aufgebaut ist. Ein eigener Aufbau erlaubt mir, das Beste jedes Tools zu nehmen und das Setup jederzeit anzupassen, ohne den Anbieter zu wechseln.
Das ist nicht der endgültige Aufbau, und ich freue mich darauf, was ich als Nächstes in meinen persönlichen Assistenten einbauen werde.
Wenn du deinen eigenen gebaut hast: Was wäre das Erste, in das du ihn einbinden würdest?
Mit Vorlagen kannst du häufige Fragen schnell beantworten oder Snippets zur Wiederverwendung speichern.
Bist du sicher, dass du diesen Kommentar verbergen möchtest? Er wird in deinem Beitrag ausgeblendet, bleibt aber über den Permalink des Kommentars sichtbar.
Für weitere Maßnahmen kannst du erwägen, diese Person zu blockieren und/oder einen Missbrauchsfall zu melden.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 10 • Originally published at nulltensor.com
For the last week, most of my work outside meetings has gone through one conversation. I send a text or a voice note to a Claude Code session on Telegram, and it hands the work to one of eight other Claude sessions, each with its own job. By evening I have an experiment measured, an inbox turned into a task list and a research note, and I have not opened a terminal.
That sounds tidier than it has been. The setup broke in new ways almost every day, and most of what I know about it came from those breaks. This post walks through the agent architecture, what it costs and the failures that shaped it, at the level of detail where you could build your own.
Everything runs on one Azure VM with a permanently logged-in desktop, because some work needs a real browser. On it run three kinds of process:
The first version let the chief of staff help with small tasks. Claude Code handles one turn at a time, so every minute it spent grepping a log was a minute my next request sat in a queue.
So the rule became strict. On any incoming task it makes at most one quick read to decide who should do it, sends the brief to that specialist, and ends its turn. If no specialist fits, it launches one. Verification is delegated too: a claim of "done" gets a request for evidence or a second specialist's check.
A side benefit I did not plan for: every specialist's context stays about its own domain. The content session knows the content experiment ledger in detail and nothing about database migrations, which keeps its turns short and its mistakes easy to trace.
I am rarely at the VM's terminal, so anything that shows up only there never reaches me. Claude Code's channels feature connects a session to a Telegram bot, and that bot became the only way the system talks to me.
Telegram allows exactly one poller per bot token, and the Claude Code plugin enforces that by killing any existing poller when a new one starts. That is reasonable for one session and dangerous for a machine running nine. In the first two days the Telegram bridge went down four ways:
The watchdog is a systemd timer that runs a short shell script every two minutes: 30 to 40 milliseconds of CPU and about 5 MB of memory per healthy tick. It checks that the poller is alive, runs from the plugin's directory, and has the chief of staff session as its ancestor. That last check came from failure 1: for three ticks the poller was alive and healthy and belonged to the wrong session. "A poller exists" and "my session owns the poller" are different health signals, and only the second tells you whether messages will reach you.
After two failed checks it restarts the chief of staff, with a lock and cool-downs. The restart has its own trap: claude --bg --resume <session-id> wakes the session in place only with no other flags. Pass any flag, even the original ones, and you get a copy with a new id, no name and no Telegram channel.
Each loop runs in two stages. The first is plain bash with no model: check whether anything is due, gather the inputs, and exit if there is nothing to do. Only then does the runner start claude -p on a cheaper model, with the inputs already in the prompt.
The lesson we kept relearning: anything deterministic belongs in a script, not in the model's instructions.
Every session reads a shared directory of markdown files, one fact per file with a name, a one-line description and a type, linked with [[name]] into a small graph. A one-line-per-memory index loads into every session at start.
Two rules keep it from rotting: specialists may correct facts in their own domain but must say so, and nobody deletes a memory without the chief of staff agreeing, because a stale-looking memory is often the only record of why a rule exists. The weak spot was the decision log, which grew to 188 KB in five days and was re-read at every session start. It is now a short live queue plus an archive.
On one day early on, the Anthropic dashboard showed about $195, and I did not know why. The audit found that 88% of spend was the model re-reading its own context: 48% cache reads and 40% cache writes, with output under 12%. The chief of staff was re-reading around 440,000 tokens on every turn, because on a 1M-token window auto-compaction never triggered.
What helped was context and turns, not clever prompts. A standard window cut the chief of staff's cost per turn from about 28 cents to 13. It runs on Claude Opus 5.5, and I capped its context window by hand at 256,000 tokens, so auto-compaction kicks in early, keeping turns cheaper and the thread responsive. The specialists run on Claude Opus 5.5 too, the scheduled jobs on Claude Sonnet 5.5 at a few cents a turn, and nothing uses Fable. And one complete brief per task, because cost follows turns more closely than anything else we measured. It is still not cheap: daily spend ranges from about $30 on a quiet day to about $200 on a heavy build day.
Most bugs in this system failed quietly: clean logs, exit code 0, and nothing happened.
The habit behind all of these: we do not trust a rule until it has run against the real state, and we do not trust a report until the result is on disk.
There are good off-the-shelf options: xAI's Grok Bot, Meta's Muse, OpenAI's Codex, Anthropic's Claude Cowork, and open-source alternatives to each. Every one of them held me back in some way.
I wanted something wired completely around how I work. A custom build lets me take the best of each tool and change the setup whenever I need to without switching providers.
This is not the final build, and I am excited about what I will build into my personal assistant next.
If you built your own, what is the first thing you would wire it into?