Asynchrone Subagents bei Hermes Agent: Warum ein Handy ein Multi-Agenten-Host sein kann

Seit Juni 2026 lässt sich bei Hermes Agent Arbeit an Subagents abgeben, ohne dass der Eltern-Chat blockiert wird: Der Auftrag geht raus, der Chat bleibt bedienbar, die Ergebnisse laufen später wieder ein. Diese Umstellung haben viele als Komfort-Feature gelesen, ich lese sie als Eintrittskarte in eine andere Hardwareklasse. Dazu muss ich zwei Dinge auseinanderhalten, die in Diskussionen gern vermischt werden: die Asynchronität der Delegation und die Auslagerung der Modelle in die Cloud. Nur eine von beiden macht den Host-RAM fast egal. Dieser Beitrag sortiert das sauber aus, zeigt einen echten Auftrag von der Eingabe bis zur Nachprüfung und nennt die Messung vom 05.09.2026 samt Methode.

Die erste Frage lautet: Wann kommt das Ergebnis? Asynchron heißt, der Eltern-Agent wartet nicht mehr. Vor der Umstellung saß der Chat fest, bis das Kind fertig war, wer drei Recherchen parallel abgab, erledigte sie der Reihe nach im Wartezimmer. Seit der Änderung geht der Auftrag raus, der Eltern-Chat arbeitet weiter, und das Ergebnis läuft ein, sobald es da ist. Die Änderung ist dokumentiert: MarkTechPost hat sie am 16.06.2026 beschrieben, im Projekt wird sie als Issue 5586 geführt. Die offizielle Delegation-Doku, geprüft am 05.09.2026 im Betrieb mit Hermes v0.20.6, beschreibt zusätzlich Live-Steuerung: Ein laufendes Kind lässt sich mitten im Lauf korrigieren, ohne es abzubrechen.

Für meinen Betrieb heißt das: Ich kann parallel recherchieren, draften und prüfen lassen, während der Chat frei bleibt für den nächsten Schritt. Die Wartezeit, die vorher ein blockierter Chat war, ist eine laufende Pipeline. Der Listenbefehl der Doku zeigt laufende Kinder mit ihrer letzten Aktivität, und die Korrektur mitten im Lauf hat mir schon einen Fehlaufruf erspart. Ein Hinweis zur Version, denn Dokumentation altert: Diese Fähigkeiten habe ich am 05.09.2026 gegen die offizielle Doku geprüft, im Betrieb mit Hermes v0.20.6. Was eine spätere Version zusätzlich kann, sage ich damit nicht voraus.

Die zweite Frage lautet: Wo rechnet das Kind? In meinem Stack laufen die Modelle der Kind-Agenten bei einem Cloud-Anbieter, der Host auf dem Handy führt nur Orchestrierung aus: Kontexte bauen, Aufträge verteilen, Ergebnisse einsammeln, verifizieren. Diese Auslagerung ist eine separate Entscheidung, sie lässt sich mit asynchroner Delegation kombinieren, muss es aber nicht. Wer lokale Modelle fährt und trotzdem asynchron delegiert, bekommt einen freien Chat bei voller Auslastung. Wer Cloud-Modelle nutzt und synchron wartet, schont den RAM und blockiert trotzdem. Der RAM-Effekt kommt aus der Auslagerung, nicht aus der Asynchronität, und genau diese Zuordnung fehlte in der ersten Fassung dieses Beitrags.

Jetzt die Zahl mit ihrem Kleingedruckten. Mein kompletter Container, also Hermes, Gateway und die Automatik, lag am 05.09.2026 bei rund 380 Megabyte, gemessen als Summe der Resident-Set-Größen über ps, eine Momentaufnahme ohne definierte Workerlast. Genau das ist die Geltungsgrenze: Die Aussage gilt für den Leerlauf der Orchestrierung, nicht für einen belasteten Betrieb. RSS-Summen können zudem Shared Memory doppelt zählen, und der Wert sagt nichts über den geräteweit freien Speicher, der lag an dem Tag bei rund 1,2 Gigabyte MemAvailable inklusive dem, was Android selbst belegt.

Unter Last habe ich gelegentlich rund 450 MB notiert, diese Beobachtung war keine systematische Messung. Eine belastbare Zahl unter definierter Workerlast existiert in meinem Messregister bisher nicht, sie steht dort als offener Punkt. Bis dahin bleibt die ehrliche Aussage: Die 380 MB sind eine dokumentierte Momentaufnahme aus dem Leerlauf, aufgenommen mit einer Methode, die sich in einer Minute nachvollziehen lässt.

Warum der Host so schlank bleibt: Ein Kind-Agent ist für das Handy ein Haufen API-Aufrufe, kein Prozess mit Modell im Speicher. Die Rechenlast sitzt beim Anbieter, der Host organisiert. Das ist der Grund, warum ein gebrauchtes Google Pixel 6a mit 6 GB RAM für 45 Euro als Multi-Agenten-Host reicht, ohne Root. Die Kehrseite kennt dieses Gerät: Android greift bei Speicherdruck hart durch, das habe ich am 28.08.2026 am eigenen System gesehen, als ein Browser den Speicher fraß und Prozesse starben. Genau darauf ist der Stack gebaut: Watchdogs setzen nach Kills wieder auf, das Gedächtnis überlebt den Kill, die Arbeitsteilung bleibt dieselbe: Hermes plant, der pi-Agent baut, Hermes verifiziert.

Abstraktionen über Delegation nützen erst, wenn man eine echte Übergabe sieht. Das Beispiel stammt aus dem Preiskompass-Bau, fertiggestellt und verifiziert am 28.08.2026, einem Reselling-Monitor mit automatisiertem SEO-Blog. Das betreffende Modul sollte wöchentliche Marktanalysen erzeugen und dabei interne Archivlinks setzen. Der Auftrag an das pi-Kind hatte drei Teile. Das Ziel: ein Modul, das die Analyse erzeugt, formatiert und mit eigenen Archivlinks ausliefert. Die Grenzen: keine Änderungen außerhalb des Projektordners, keine neuen Abhängigkeiten ohne Begründung, Netzaufrufe nur auf die vorgegebenen Domänen. Die Akzeptanzkriterien: Die Testsuite läuft, definierte Sonderfälle werden behandelt, das Ergebnis kommt als Textausgabe zurück.

Das Kind lieferte drei Dinge zurück: die Dateien mit kurzer Begründung je Änderung, die Ausgabe der Testsuite als Text und eine Liste der Fälle, die es nicht bearbeitet hat. Rund zwanzig Minuten nach Auftragsübergabe war der Bau fertig. Geglaubt habe ich die Erfolgsmeldung nicht, ich habe nachgeprüft. Die Testsuite lief dazu in einem eigenen Python-3.12-Venv, sieben von sieben Tests bestanden, Ruff-Lint und Compile-Check waren grün. Erst diese eigene Prüfung gegen die Akzeptanzkriterien lässt den Auftrag als erledigt gelten, nicht die Selbstauskunft des Kindes. Die Nachprüfung kostet Minuten, ein ungeprüfter Fehllauf kostet Stunden, und genau deshalb bleibt sie beim Eltern-Agenten hängen.

Erstens: Ein Kind erbt nicht die Eltern-Konversation; was es zusätzlich an Projektkontext sieht, etwa eingebettete Projektdateien des Workspace, regelt die aktuelle Delegations-Dokumentation. Gemessen habe ich hier das Verhalten von v0.20.6 am 05.09.2026, nicht die Doku-Lage jeder Version. Kontext gehört vollständig hinein, Dateipfade, Fehlermeldungen, Constraints. Halb übergebener Kontext produziert schöne Selbstauskünfte über Arbeit, die es nicht gab, das habe ich im Betrieb bezahlt. Zweitens: Kinder stellen keine Rückfragen. Ein Auftrag mit Mehrdeutigkeit wird mit einer Annahme beantwortet, nicht mit einer Frage, und eine falsche Annahme kostet einen ganzen Durchlauf. Drittens: Zusammenfassungen sind Selbstauskünfte. Was nach außen wirkt, eine Datei, ein Upload, ein Publish, prüfe ich selbst gegen das Ziel nach, statt der Meldung des Kindes zu glauben. Diese Regeln verlagern Arbeit vom Korrigieren zum Vorbereiten, und Vorbereiten ist billig.

Erstens der Vagheits-Auftrag: Fixe den Fehler, ohne Kontext mitzugeben, und das Kind repariert etwas anderes oder erfindet eine Ursache. Zweitens die Parallel-Falle: Fünf Kinder gleichzeitig auf Aufgaben, die sich am selben Verzeichnis treffen, produzieren Konflikte, die ein einzelnes Kind so nicht gebaut hätte. Drittens der Selbstauskunfts-Glaube: Das Kind meldet Erfolg, die Datei ist leer oder der Upload ging ins Leere, deshalb zählt nur das eigene Nachlesen. Viertens der Tiefe-Griff: Kinder selbst wieder Kinder bauen lassen, ohne dass es die Aufgabe verlangt, und der Baum wächst schneller als die Kontrolle. Keines dieser Muster kostet ein neues Werkzeug, Delegation ist ein Handwerk und kein Knopf.

Vier Grenzen bleiben, sonst wäre es Werbung. Erstens: Asynchrone Kinder erhöhen die Parallelität, nicht die Verlässlichkeit, ein Kind, das eine Quelle falsch liest, liest sie asynchron genauso falsch. Zweitens: Die Verifikationslast wandert zum Eltern-Agenten und am Ende zum Menschen, denn nur er verantwortet die Außenwirkung. Drittens: Die Latenz verschwindet nicht, sie verteilt sich anders, der Chat blockiert nicht mehr, das Ergebnis braucht trotzdem seine Zeit. Viertens: Die Kosten laufen mit, ein Kind ist ein eigener Kontext mit eigenen Requests, drei Kinder kosten mehr als eines, auch wenn sie schneller fertig sind. Wer diese Grenzen kennt, bekommt ein brauchbares Werkzeug, wer sie ignoriert, baut sich einen teuren Zufallsgenerator.

Ich bin Marcel, Grafikdesigner und Betreiber der d4sn3st-Seiten. Ich betreibe das HUNTER-Cyberdeck auf einem gebrauchten Google Pixel 6a, ohne Root, mit Cloud-Modellen und Terminal-Orchestrierung. Die RAM-Messung in diesem Beitrag ist eine eigene Momentaufnahme vom 05.09.2026, aufgenommen mit ps als RSS-Summe und ohne definierte Workerlast. Die Angaben zur Delegation wurden mit Hermes v0.20.6 am 05.09.2026 gegen die offizielle Doku geprüft. Zuletzt fachlich geprüft: 05.09.2026.