Agent of Empires: tmux-Sitzungen als Steuerzentrale für Coding-Agenten

Welches Problem AoE löst und für wen es gedacht ist

Ein einzelner Coding-Agent in einem Terminal ist unproblematisch. Sobald mehrere parallel laufen, entsteht ein Verwaltungsproblem: welcher Agent arbeitet gerade, welcher wartet auf eine Eingabe, welcher ist mit einem Fehler ausgestiegen, und in welchem Verzeichnis läuft er überhaupt. Agent of Empires setzt genau dort an. Das Projekt beschreibt sich selbst als Sitzungsmanager für KI-Coding-Agenten unter Linux und macOS, der Agenten parallel über Branches laufen lässt, sie aus der TUI oder einem Browser überwacht und jeden in einer persistenten Sitzung mit optionaler Worktree- und Container-Isolation hält. Die Zielgruppe sind also Entwicklerinnen und Entwickler, die mehrere Agenten gleichzeitig betreiben und den Überblick behalten wollen, nicht jemand, der einen einzelnen Assistenten gelegentlich befragt. Die Unterstützung reicht laut Beschreibung von Claude Code und OpenCode über Mistral Vibe, Codex CLI, Gemini CLI, Pi.dev und Copilot CLI bis zu Factory Droid Coding. Welche davon auf der eigenen Maschine tatsächlich vorhanden und nutzbar sind, beantwortet der Befehl aoe agents; das README verweist für die aktuelle Liste ausdrücklich auf diesen Befehl statt auf eine statische Aufzählung.

tmux als Fundament und die Grenze zwischen Sitzung und Prozess

Der Mechanismus ist bewusst unspektakulär: Jeder Agent läuft in einer eigenen tmux-Sitzung. Das README formuliert die Konsequenz so, dass die Agenten weiterlaufen, wenn man die TUI schließt, die SSH-Verbindung trennt oder das Terminal abstürzt. Beim erneuten Start von aoe findet man den Zustand wieder vor, in dem man ihn verlassen hat. Sitzungen verschwinden nur, wenn sie ausdrücklich gelöscht werden. Das ist keine eigene Prozessverwaltung, sondern eine Nutzung dessen, was tmux ohnehin tut, weshalb tmux auch als erforderliche Voraussetzung genannt wird. Wer bereits mit tmux arbeitet, kann jede AoE-Sitzung direkt mit tmux attach übernehmen; die Abstraktion ist durchlässig. Der Preis dafür ist, dass AoE ohne tmux nicht funktioniert und dass die Semantik von Sitzungen und Fenstern durchschlägt, wenn man sich in tmux auskennt. Die wichtigste Tastenkombination bleibt deshalb Ctrl+b d, mit der man aus einer Sitzung wieder in die TUI zurückkehrt. Wer diese Bindung nicht kennt, hält AoE schnell für hängend, obwohl nur eine tmux-Sitzung aktiv ist.

Was AoE über tmux hinaus hinzufügt

Auf die Frage, worin der Unterschied zur direkten tmux-Nutzung liegt, nennt das README eine Reihe von Ergänzungen: agentenbewusste Statuserkennung mit den Zuständen running, waiting, idle und error, Git-Worktree-Verwaltung, Docker-Sandboxing, ein Web-Dashboard, Zugriff vom Telefon aus und einen Diff-Viewer. Der Status ist der eigentlich interessante Teil, weil er die Frage beantwortet, die tmux selbst nicht beantwortet: Ein tmux-Fenster sieht gleich aus, egal ob der darin laufende Agent arbeitet, auf eine Freigabe wartet oder mit einem Fehler beendet wurde. Wie die Erkennung im Einzelnen funktioniert, geht aus dem vorliegenden Material nicht hervor; das README nennt das Ergebnis, nicht den Mechanismus. Wer sich darauf verlassen will, sollte das im eigenen Betrieb prüfen, weil Fehlklassifikationen genau die Information entwerten, für die man das Werkzeug einsetzt. Neben der Statuserkennung stehen Benachrichtigungen, Profile, Repo-Hooks und eigene Agenten-Befehle. Die Isolation über Git-Worktrees ist für parallele Arbeit an demselben Repository der praktischste Teil, weil jeder Agent auf einem eigenen Branch arbeiten kann, ohne dass sich unfertige Änderungen gegenseitig stören.

Installation und erste Befehle

Das README nennt tmux als zwingende Voraussetzung und Docker als optional für Sandboxing. Installiert wird über ein Skript, das per curl geholt und an bash übergeben wird, über Homebrew mit brew install aoe, über Nix mit nix run github:agent-of-empires/agent-of-empires oder aus dem Quelltext mit git clone, gefolgt von cargo build --release. Der Einstieg besteht aus drei Befehlen: aoe startet die TUI, aoe add --cmd claude legt eine Sitzung an, die Claude Code ausführt, und aoe serve startet das Web-Dashboard. In der TUI zeigt die Taste ? die Hilfe, und die Informationsleiste am unteren Rand blendet die jeweils verfügbaren Tastenkombinationen ein. Für die Entwicklung sind cargo build, cargo test, cargo fmt und cargo clippy dokumentiert, dazu cargo build --features web. Diese Feature-Flag-Angabe ist ein konkreter Hinweis darauf, dass die Web-Oberfläche nicht in jedem Build enthalten ist; wer aoe serve nutzen will, muss den Build entsprechend wählen. Über SSH funktioniert AoE laut FAQ, weil die Sitzungen Verbindungsabbrüche überstehen und man nach dem Wiederverbinden einfach erneut aoe ausführt.

Plattformgrenzen und Fälle, in denen AoE das falsche Werkzeug ist

Die deutlichste Einschränkung steht in der FAQ: Windows wird nur über WSL2 unterstützt, weil AoE von tmux und POSIX-Prozessverwaltung abhängt. Native Windows-Unterstützung gibt es nicht, und daran ändert auch die Web-Oberfläche nichts, denn der Server läuft auf der Linux- oder macOS-Seite. Ein zweiter Grenzfall ist die Anzahl der Agenten. Die gesamte Argumentation des Projekts setzt voraus, dass mehrere Agenten parallel laufen und überwacht werden müssen. Wer einen Agenten in einem Terminal startet, ihm bei der Arbeit zusieht und ihn danach beendet, bekommt durch AoE eine zusätzliche Abstraktionsebene ohne Gegenwert; tmux allein deckt diesen Fall bereits ab. Drittens ist der Statuserkennung nicht ohne Weiteres zu trauen, solange man nicht weiß, wie sie arbeitet. Wenn der Status falsch als idle gemeldet wird, während der Agent auf eine Eingabe wartet, entsteht genau die Situation, die das Werkzeug verhindern soll. Und schließlich ist die Container-Isolation optional und damit eine bewusste Entscheidung: Ohne sie laufen die Agenten mit den Rechten des eigenen Benutzers im eigenen Dateisystem.

Alternative: tmux direkt oder ein anderer Agenten-Deck

Die naheliegende Alternative ist tmux ohne Aufsatz. Der Unterschied liegt nicht in der Persistenz, die beide bieten, sondern in der Auswertung: tmux kennt keine Agenten, keine Zustände und keine Worktrees. Man kann sich mit eigenen Skripten behelfen, die Fensterinhalte auslesen, aber genau diese Arbeit nimmt AoE einem ab. Ein zweiter Bezugspunkt ist agent-deck, das im Abschnitt Acknowledgments als Inspiration genannt wird und in Go mit Bubble Tea geschrieben ist. Der Unterschied im Ansatz ist damit ein anderer Technologie-Stack und eine andere Oberflächenbibliothek; ob der Funktionsumfang vergleichbar ist, lässt sich aus dem vorliegenden Material nicht beurteilen, und das README behauptet es auch nicht. Wer Rust im Werkzeugkasten hat und den Code selbst anpassen oder erweitern will, hat bei AoE den kürzeren Weg, weil cargo build, cargo test und cargo clippy dokumentiert sind und die Sprache des Projekts Rust ist.

Wartung, Release-Takt und Lizenz

Das Repository ist nicht archiviert, der letzte Push datiert vom 9. September 2026. Die drei jüngsten Releases v1.15.3, v1.15.2 und v1.15.1 liegen zwischen dem 28. August und dem 2. September 2026, also innerhalb weniger Tage. Der Versionsstand v1.15.x deutet auf eine Reihe vorangegangener Iterationen hin; das Material enthält keine Angaben darüber, wie lange das Projekt schon existiert oder wie viele Personen daran arbeiten. Genannt werden eine Community und Unterstützung durch Mozilla.ai, dazu wöchentliche Office Hours dienstags um 9:00 Uhr ET im Discord. Ein öffentliches Projektboard dient als Roadmap. Für die Wartung bedeutet das: Es gibt einen sichtbaren Release-Rhythmus und einen Kommunikationskanal, aber keine Zusage über langfristige Unterstützung. Wer AoE produktiv einsetzt, sollte die Release-Häufigkeit als Hinweis darauf lesen, dass sich Befehle und Konfiguration zwischen Versionen ändern können, und vor einem Update die Release Notes prüfen. Lizenziert ist das Projekt unter MIT. Eine Ausnahme ist dokumentiert: Die Datei src/tui/hyperlink.rs enthält Code, der unter der Apache-Lizenz 2.0 von herdr abgeleitet wurde, mit Verweis auf THIRD_PARTY_NOTICES.md. Wer den Code weiterverbreitet, sollte diese Datei und die dort gemachten Angaben berücksichtigen; eine rechtliche Bewertung kann dieser Text nicht leisten.

Wann sich die Einrichtung lohnt

Der Aufwand für die Einrichtung ist gering: tmux installieren, aoe über Homebrew, Nix oder das Installationsskript beziehen, mit aoe add --cmd <agent> die ersten Sitzungen anlegen. Der Nutzen skaliert mit der Anzahl paralleler Agenten und mit der Häufigkeit, mit der man von einem anderen Gerät nachsehen will. Wer ohnehin schon mehrere tmux-Fenster von Hand beschriftet und zwischen ihnen wechselt, tauscht diese Gewohnheit gegen eine Statusanzeige und ein Web-Dashboard ein. Wer nur gelegentlich einen Agenten startet, behält besser sein Terminal. Vor dem produktiven Einsatz sind drei Dinge konkret zu prüfen: ob tmux in der erwarteten Version vorhanden ist, welche Agenten aoe agents auf der Zielmaschine tatsächlich findet, und ob der Build die Web-Funktion enthält, falls aoe serve genutzt werden soll. Diese drei Punkte entscheiden darüber, ob AoE die versprochene Rolle übernimmt oder nur eine weitere Schicht zwischen dem Benutzer und einem Terminal ist.

Redaktionelles Fazit

Sinnvoll ist AoE für alle, die mehrere CLI-Agenten parallel in getrennten Branches betreiben und von unterwegs oder über SSH nachsehen wollen, was gerade läuft. Wer einen einzigen Agenten in einem Terminal nutzt, gewinnt wenig gegenüber tmux allein. Vor der Einführung ist zu prüfen, ob tmux installiert ist, ob die Container-Runtime der Wahl unterstützt wird und ob die Web-Oberfläche über die Feature-Flag-Kompilierung verfügbar ist; die Liste der erkannten Agenten liefert aoe agents auf der Zielmaschine.

Offizielle Quellen

1. agent-of-empires/agent-of-empires on GitHub
2. License: MIT
3. Project website
4. README
5. Releases