Ein Engineer im Grok Bot Team hat es geschafft, von 15 gleichzeitig laufenden Cloud-Agents auf über 200 zu skalieren.
Nicht mit 200 Bots. Sondern mit sechs.
Fünf Engineer-Bots, die jeweils eine eigene Domäne verantworten, und ein Ops-Bot, der keine einzige Zeile Code schreibt. Im selben Team hat Lauren Tan in einem Monat über 2.000 PRs gemergt.
Genau das übersehen die meisten. Ihr erster Bot funktioniert, also fügen sie einen zweiten hinzu, dann einen fünften, dann einen zehnten. Am Ende haben sie zehn Chat-Fenster und einen neuen Vollzeitjob: sie alle zu lesen.
Ein Haufen Bots ist nur Personal. Ein Team braucht Struktur. Dieser Guide liefert genau diese Struktur – basierend darauf, wie die Leute bei xAI selbst arbeiten.
Die 30-Sekunden-Zusammenfassung
- Ein Bot ist eine Neueinstellung. Ein Team braucht fünf Dinge: eine zentrale Anlaufstelle, Spezialisten, ein Board, eine Uhr und ein Gate.
- Du sprichst mit einem einzigen Bot. Er verteilt die Arbeit an den Rest.
- Jeder Spezialist verantwortet eine Domäne und pflegt sein eigenes Gedächtnis.
- Die Arbeit lebt auf einem Board, nicht im Chat.
- Routinen treiben die Arbeit voran, während du schläfst. Freigaben entscheiden, was das System verlassen darf.
- Die Teams bei xAI selbst setzen das mit etwa sechs Bots um. Nicht mit sechzig.
Teil 1. Wann du Bot Nummer zwei einstellst
Nicht dann, wenn der erste ausgelastet ist. Bots werden nicht so „beschäftigt" wie du.
Kevin Niparko leitet als PM bei SpaceXAI ein komplettes Bot-Team. Sein Guide nennt drei Gründe, Arbeit auf mehrere Bots aufzuteilen: Referenzierbarkeit („Du weißt, wer was macht"), Parallelität und isoliertes Gedächtnis.
Der dritte Punkt ist die eigentliche Antwort. In seinen Worten:
Der Chief of Staff sollte keine Computer-Use-Evals debuggen.
Stelle Bot Nummer zwei ein, wenn das Gedächtnis eines Bots anfängt, zwei Jobs gleichzeitig zu machen.
Du wirst es spüren, bevor du es benennen kannst. Der Inbox-Bot antwortet plötzlich im Tonfall deines Code-Reviewers. Kalenderpräferenzen sickern in Research-Briefings durch. Du musst jede Nachricht damit beginnen, dem Bot zu erklären, welchen Hut er heute trägt.
Lingxi Li, die Grok Bot mit Grok Bot baut, sagt aus Engineering-Sicht dasselbe: Bots „liefern die besten Ergebnisse, wenn sie sich auf eine einzige Domäne konzentrieren".
Der Test: Skill oder Bot?
Die Docs definieren einen Skill als „eine wiederverwendbare Sammlung von Anweisungen, wie eine Aufgabe erledigt wird". Deine privaten Skills sind eine Bibliothek, die alle deine Bots gemeinsam nutzen.
Eine neue Aufgabe ist also ein Skill. Eine neue Domäne mit eigenem Gedächtnis ist ein Bot. Wenn du die Domäne nicht in drei Worten benennen kannst, brauchst du noch keinen weiteren Bot.
Teil 2. Die fünf Bausteine eines Teams
1. Die zentrale Anlaufstelle
Ein Bot, mit dem du tatsächlich sprichst. Josh Kims Guide nennt ihn Bot Boss, die „einheitliche Schnittstelle". Niparko nennt ihn Chief of Staff und beschreibt ihn in zwei Sätzen: „Der einzige Generalist. Bleibt still, wenn sich nichts geändert hat."
Die Anlaufstelle verteilt. Sie baut nicht. Kims eigener Prompt formuliert es unmissverständlich: „you are hub and spoke EA, not a builder and not an auditor".
Ein Prompt zum Kopieren:
Du bist mein Chief of Staff und der einzige Bot, mit dem ich spreche. Leite jede Anfrage an den zuständigen Spezialisten weiter, sammle das Ergebnis ein, prüfe es gegen meine ursprüngliche Anforderung und berichte mir in fünf Zeilen. Bleib still, wenn sich nichts geändert hat.
2. Die Spezialisten
Niparkos Aufstellung: ein Chief of Staff, eine Engineering Managerin namens Emily, fünf Engineer-Bots, ein Datenanalyst, ein PM-Bot und ein Recruiter. Lis Aufstellung: fünf Engineer-Bots, aufgeteilt nach Oberfläche (iOS, Desktop, Infrastruktur, Android, das Harness), plus Jenny, Head of Operations.
Schau dir an, was beide Teams gemeinsam haben. Einen Manager, der die Arbeit nicht selbst macht. Emily zerlegt Aufgaben, delegiert und prüft das Ergebnis gegen das Ziel. Jenny onboarded neue Bots und führt Postmortems durch. Keine von beiden schreibt Code.
Für ein erstes Team reichen drei Spezialisten. Eric Zakariasson begrenzt jeden Projekt-Channel auf maximal sechs Bots und nennt diese Grenze „nur eine willkürliche Zahl". Willkürlich – aber richtig.
3. Das Board
Chats scrollen einfach weg. Ein Team braucht einen Ort, an dem der Arbeitsstand lebt.
Lis Team nutzt einen gemeinsamen Tracker in Notion. Alle 30 Minuten prüfen die Bots jeden PR auf fehlgeschlagene CI-Pipelines, Review-Kommentare und Merge-Konflikte. Probleme wandern zurück auf „Working". Saubere Tickets gehen auf „Ready for Review".
Zakariasson arbeitet mit zwei Datenbanken, Projects und Tasks, und einem Channel pro Projekt. Hängt ein Bot fest, markiert er seine Aufgabe als „Blocked" und pingt den Menschen an. Den Rest der Zeit schaut der Mensch einfach nur zu, wie sich die Karten bewegen.
Der beste Satz aus allen Guides stammt von ihm:
Das Faszinierende daran ist: Je mehr ich darauf aufbaue, desto stärker ähnelt es einem System, das ursprünglich für Menschen gebaut wurde.
4. Die Uhr
Eine Routine „sagt einem Bot, wann er einen Workflow ausführen soll", so die Docs. Jeder Bot kann bis zu 50 davon speichern, sie können alle fünf Minuten feuern – und sie laufen weiter, auch wenn dein Laptop zugeklappt ist.
Lis Uhr sieht so aus: Um 3 Uhr morgens laufen die nächtlichen Audits: Dead Code, Ladezeit, Bundle-Größe. Um 5 Uhr morgens führt Jenny ein 1:1 mit jedem Bot im Team, geht das Playbook durch und deckt Blocker auf. Das berichtete Ergebnis: Die Bots „vergessen meine komplexen Workflows selten, selbst nach vielen Wochen".
Dieses 5-Uhr-Standup ist die unterschätzteste Idee im ganzen Setup. Der Kontext eines Bots ist begrenzt. Wiederholung ist das Mittel, mit dem ein Team seine Standards hält – und hier übernimmt ein Bot die Wiederholung, damit du es nicht tun musst.
5. Das Gate
Niparko darüber, wo weiterhin ein Mensch gebraucht wird:
Ich behalte weiterhin die finale Freigabe für alle ausgehenden E-Mails, jegliche Einkäufe oder destruktive Aktionen wie Löschvorgänge.
Kim geht noch weiter. Sein Inbox-Bot ist Read-only und sendet nichts, bis in genau diesem Moment das Wort „send" getippt wird.
Zwei Fakten aus den Docs, die verändern, wie du dein Gate designst:
- Hintergrundfreigaben verfallen. Wenn eine Routine oder ein anderer Bot eine Aktion auslöst, die dein Okay braucht, verfällt die Anfrage nach etwa 10 Minuten und die Aktion wird nicht ausgeführt. Ein Job um 3 Uhr morgens, der auf dich wartet, wird beim Warten sterben. Entscheide vorher: Entweder schreibst du eine Allow-Regel dafür, oder die Routine stoppt bei einem Entwurf.
- Alle deine Bots teilen sich einen Cloud-Computer. Dateien, Browser-Sessions und Logins stehen dem gesamten Team zur Verfügung. Die Docs sagen es direkt: Behandle separate Bots nicht als Sicherheitsgrenze.
Du teilst Bots auf wegen Fokus und Gedächtnis. Sicherheit bekommst du durch das Gate.
Teil 3. Bau es in fünf Tagen
Tag 1. Die zentrale Anlaufstelle. Befördere deinen ersten Bot mit dem Prompt oben zum Chief of Staff. Ab jetzt ist er der einzige Chat, den du öffnest.
Tag 2. Nach Gedächtnis aufteilen. Liste alles auf, was Bot eins heute tut, und gruppiere die Liste nach Domänen. Die zwei größten Gruppen werden deine ersten beiden Spezialisten. Die Einstellungen eines Bots bestehen aus drei Feldern: Name, Title, Description. Fülle sie aus wie eine Stellenanzeige.
Tag 3. Das Board. Eine Tabelle mit Task, Owner und Status: Todo, Working, Blocked, Ready for Review, Done. Dann sag jedem Bot dasselbe: Nichts ist erledigt, bis das Board es sagt, und wenn du feststeckst, setze den Status auf „Blocked" und ping mich an.
Tag 4. Die Uhr. Drei Routinen für den Start: ein Morgen-Board vom Chief of Staff, ein 30-Minuten-Sweep des Boards und ein nächtlicher Audit. Führe jede zuerst als Test mit harmlosem Input aus. Die Docs warnen, dass ein Testlauf „echte Arbeit ausführt".
Tag 5. Das Gate. Schreibe die Ask-first-Regeln: Senden, Kaufen, Löschen, Veröffentlichen, alles in Production. Füge eine Allow-Regel für die Aktion hinzu, die du bereits fünfmal hintereinander manuell freigegeben hast.
Dann lass das Ganze eine Woche in Ruhe, bevor du Bot Nummer vier einstellst.
Fünf Fehler, die ein Bot-Team killen
Die Klon-Armee. Fünf Kopien desselben Generalisten. Kein isoliertes Gedächtnis, keine Domäne, kein Mehrwert. Du hast die Kosten multipliziert und das Chaos behalten.
Der Gruppenchat ohne Board. Bots können sich gegenseitig Nachrichten schicken und triggern. Ohne gemeinsamen Zustand ist das ein Meeting, keine Arbeit.
Der bauende Chef. Eine Anlaufstelle, die anfängt, Aufgaben selbst zu erledigen. Sobald dein Chief of Staff den Code schreibt, verteilt niemand mehr und niemand kontrolliert.
Der offene Listener. Ein Trigger auf jede neue Nachricht. Die Docs warnen genau davor, weil es Rauschen erzeugt und Usage verbrennt. Matche eng.
Die Sicherheits-Illusion. Der Glaube, der Finance-Bot könne nicht sehen, worin sich der Research-Bot eingeloggt hat. Derselbe Computer, dieselben Sessions.
Das Organigramm ist das Produkt
Die Leute, die Grok Bot bauen, haben keine neue Architektur für ihre eigenen Teams erfunden. Sie haben die älteste wieder aufgebaut, die es gibt: einen Manager, Spezialisten, ein Board, ein Standup und eine Freigabe.
Der Unterschied ist, dass dieses Team sein Standup um 5 Uhr morgens abhält – und niemand beschwert sich.
Starte mit der zentralen Anlaufstelle. Füge einen Spezialisten hinzu. Hol keinen dritten dazu, bevor das Board existiert.
P.S. Falls du noch keinen ersten Bot eingestellt hast, starte mit meinem vorherigen Guide: „Grok Bot: How to Hire Your First AI Employee". Alles, was hier zitiert wird, stammt aus den öffentlichen Grok Bot Guides und Docs von xAI.
