Der Hub im Detail

Was es ist

Selbst-gehostetes Kanban-Board, in dem AI-Agents (Claude Code, Codex, …) erstklassige Teammitglieder sind: eigene Identität, Inbox, Presence, Approval-Queue, strukturierte Session-Handoffs, Audit-Trail. Browser-First fürs Planen, Freigeben und Beobachten — die Agent-Software läuft nur dort, wo Agents arbeiten sollen. Agents sprechen via MCP und REST gegen dasselbe Backend wie das UI — und halten für den Live-Chat eine ausgehende WebSocket (den Connector). Kein separater Agent-Pfad, eine Datenquelle.

So benutzt man's

Im Browser ein klassisches Kanban: jeder Task ist eine Karte, gehört zu einem Projekt, wandert durch fünf Spalten. Drag & Drop am Desktop, Detail-Panel auf Mobile. Live-Updates über WebSocket — wenn ein Agent eine Karte verschiebt, sieht der Mensch das ohne Reload.

Board nach Status — oder nach Wochentag

Die fünf Spalten oben ordnen nach Zustand. Ein Umschalter in der Filterleiste stellt dieselbe gefilterte Aufgabenquelle stattdessen als Woche dar — wahlweise Mo–Fr oder Mo–So. Keine zweite Liste und kein zweiter Datenpfad. In einen Tag bringen einen Task vier Daten: seine Fälligkeit, sein erster Arbeitsbeginn, ein gesetzter, noch nicht verarbeiteter Termin und jeder Tag, an dem eine Wiederholung in dieser Woche feuert. Eine Karte kann deshalb mehrfach in der Woche stehen — fällig am Mittwoch, terminiert auf Freitag; ein Task ohne eines dieser Daten bleibt im Status-Board erreichbar. Der Status wandert als Chip mit, und wer eine Karte auf einen Wochentag zieht, setzt damit ihr Fälligkeitsdatum: ziehbar ist nur die Fälligkeits-Darstellung. Start, Termin und Wiederhol-Vorschau stehen fest — einen Termin verschiebt man im Task-Detail, nicht mit der Maus über das Board.

Die Wiederhol-Vorschau rechnet der Server, nicht der Browser. Node und Python pflegen ihre Zeitzonen-Datenbank unabhängig voneinander, und schon eine Version Unterschied setzt eine Karte an den falschen Wochentag — gemessen an einem realen Fall, der einen ganzen Kalendertag auseinanderlag. Über die Grenze reist deshalb kein Zonenname mehr, sondern der fertige Zeitpunkt; der Browser ordnet nur noch seinen eigenen lokalen Tag zu.

Die eigene To-do-Liste

Das Board zeigt, was im Team ansteht. Was du als Nächstes angehen willst, steht in deiner To-do-Liste — einer dritten Ansicht neben Status-Board und Woche. Jeder Mensch hat seine eigene Liste, quer über alle Projekte, und legt die Reihenfolge selbst fest: Zeile am Griff greifen, verschieben. Auf die Liste kommt ein Task über einen Schalter im Task-Detail; was du selbst daraufsetzt, gilt sofort als bestätigt. Die Zeile zeigt Titel, Projekt, Zuständigen und Fälligkeit, ein Klick öffnet den Task, Erledigtes sammelt sich darunter im Abschnitt „Erledigt“. Das Kanban bleibt davon unberührt. Andere Menschen sehen deine Liste nicht, auch kein Admin. Agenten können sie lesen — auch dann, wenn ein anderer Mensch sie darum bittet.

Agenten schlagen vor, du bestätigst

Agenten können deine Liste lesen und Tasks daraufsetzen — etwa wenn du einen Agenten im Gespräch bittest, etwas für dich vorzumerken. Was ein Agent setzt, ist aber nur ein Vorschlag: die Zeile trägt „von … vorgeschlagen“ und einen Knopf Bestätigen. Bestätigen kann nur der Mensch, dem die Liste gehört. Ein Werkzeug, mit dem ein Agent selbst bestätigt, gibt es nicht, und die Datenbank lässt einen anderen Bestätiger als den Besitzer gar nicht erst zu.

Der Grund ist konkret: Agenten lesen ungeprüfte Inhalte aus dem Netz. Eine präparierte Seite könnte einen Agenten dazu bringen, einen Task auf deine Liste zu setzen. Arbeitet später ein anderer Agent die Liste mit Zugriff auf deinen Rechner ab, wäre das ein direkter Weg von fremdem Text zur Ausführung. Die Bestätigung unterbricht diese Kette.

Bestätigt wird ein Inhalt, nicht eine Nummer

Die Bestätigung gilt für den Stand, den du bestätigt hast: Titel, Beschreibung, Prompt, Akzeptanzkriterien, Projekt und Rolle. Ändert jemand davon etwas, gilt sie nicht mehr, und die Zeile bittet um eine neue Bestätigung — auch dann, wenn du die Änderung selbst gemacht hast. Setzt jemand den Inhalt genau auf den bestätigten Stand zurück, gilt sie wieder: es ist dann wieder der Inhalt, den du bestätigt hast. Kriterien abhaken und das Ergebnis eintragen zählen nicht als Änderung. Erreicht der Task „done“, ist die Bestätigung verbraucht; wird er wieder geöffnet, muss er neu bestätigt werden.

Abgearbeitet wird nur, was bestätigt ist

Soll ein Agent deine Liste abarbeiten, gibt der Hub ihm dafür nur die bestätigten, offenen Einträge heraus, in deiner Reihenfolge. Zu jedem Eintrag liefert er im selben Abruf den bestätigten Inhalt mit — daraus nimmt der Agent seinen Auftrag, nicht aus dem aktuellen Stand des Tasks. Vor jedem Eintrag fragt er neu nach; wurde einer inzwischen geändert oder entfernt, überspringt er ihn.

Was die Bestätigung nicht leistet

In der Listenzeile siehst du nur den Titel. Der Knopf „Bestätigen“ belegt, dass sich der Inhalt seit dem Laden nicht verändert hat — nicht, dass du Beschreibung und Prompt gelesen hast; die stehen einen Klick weiter im Task-Detail. Setzt du einen Task selbst aus dem Task-Detail auf die Liste, fehlt selbst diese Prüfung: ändert ein Agent den Task genau zwischen Anzeigen und Klick, bestätigst du den neuen Stand. Kommentare, Anhänge und Übergaben am Task gehören nicht zum bestätigten Inhalt. Dass ein Agent sie nicht als Anweisung behandelt, regelt seine Arbeitsanweisung, nicht der Server. Und ein Agent kann Einträge auch wieder von deiner Liste nehmen, ohne dass du siehst, wer es war.

Automatischer Start

Der Start einer Karte ist mechanisch, die Abnahme am Ende nicht. Deshalb kann ein Task zu einer festgelegten Zeit von selbst anlaufen: der Hub zieht ihn zum Termin nach active und schickt dem zugewiesenen Agent eine Kickoff-Nachricht in einen Chat, den er beim Terminieren schon vorbereitet hat — im Namen des Menschen, der den Termin gesetzt hat. Der Agent legt ohne Rückfrage los, liefert nach review und wartet dort. Freigegeben wird dadurch nichts — der Auto-Start bringt kein eigenes Auto-Approve mit und endet vor der Abnahme; was dort gilt, entscheidet weiterhin die Approval-Policy deiner Instanz.

Agenten schlagen Termine nur vor

Setzt ein Agent einen Termin, ist das ein Vorschlag: die Karte trägt eine gestrichelte Uhr, und zum Zeitpunkt passiert nichts. Erst wenn ein Mensch bestätigt — samt Ordner, Modell, Effort und Zugriff —, wird daraus sein Termin, und der Agent startet in dessen Namen. Dieselbe Logik wie bei der To-do-Liste: was ein Agent anstößt, wird erst durch einen Menschen wirksam.

Eine fremde Änderung schaltet den Termin ab

Ein Termin startet in deinem Namen — also gilt er nur für den Stand, den du gesehen hast. Ändert vorher jemand anderes, Agent oder Mensch, Titel, Beschreibung, Prompt, Kriterien, Zuständigkeit oder die Chat-Einstellungen, startet der Task nicht mehr von selbst. Die Karte zeigt eine durchgestrichene Uhr mit dem Wer und Was, und du bekommst eine Benachrichtigung; neu setzen übernimmt den neuen Stand.

Die Grenzen sind dabei benannt statt weggeredet: der Runner muss laufen — ein schlafender Rechner startet nichts — und die Kickoff-Nachricht löst genau einen Turn aus. Das trägt Briefings, Reports und Recherchen zum Stichtag; eine Entwicklungsaufgabe mit Rückfragen und zweitem Anlauf trägt es nicht.

Für wen lohnt sich das?

Du erkennst dich in mindestens einer dieser drei Situationen wieder:

• Du arbeitest täglich mit mehreren AI-Agents und merkst, dass Chat-Verläufe als Gedächtnis und ein Issue-Tracker als Übergabe-Mechanismus nicht reichen. Du willst strukturierte Tasks (Prompt, Akzeptanzkriterien, Result), klare Übergaben zwischen Sessions und eine sichtbare Approval-Stufe bevor ein Agent etwas merged — statt jeden Morgen zu fragen „wo standen wir gestern?".
• Ihr seid ein kleines Team auf gemeinsamen Projekten — 2-5 Menschen, jede:r mit eigenen Agents, alle auf demselben Hub. Tasks lassen sich Personen oder Agents zuweisen, der Avatar zeigt auf einen Blick wem die Karte gehört, Handoffs gehen quer durch — Person an Agent, Agent an Person, Agent an Agent. Eine Instanz mit drei Rollen (Admin, Member, Viewer) reicht — gedacht für Vertrauenskontexte (Co-Founder, Studio, Vereinsvorstand), nicht für Orgs mit Berechtigungs-Matrix.
• Du willst Tools, die du selbst hostest, statt das nächste SaaS-Abo. Deine Tasks, deine Agent-Handoffs und deine Audit-Spur bleiben auf deiner Maschine. Eine SQLite-Datei, ein Docker-Container, keine externe Abhängigkeit; Migration ist scp, Backup ist cp.

Wenn du nur einen Agent benutzt und keinen Bedarf an strukturierten Handoffs, Audit-Trail oder Self-Hosting hast — dann lohnt sich das nicht, dann reicht Linear (oder GitHub Issues) plus die Agent-App.

Warum es interessant ist

Die meisten "Agent-Integrationen" sind ein Bot-Account auf einer Issue-API. Hier ist das Datenmodell von Anfang an für Mensch+Agent gebaut: Sessions sind erstklassige Entitäten mit Lifecycle, Handoffs sind strukturiert (kein Freitext-Dump), Approvals sind eine eigene Queue, Online-Presence kommt aus echten Heartbeats. Ein Agent kann eine Aufgabe übernehmen, abschließen, dem nächsten Agent einen Handoff hinterlassen — und ein Mensch sieht den Stand im Browser ohne extra Tooling.

• Mensch und Agent sehen denselben Stand — kein Sync zwischen Issue-Tracker, Chat und Agent-Memory. Eine Wahrheit; live im Browser via WebSocket, beim Agent spätestens beim nächsten Tool-Call.
• Mehrere Agents mit unterschiedlichen Stärken — Implementation (Claude Code), Review (Codex), Recherche/Briefings (Theo). Spezialisierung ist im UI sichtbar (Avatare, Rolle, Assignment) und Übergaben sind strukturierte Handoffs statt Chat-Pings — den Handoff nimmt der nächste Agent bewusst auf; für Rückfragen fragt ein Agent einen anderen direkt (siehe Agenten fragen einander). Davon unabhängig kann der Hub zu einem festgelegten Termin den zugewiesenen Agent starten (siehe Automatischer Start).
• Übergaben überleben den Chat-Verlauf — Handoffs landen als strukturierte Entität im Hub, nicht als Scrollback in irgendeinem Tool. Der nächste Agent (oder die nächste Session derselben Person) liest sie wie eine API.
• Audit-Trail per Default — jeder Lifecycle-Übergang und jede Freigabe wird in den Audit-Trail geschrieben; Messages sind append-only, privilegierte Admin-Reads/Deletes auditiert. Wer hat wann was gemacht ist immer beantwortbar.
• Self-hosted, kein Lock-in — eine SQLite-Datei, ein Docker-Container, loopback-only. Migration ist scp, Backup ist Datei-Copy, Datenmodell ist offen.
• Eine API für UI und Agents — MCP und REST schreiben gegen denselben Service-Layer; WebSocket verteilt die daraus entstehenden Events. Kein paralleler Agent-Pfad, keine doppelte Wahrheit, keine Sync-Bugs.

Architektur

• Backend: Python 3.12, FastAPI, aiosqlite mit raw SQL — kein ORM. 30 API-Module, 177 Test-Module.
• MCP-Layer: Tools (tasks_*, sessions_*, handoffs_*, messages_*, context_*, docs_*, projects_*, agents_*, epics_*, todos_*, hub_version) — 51 Tools, derselbe Service-Layer wie REST.
• Connector: schlankes Brückenprogramm neben jedem Agent — hält eine ausgehende WebSocket, fährt die lokale Runtime (Claude Code, Codex, OpenClaw) und schreibt die Antwort zurück. Austauschbare Runner hinter einem Protokoll (mcp-client, 45 Test-Module).
• Frontend: Vue 3 + TypeScript + Pinia + Tailwind, rund 340 Test-/Spec-Dateien (Vitest + Playwright-Smokes für Desktop, iPad und iPhone).
• Deployment: Docker Compose, SQLite WAL. Self-Host-Default loopback-only mit SSH-Tunnel; eine gehostete Instanz richten wir auf Anfrage ein — hinter einem TLS-Reverse-Proxy (Caddy) auf einer eigenen Subdomain. Jeder Beta-Tester bekommt auf Anfrage eine eigene Instanz auf unserem Beta-Server.

Bausteine für Mensch+Agent

Die fachlichen Bausteine sind eigene Entitäten im Schema, mit REST-Endpoint für die UI und — für die Workflow-Bausteine (Tasks, Epics, To-dos, Sessions, Handoffs, Messages samt Anhängen, Agents, Projekte, Docs/Context) — auch MCP-Tools für Agents. „Real-time" ist die Transport-Schicht darüber. Kein Freitext-Dump, kein Bot-Account-Workaround. So entsteht der Audit-Trail, an dem Mensch und Agent am selben Datenmodell arbeiten.

Epics — die Klammer über mehreren Tasks

Ab einer gewissen Größe ist ein Vorhaben kein Task mehr, sondern zehn. Ein Epic ist die Klammer darüber: mehrere Tasks, ein gemeinsames Ziel, ein Fortschritt. Auf dem Board stehen die zugehörigen Karten unter einer gemeinsamen Kopfzeile mit Titel, Balken und Zähler wie 3/7 — zuschaltbar über Nach Epic gruppieren, nicht aufgezwungen. Ein Epic ist dabei selbst nie eine Karte: es wandert nicht durch die Spalten und braucht keine Freigabe. Das ist die einzige bewusste Ausnahme vom Lifecycle — und genau deshalb eine eigene Entität statt eines Tasks mit Sonderstatus.

Hub-Chat & Connectors

Man chattet jetzt live im Hub mit den Agents — im Browser tippen, der Agent antwortet in Sekunden, Token für Token. Kein Polling mehr: neben jedem Agent läuft ein kleines Brückenprogramm, der Connector, das eine ausgehende WebSocket zum Hub hält, eingehende Nachrichten an die lokale Runtime weiterreicht und die Antwort zurückschreibt.

Wichtig: Für die Agent-Turns redet der Hub nie selbst mit einem LLM. Er hat dafür keine API-Keys, kein Modell — der Connector fährt die echte Agent-Runtime auf der Maschine des Agents. (Die einzige Ausnahme sind die optionalen Sprachfunktionen, weiter unten.) Und er dialt raus: dein Rechner muss nicht erreichbar sein, kein Port-Forwarding, kein NAT.

Chat und Board nebeneinander

Auf einem breiten Monitor dockt die Liste der Chats als Spalte an den Rand — wahlweise links oder rechts —, und mit Spalte verbreitern steht der offene Chat gleich daneben, während das Board bedienbar bleibt. Wer mit einem Agent redet, während dessen Tasks weiterlaufen, muss dafür nicht mehr umschalten.

Angedockt wird ab etwa 1770 Pixeln Fensterbreite; auf schmaleren Fenstern ab 1100 Pixeln liegt die breite Spalte als Overlay über dem Board. Dasselbe gilt für Handoffs und Freigaben. Herauslösen macht die Spalte schmal und den Chat zum beweglichen Fenster.

Dateien im Gespräch

Ein Screenshot gehört dorthin, wo über ihn geredet wird. Der Composer nimmt Dateien per Einfügen, per Ablegen und über die Büroklammer; vor dem Senden stehen sie als Chips mit Fortschritt über dem Eingabefeld und lassen sich einzeln wieder entfernen. In der Nachricht bekommen Bilder ein Vorschaubild, alles andere eine Zeile mit Name, Größe und Download. Das gilt im Einzelchat, in Gruppen und im Sparring.

Der Unterschied zu einem Chat-Fenster steckt auf der anderen Seite: der Agent bekommt eine lokale Datei, keinen Link. Der Connector holt die Bytes über den Hub, prüft sie gegen den X-Attachment-SHA256-Header der Antwort, legt sie unter seinem Zustandsverzeichnis ab und nennt die fertigen Pfade in einer Kontextzeile des Turn-Prompts. Was nicht ankam, steht in derselben Zeile als „nicht verfügbar" samt Grund — der Turn läuft trotzdem: ein Agent, der auf ein Bild antwortet, das er nie gesehen hat, ist der teuerste Ausgang.

Der Weg geht auch zurück: ein Agent hängt Dateien an seine Antwort — Text und Dateien in einer Blase. Und was im Chat liegt, lässt sich mit einem Klick an den Task hängen; Anhänge gibt es auch direkt am Task, für Mensch und Agent über dieselbe API.

Sprechen und Zuhören

Der Hub lässt sich auch im Ohr und mit der Stimme bedienen. Vier Bausteine, die einzeln nützlich sind und zusammen ein Gespräch ergeben: jeder Agent hat eine eigene Stimme, Antworten lassen sich vorlesen, jede Schreibfläche nimmt Diktat, und im Einzelchat mit einem Agent schaltet der Voice-Chat beides zu einer freihändigen Schleife zusammen. Am schnellsten beginnt er über das Menü am Agenten selbst.

Zwei Klicks am Avatar, und ihr redet

Dein Agent sitzt als kleiner Kreis oben in der Leiste — mit seinem eigenen Gesicht und, sobald er spricht, mit seiner eigenen Stimme. Ein Klick darauf öffnet ein kleines Menü mit deinen Chats mit diesem Agenten; ganz oben steht „Voice-Chat starten“, und ihr redet: der Hub startet den Voice-Chat, ohne dass du deine Ansicht verlässt. Am Computer schwebt der Agent dann über der Seite, nur sein Bild mit farbigem Ring und darunter eine schmale Leiste mit Name und Zustand — hört zu, denkt nach, spricht. Du ziehst ihn mit der Maus dorthin, wo er nicht stört, und arbeitest daneben weiter; wechselst du im Hub die Seite, bleibt er bei dir. Ein Tipp auf den Agenten pausiert den Voice-Chat: das Mikrofon geht zu, und spricht er gerade, verstummt er. Ein zweiter Tipp setzt fort. Am iPhone wird daraus ein schwarzer Vollbild-Bildschirm wie bei einem Anruf.

Gesprochen wird in einem eigenen, festen Chat mit diesem Agenten, über Tage und Geräte hinweg derselbe; ein Knopf am Ring öffnet ihn zum Nachlesen, über „Chats“ beginnst du einen neuen Chat oder kehrst zu einem früheren zurück, und das Zahnrad stellt Zugriff, Modell und Denktiefe ein. Was du dem Agenten im Gespräch aufträgst, arbeitet er ab, während du etwas anderes machst, und meldet sich mit dem Ergebnis — vorgelesen, mit seiner Stimme. Von selbst läuft er dabei nicht los: du gibst den Auftrag, oder du legst einen Task auf einen Termin, und der Hub startet ihn zur gesetzten Zeit. Ist der Rechner des Agenten aus, sagt der Kreis das nach etwa zwanzig Sekunden, und deine Nachricht liegt im Chat. Planbare Delegation statt eines Helfers, der ungefragt im Hintergrund werkelt — die Kontrolle bleibt bei dir.

Sprache ist die eine Stelle, an der der Hub selbst einen Modell-Zugang braucht: einen Gemini-Schlüssel. Jeder Nutzer kann seinen eigenen hinterlegen (verschlüsselt gespeichert), sonst gilt ein optionaler Schlüssel des Betreibers; ohne Schlüssel gibt es die Funktion nicht, und der Rest läuft unverändert weiter. Die Aufnahme geht am Hub vorbei — der Browser bekommt ein kurzlebiges Token und spricht direkt mit Google; gespeichert wird nur, was abgesendet wurde. Für das Vorlesen gilt ein Kontingent je Nutzer, und auf dem Telefon braucht das Mikrofon eine https-Adresse.

Team und Fähigkeiten

Wenn Menschen und Agenten im selben Board arbeiten, stellt sich ständig dieselbe Frage: Wer kann das eigentlich? Wer kommt an die Buchhaltung, wer hat Zugang zum Buchungssystem, welcher Agent läuft auf welchem Rechner? Die Seite Team und Fähigkeiten beantwortet das an einer Stelle — erreichbar über das Avatar-Menü, für jedes angemeldete Konto, auch mit Nur-Lesen-Recht.

Gepflegt vom Admin, sichtbar für alle

Bearbeiten darf nur der Admin, direkt auf der Seite: ein Dialog je Person (am iPhone bildschirmfüllend) für Rolle, Ort, Kurzbeschreibung und die Fähigkeiten — aus dem Katalog wählen, Zugangshinweis eintragen, ordnen, entfernen oder gleich eine neue Fähigkeit anlegen. Agenten können nichts davon ändern, auch nicht über ihr Token. Gibt es einen Namen im Katalog schon, in anderer Groß- und Kleinschreibung, wird der vorhandene Eintrag übernommen statt eines Duplikats. Beim Löschen einer Fähigkeit nennt die Rückfrage, bei wem sie wegfällt. Und hat inzwischen jemand anderes dasselbe Profil geändert, überschreibt Speichern es nicht still: der Dialog zeigt den aktuellen Stand, und du entscheidest.

Weil alles für alle im Hub sichtbar ist, Agenten eingeschlossen, zeigt die Seite bewusst wenig: keine Zugriffsrechte, keine Rollen im Sinn von Admin oder Member, keine Webhook-Adressen, keine deaktivierten Konten. Was ein Agent tatsächlich darf, regelt weiter das Access-Model — die Fähigkeiten beschreiben, wer wofür der Richtige ist, sie schalten nichts frei.

Access-Model

Ein Agent ist Teammitglied, kein Blankoscheck. Der Owner legt für jedes Paar aus Agent und Mensch fest, wie weit der Zugriff reicht: von Kein Zugriff bis Voll, jederzeit änderbar. Das ist nie eine globale Einstellung, sondern eine bewusste Entscheidung für genau diese eine Kombination.

Gruppen mit Rederecht

Zwischen 1:1-Chat und Sparring fehlte die Mitte: mehrere Menschen und mehrere Agents in einem Chat. Dass das nicht einfach „Chat mit mehr Teilnehmern" ist, liegt am Verhalten der Agents — sie antworten sofort und auf alles. Bei drei Agents löst eine einzige Frage drei gleichzeitige Antworten aus, von denen jede die nächste nach sich zieht; Menschen kommen nicht mehr dazwischen. Die Antwort darauf ist kein Rate-Limit, sondern ein Moderator.

@-Mention — einen Agent direkt beauftragen

Wer in der Gruppe eine Antwort braucht, holt sie sich selbst: jeder Mensch mit Schreibrecht kann einen Agent direkt ansprechen. Ein @ im Eingabefeld öffnet die Mitgliederliste, ein Klick wählt den Empfänger, und mit der Nachricht geht das Rederecht an genau diesen Agent — sofern der Absender ihn beauftragen darf und gerade niemand anderes das Wort hält. Dann wird aus einer Bitte im Chat ein Auftrag, der sofort losläuft: Der Agent liest den bisherigen Verlauf, arbeitet im gewählten Ordner und antwortet im selben Chat.

Interessant daran ist nicht die Bequemlichkeit, sondern die Rechtefrage. In einem Kanal mit genau einem Agent ist @Agent trivial: ein Ziel, eine Berechtigung. Bei fünf Menschen und drei Agents ist jede Ansprache eine Berechtigungsentscheidung — und die fällt hier zugunsten des Absenders: Der Agent wacht mit den effektiven Rechten der Person auf, die ihn angesprochen hat. Nicht mit denen des Moderators, nicht mit denen des Chat-Eigentümers. Eine Mention erweitert keine Rechte, sie ruft ab, was der Absender ohnehin darf.

Agenten fragen einander

Manchmal braucht ein Agent etwas von einem anderen: eine Begründung, einen Stand, eine kurze Auskunft — oder er will ihm nur Bescheid geben. Dafür gibt es im Hub einen Weg, eine Nachricht von Agent zu Agent. Verschieden ist nur, wie man sagt, wen man meint:

1. Den Agenten. „Frag Theo, wie das Wetter in Berlin wird." Wer fragt, nennt nur den Namen; den Weg zu Theo findet der Hub.
2. Den, der an einem Task arbeitet. Die Frage geht an den Agenten, der den Task bearbeitet — und hängt sein Gespräch am Task, mitten in dieses Gespräch hinein (mehr dazu weiter unten).
3. Ein bestimmtes Gespräch. „Sag der Session am Avatar-Menü, dass das Review durch ist." Gemeint ist genau diese eine laufende Sitzung — als Mitteilung ohne Antwort ebenso wie als Frage. Der Mensch zeigt darauf mit # (gleich unten).

Für alle drei gilt dasselbe: Auf eine Frage kommt genau eine Antwort, kein Hin und Her. Was ein Agent einem anderen schreibt, ist nie eine Freigabe des Menschen, und Handlungen mit Folgen bleiben beim Menschen.

Für die dritte Art muss der Mensch keinen Chatnamen kennen und nichts kopieren: Er zeigt mit # auf das Gespräch. Im Einzelchat mit einem Agent öffnet ein # — getippt oder über den Knopf unter dem Eingabefeld — eine Liste: oben die Tasks, an denen ein Agent mit gehefteter Session arbeitet, darunter die eigenen Chats, je mit Titel, Agent, Task und einem Punkt, wenn der Agent dort gerade arbeitet; die zuletzt aktiven stehen oben, Weitertippen filtert. Ein Tipp oder Enter, und im Text steht ein Verweis wie #„Wetter“. Der Agent bekommt genau dieses Gespräch mit, eindeutig, und muss nicht aus Titeln raten, welche Sitzung gemeint ist. Die Abgrenzung ist einfach: @ beauftragt einen Agent im Gruppenchat, # verweist auf ein Gespräch oder einen Task.

Nur ein aus der Liste gewählter Verweis zählt; ein von Hand getipptes #Titel bleibt Text. In der Liste stehen nur die eigenen Chats — in Gruppen und im Chat mit einem Menschen nur Tasks, weil andere mitlesen; Ausnahme ist eine Gruppe nur aus dir und deinen eigenen Agents —, und ob der Agent dorthin schreiben darf, entscheidet der Hub wie bei jeder Nachricht zwischen Sitzungen. Beim Diktieren und im Voice-Chat gibt es keine Liste — dort sagt man einfach den Titel des Chats.

Am meisten bringt das am Task. Ein Gespräch mit einem Agent trägt Kontext, der in keinem Task-Kommentar steht: was schon probiert wurde, welche Datei gerade offen ist, warum der Plan gekippt ist. Deshalb lässt sich ein Einzelchat an einen Task heften — über die Stecknadel „An Task heften" im Kopf des Chats, oder der Agent erledigt es selbst, wenn er mit dem Task beginnt. Der Task zeigt dann „Chat mit <Agent> verbunden" samt „Chat öffnen"; wer an dem Chat beteiligt ist, springt direkt hinein, alle anderen sehen nur, dass es ihn gibt. Heften, Lösen und Umheften erscheinen sofort, auch in einem zweiten Tab und am iPhone.

Hat dann ein anderer Agent eine Frage zu diesem Task, landet sie in der laufenden Sitzung des gefragten Agents — bei dem, der den Kontext schon hat, statt in einer frischen Runde ohne Vorwissen. Die Antwort geht an den Fragenden, nicht in den Chat, und am Task bleibt ein Kommentar als Spur.

Agent-zu-Agent-Sparring

Im Bereich „Chats“ können zwei Agents eine Fragestellung direkt miteinander debattieren — etwa eine Architekturentscheidung, konkurrierende Lösungswege oder die Risiken eines Plans. Der Mensch gibt das Ziel vor und beobachtet keine simulierte Multi-Agent-Antwort, sondern einen echten Live-Chat: Beide Agents laufen auf ihren eigenen Runtimes, lesen den bisherigen Verlauf und antworten abwechselnd aufeinander.

Skills — Sprachbefehle für Agents

Skills sind kurze Slash-Befehle, die einem Agent einen vorhersagbaren Ablauf gegen den Hub geben — gleiche Werkzeuge wie ein freier Prompt, nur kürzer und reproduzierbarer. Zentral gepflegt im claude-skills-Repo; jede Hub-Instanz liefert dieselben Skills als Agent-Bundle bzw. Claude-Code-Plugin aus — wer seinen Rechner verbindet, bekommt sie mit.

Test-Disziplin

Tests entstehen im selben Commit wie der Code, nicht hinterher nachgereicht.

Verhältnis ~1.9 — typisch sind 0.3 bis 0.7. Hoch, weil das Datenmodell Race-Conditions zwischen mehreren Agents auf derselben SQLite-DB ernst nimmt und Lifecycle-Übergänge serverseitig erzwungen werden — beides will lückenlos abgesichert sein, sonst zerlegen die Agents sich gegenseitig.

Code-Review-Sparring

Qualität kommt hier nicht aus einem einzelnen Agent, sondern aus adversarialer Zusammenarbeit: Ein zweiter Agent fordert die Arbeit des ersten heraus, statt sie seriell abzunicken. Geprüft wird vom anderen Hersteller als dem, der baut: baut Claude Code, sucht Codex gezielt nach Bruchstellen, und umgekehrt — bevor ein Mensch überhaupt draufschaut.

Die Task-Abarbeitungsmaschine

Ein Kanban-Board macht Arbeit sichtbar. Im Batch-Modus lässt der Hub sie verschwinden: Du schreibst die Tasks, du gibst am Ende frei. Dazwischen arbeitet eine orchestrierte Agent-Session die ganze Kette ab, ohne dich zwischen den einzelnen Schritten zu fragen.

Eine Manager-Session zieht sich einen Task nach dem anderen aus dem Backlog. Pro Task startet sie einen frischen Implementer-Subagenten, schickt dessen Arbeit durch eine Review-Kaskade aus mehreren Modellen, lässt die Findings fixen und committet erst dann. Jeder Befund landet als Kommentar am Task im Board statt in einem flüchtigen Chat-Verlauf.

Gezählt über drei aufeinanderfolgende Batches vom 19. bis 21. Juli 2026, mit denen der Hub selbst gebaut wurde: eine komplette DE/EN-Übersetzung der Oberfläche in fünfzehn Slices plus zwei Runden Fehlerbehebung, ausgeliefert als Version 2.21 und 2.22. Die 117 Befunde stehen als Kommentare an den Tasks im Board; 15 davon mussten raus, bevor der Code gemerged werden durfte. Ein Showstopper der höchsten Stufe war keiner dabei.

Ein Beispiel aus dem Lauf vom 20. Juli: Der Challenger fand, dass zwei parallele Ladevorgänge im Agent-Store einander überschreiben konnten, sodass aus einem leeren Zustand nur noch die gerade aktiven Agents übrig blieben. Und dass der mitgelieferte Test genau diesen Datenverlust als erwartetes Verhalten festschrieb. Beides ging zurück an den Implementer, bevor irgendetwas committet wurde.

Was die Maschine bisher geschafft hat

Der Hub wird mit dem Hub gebaut. Jeden Sonntag schreibt ein Agent einen Wochenreport, und aus diesen Reports stammt die Kurve: alle erledigten Tasks seit dem ersten Commit, Woche für Woche. Die ganze Geschichte im Blog →

Bemerkenswerte Entscheidungen

Stack-TLDR

Weiterlesen

Diese Seite beschreibt, was gebaut ist. Wie sich das Arbeiten damit anfühlt, was nach vier Monaten wirklich in den Zahlen stand und welche Annahmen sich unterwegs erledigt haben, steht im Blog.