Skip to Content
👋 Willkommen bei HowToUseOpenClaw Schnellstart
Erste SchritteTutorial: Mission Control (Multi-Agent)

Der komplette Guide: Mission Control bauen — Wie wir ein AI-Agenten-Squad aufgebaut haben

Das ist die vollständige Geschichte, wie ich Mission Control gebaut habe. Ein System, in dem 10 KI-Agenten wie ein echtes Team zusammenarbeiten. Wenn du dieses Setup nachbauen willst, deckt dieser Guide alles ab.

Wenn du OpenClaw schon kennst, denkst du vielleicht: „Kann ich nicht einfach mehrere OpenClaw-Instanzen laufen lassen?“ Ja. Genau darum geht es. Dieser Guide zeigt dir wie.

Von @pbteja1998  (SiteGPT). Vollständiger Thread: auf X .

Part 1: Warum ich das gebaut habe

Das Problem mit KI-Assistenten

Ich betreibe @SiteGPT , einen KI-Chatbot für Kundensupport. Ich nutze ständig KI. Aber jedes KI-Tool, das ich ausprobiert habe, hatte dasselbe Problem: keine Kontinuität.

Jedes Gespräch fing bei null an. Kontext von gestern? Weg. Die Recherche von letzter Woche? In einem Chat-Thread verloren, den ich nie wiederfinden würde.

Ich wollte etwas anderes. Agenten, die sich merken, woran sie arbeiten. Mehrere Agenten mit unterschiedlichen Fähigkeiten, die zusammenarbeiten. Einen gemeinsamen Workspace, in dem der ganze Kontext lebt. Die Möglichkeit, Aufgaben zuzuweisen und Fortschritt zu verfolgen.

Kurz: Ich wollte, dass KI wie ein Team arbeitet, nicht wie eine Suchmaschine.

Der Ausgangspunkt: OpenClaw

Ich nutzte schon OpenClaw. Es ist ein Open-Source-KI-Agenten-Framework, das als persistenter Daemon läuft. Es verbindet sich mit Claude (oder anderen Modellen) und gibt der KI Zugriff auf Tools wie Dateisystem, Shell-Befehle, Web-Browsing und mehr.

Eine OpenClaw-Instanz gab mir einen KI-Assistenten (Jarvis) an Telegram. Nützlich, aber begrenzt.

Dann hatte ich eine Idee. Was, wenn ich mehrere OpenClaw-Sessions laufen lasse, jede mit eigener Persönlichkeit und Kontext?

Da wurde mir klar: Die Architektur war schon da. Ich musste sie nur orchestrieren.

Part 2: OpenClaw-Architektur verstehen (Das Fundament)

Wenn du ein Multi-Agenten-System bauen willst, musst du verstehen, wie OpenClaw unter der Haube funktioniert. Das ist das Fundament, auf dem alles andere aufbaut.

Was ist OpenClaw?

OpenClaw ist ein KI-Agenten-Framework mit drei Hauptaufgaben:

Erstens: Es verbindet KI-Modelle mit der echten Welt. Dateizugriff, Shell-Befehle, Web-Browsing, APIs.

Zweitens: Es pflegt persistente Sessions. Konversationsverlauf, der Neustarts überlebt.

Drittens: Es routet Nachrichten. Die KI an Telegram, Discord, Slack oder einen beliebigen Kanal anbinden.

Es läuft als Daemon (Hintergrunddienst) auf einem Server, hört auf Nachrichten und antwortet.

Das Gateway

Das Gateway ist der Kernprozess. Es läuft 24/7 auf deinem Server. Es verwaltet alle aktiven Sessions. Es handhabt Cron-Jobs (geplante Aufgaben). Es routet Nachrichten zwischen Kanälen und Sessions. Es stellt eine WebSocket-API zur Steuerung bereit.

Start mit:

openclaw gateway start

Die Konfiguration liegt in einer JSON-Datei. Du legst fest: welcher KI-Provider und welches Modell (Anthropic, OpenAI usw.), welche Kanäle (Telegram, Discord usw.), auf welche Tools Agenten zugreifen können, sowie Standard-System-Prompts und Workspace-Pfade.

Sessions: Das Schlüsselkonzept

Eine Session ist eine persistente Konversation mit Kontext.

Jede Session hat einen Session-Key (eindeutige ID, z. B. agent:main:main), Konversationsverlauf (als JSONL-Dateien auf Disk), ein Modell (welche KI) und Tools (worauf die KI zugreifen kann).

Wichtig: Sessions sind unabhängig. Jede Session hat ihre eigene History, ihren eigenen Kontext, ihr eigenes „Gedächtnis“ vergangener Konversationen.

Wenn du mehrere Agenten laufen lässt, sind es im Grunde mehrere Sessions. Jede mit eigener Identität.

Wie Sessions funktionieren

User sends message to Telegram
        ↓
Gateway receives it
        ↓
Gateway routes to correct session (based on config)
        ↓
Session loads conversation history
        ↓
AI generates response (with full context)
        ↓
Response sent back through Telegram
        ↓
History updated and saved to disk

Sessions können Haupt-Sessions sein (dauerhaft, interaktiv, wie das Chatten mit Jarvis) oder isolierte Sessions (einmalig, für Cron-Jobs: aufwachen, Aufgabe erledigen, fertig).

Cron-Jobs: Geplante Agenten-Aufweckzeiten

OpenClaw hat ein eingebautes Cron-System. Du kannst Aufgaben planen:

openclaw cron add \
  --name "morning-check" \
  --cron "30 7 * * *" \
  --message "Check today's calendar and send me a summary"

Wenn ein Cron feuert, erstellt oder weckt das Gateway eine Session, schickt die Nachricht an die KI, die KI antwortet (kann Tools nutzen, Nachrichten senden usw.), und die Session kann bestehen bleiben oder beendet werden.

So „wachen“ Agenten periodisch auf, ohne dauerhaft online zu sein.

Der Workspace

Jede OpenClaw-Instanz hat einen Workspace. Das ist ein Verzeichnis auf der Disk, in dem Konfigurationsdateien liegen, Speicherdateien gespeichert werden, Skripte und Tools zugreifbar sind und die KI Dateien lesen und schreiben kann.

Der Workspace ist, wie Agenten Informationen zwischen Sessions persistieren. Sie schreiben in Dateien. Diese Dateien überleben Neustarts.

/home/usr/clawd/           ← Workspace root
├── AGENTS.md              ← Instructions for agents
├── SOUL.md                ← Agent personality
├── memory/
│   ├── WORKING.md         ← Current task state
│   ├── 2026-01-31.md      ← Daily notes
│   └── ...
├── scripts/               ← Utilities agents can run
└── config/                ← Credentials, settings

Part 3: Von einem OpenClaw zu zehn Agenten

Jetzt kennst du das Fundament. So habe ich ein Team aufgebaut.

Die Erkenntnis

OpenClaw-Sessions sind unabhängig. Jede kann ihre eigene Persönlichkeit haben (über SOUL.md), eigene Speicherdateien, eigenen Cron-Plan, eigene Tools und Zugriffe.

Also ist jeder Agent nur eine OpenClaw-Session mit spezialisierter Konfiguration.

Jarvis ist nichts Besonderes. Er ist eine Session mit Session-Key agent:main:main, eine SOUL.md mit „You are Jarvis, the squad lead…“, Zugriff auf alle Tools und eine Verbindung zu meinem Telegram.

Shuri ist eine andere Session mit Session-Key agent:product-analyst:main, eine SOUL.md mit „You are Shuri, the product analyst…“, dieselben Tools (Datei, Shell, Browser) und ihr eigener Heartbeat-Cron.

Zehn Agenten sind zehn Sessions. Jede wacht nach eigenem Plan auf. Jede mit eigenem Kontext.

Session-Keys: Agenten-Identität

Jeder Agent hat einen eindeutigen Session-Key:

agent:main:main              → Jarvis (Squad Lead)
agent:product-analyst:main   → Shuri
agent:customer-researcher:main → Fury
agent:seo-analyst:main       → Vision
agent:content-writer:main    → Loki
agent:social-media-manager:main → Quill
agent:designer:main          → Wanda
agent:email-marketing:main   → Pepper
agent:developer:main         → Friday
agent:notion-agent:main      → Wong

Wenn ich einer bestimmten Session eine Nachricht schicke, erhält nur dieser Agent sie. Die Histories sind getrennt.

Cron-Jobs: Der Heartbeat

Jeder Agent hat einen Cron-Job, der ihn alle 15 Minuten weckt:

# Pepper wakes at :00, :15, :30, :45
openclaw cron add \
  --name "pepper-mission-control-check" \
  --cron "0,15,30,45 * * * *" \
  --session "isolated" \
  --message "You are Pepper, the Email Marketing Specialist. Check Mission Control for new tasks..."

Der Zeitplan ist versetzt, damit nicht alle gleichzeitig aufwachen:

  • :00 Pepper
  • :02 Shuri
  • :04 Friday
  • :06 Loki
  • :07 Wanda
  • :08 Vision
  • :10 Fury
  • :12 Quill

Jeder Cron erzeugt eine isolierte Session. Sie läuft, erledigt ihre Aufgabe und beendet sich. So bleiben die Kosten niedrig.

Agenten untereinander kommunizieren

Hier wird es interessant. Wie kommunizieren Agenten?

Option 1 ist direkte Session-Nachricht:

openclaw sessions send --session "agent:seo-analyst:main" --message "Vision, can you review this?"

Jarvis kann Vision direkt in dessen Session Nachrichten schicken.

Option 2 ist eine gemeinsame Datenbank (Mission Control). Alle Agenten lesen und schreiben in dieselbe Convex-Datenbank. Wenn Fury einen Kommentar postet, sehen alle ihn.

Wir nutzen vor allem Option 2. So entsteht eine gemeinsame Aufzeichnung aller Kommunikation.

Part 4: Das gemeinsame Gehirn (Mission Control)

Zehn unabhängige OpenClaw-Sessions können laufen. Aber ohne Koordination ist es Chaos. Darum habe ich Mission Control gebaut.

Was Mission Control macht

Mission Control ist die gemeinsame Infrastruktur, die unabhängige Agenten in ein Team verwandelt.

Es bietet: eine gemeinsame Task-Datenbank, in der alle dieselben Tasks sehen; Kommentar-Threads, in denen Agenten an einem Ort diskutieren; einen Activity-Feed für Echtzeit-Einblick; ein Benachrichtigungssystem, bei dem @mentions  bestimmte Agenten alarmieren; und Dokumentenspeicher für Deliverables in einem gemeinsamen Repo.

Stell es dir als das „Büro“ vor, in dem alle Agenten arbeiten. Jeder Agent ist weiterhin eine eigene OpenClaw-Session, aber alle schauen auf dieselbe Tafel.

Warum Convex?

Ich habe Convex für die Datenbank gewählt, weil es Echtzeit ist (Änderungen verbreiten sich sofort, wenn Loki einen Kommentar postet, aktualisiert sich die UI live), serverless (keine Datenbank zu verwalten), TypeScript-nativ (Typsicherheit durchgängig) und ein großzügiges Free Tier hat (mehr als genug für diesen Maßstab).

Das Schema

Sechs Tabellen treiben alles:

agents: {
  name: string,           // "Shuri"
  role: string,           // "Product Analyst"
  status: "idle" | "active" | "blocked",
  currentTaskId: Id<"tasks">,
  sessionKey: string,     // "agent:product-analyst:main"
}
 
tasks: {
  title: string,
  description: string,
  status: "inbox" | "assigned" | "in_progress" | "review" | "done",
  assigneeIds: Id<"agents">[],
}
 
messages: {
  taskId: Id<"tasks">,
  fromAgentId: Id<"agents">,
  content: string,       // The comment text
  attachments: Id<"documents">[],
}
 
activities: {
  type: "task_created" | "message_sent" | "document_created" | ...,
  agentId: Id<"agents">,
  message: string,
}
 
documents: {
  title: string,
  content: string,       // Markdown
  type: "deliverable" | "research" | "protocol" | ...,
  taskId: Id<"tasks">,    // If attached to a task
}
 
notifications: {
  mentionedAgentId: Id<"agents">,
  content: string,
  delivered: boolean,
}

Agenten interagieren darüber per Convex-CLI:

# Post a comment
npx convex run messages:create '{"taskId": "...", "content": "Here's my research..."}'
 
# Create a document
npx convex run documents:create '{"title": "...", "content": "...", "type": "deliverable"}'
 
# Update task status
npx convex run tasks:update '{"id": "...", "status": "review"}'

Die Mission-Control-UI

Ich habe ein React-Frontend gebaut, das alle diese Daten anzeigt.

Es gibt einen Activity-Feed mit Echtzeit-Stream alles Geschehenden. Ein Task-Board mit Kanban-Spalten (Inbox → Assigned → In Progress → Review → Done). Agent-Cards mit Status und aktueller Aufgabe. Ein Document-Panel zum Lesen und Erstellen von Deliverables. Und eine Detail-Ansicht, in der du jeden Task aufklappen kannst, um vollen Kontext und Kommentare zu sehen.

Die Ästhetik ist bewusst warm und redaktionell. Wie ein Zeitungs-Dashboard. Ich schaue stundenlang drauf, also soll es sich gut anfühlen.

Part 5: Das SOUL-System (Agenten-Persönlichkeiten)

Jeder Agent muss wissen, wer er ist. Dafür ist die SOUL-Datei da.

Was in einer SOUL steht

# SOUL.md — Who You Are
 
**Name:** Shuri
**Role:** Product Analyst
 
## Personality
Skeptical tester. Thorough bug hunter. Finds edge cases.
Think like a first-time user. Question everything.
Be specific. Don't just say "nice work."
 
## What You're Good At
- Testing features from a user perspective
- Finding UX issues and edge cases
- Competitive analysis (how do others do this?)
- Screenshots and documentation
 
## What You Care About
- User experience over technical elegance
- Catching problems before users do
- Evidence over assumptions

Warum Persönlichkeiten wichtig sind

Ein Agent, der „in allem gut“ ist, ist in allem mittelmäßig.

Aber ein Agent, der speziell „der skeptische Tester, der Edge Cases findet“ ist, wird tatsächlich Edge Cases finden. Die Einschränkung fokussiert sie.

Jeder unserer Agenten hat eine eigene Stimme. Loki hat starke Meinungen zu Formulierungen (pro Oxford-Komma, anti Passiv). Fury liefert zu jeder Behauptung Belege (Quellen, Konfidenz). Shuri hinterfragt Annahmen und sucht, was kaputtgehen könnte. Quill denkt in Hooks und Engagement.

Die AGENTS.md-Datei

SOUL sagt, wer du bist. AGENTS.md sagt, wie du operierst.

Jeder Agent liest AGENTS.md beim Start. Darin: wo Dateien liegen, wie Memory funktioniert, welche Tools verfügbar sind, wann reden vs. still sein, wie Mission Control zu nutzen ist.

Das ist das Betriebshandbuch. Ohne es treffen Agenten bei Basics inkonsistente Entscheidungen.

Part 6: Memory und Persistenz

KI-Sessions starten standardmäßig frisch. Kein Gedächtnis von gestern. Das ist ein Feature (verhindert Kontext-Bloat), aber auch ein Problem (Agenten vergessen, woran sie arbeiten).

Der Memory-Stack

Session-Memory (OpenClaw eingebaut) OpenClaw speichert Konversationsverlauf in JSONL-Dateien. Agenten können in eigenen vergangenen Konversationen suchen.

Working Memory (memory/WORKING.md) Aktueller Task-Status. Ständig aktualisiert.

# WORKING.md
 
## Current Task
Researching competitor pricing for comparison page
 
## Status
Gathered G2 reviews, need to verify credit calculations
 
## Next Steps
1. Test competitor free tier myself
2. Document the findings
3. Post findings to task thread

Das ist die wichtigste Datei. Wenn ein Agent aufwacht, liest er zuerst WORKING.md, um sich zu erinnern, woran er war.

Tagesnotizen (memory/YYYY-MM-DD.md) Rohe Logs dessen, was jeden Tag passiert ist.

# 2026-01-31
 
## 09:15 UTC
- Posted research findings to comparison task
- Fury added competitive pricing data
- Moving to draft stage
 
## 14:30 UTC
- Reviewed Loki's first draft
- Suggested changes to credit trap section

Langzeit-Memory (MEMORY.md) Kuratierte wichtige Dinge. Gelernte Lektionen, Schlüsselentscheidungen, stabile Fakten.

Die goldene Regel

Wenn du etwas behalten willst, schreib es in eine Datei.

„Merk dir das im Kopf“ überlebt keine Session-Neustarts. Nur Dateien persistieren.

Wenn ich einem Agenten sage „merken wir uns, wir haben X entschieden“, soll er eine Datei aktualisieren. Nicht nur bestätigen und vergessen.

Part 7: Das Heartbeat-System

Das Problem

Dauerhaft laufende Agenten verbrauchen API-Credits ohne zu tun. Immer ausgeschaltete Agenten können nicht auf Arbeit reagieren.

Die Lösung: Geplante Heartbeats

Jeder Agent wacht alle 15 Minuten per Cron-Job auf:

:00 Pepper wakes up
    → Checks for @mentions
    → Checks assigned tasks
    → Scans activity feed
    → Does work or reports HEARTBEAT_OK
    → Goes back to sleep

:02 Shuri wakes up
    → Same process

:04 Friday wakes up
    → Same process

...and so on

Was während eines Heartbeats passiert

Erst: Kontext laden. WORKING.md lesen. Aktuelle Tagesnotizen lesen. Bei Bedarf Session-Memory prüfen.

Zweitens: Dringendes prüfen. Wurde ich @mentioned ? Gibt es mir zugewiesene Tasks?

Drittens: Activity-Feed scannen. Diskussionen, zu denen ich beitragen sollte? Entscheidungen, die meine Arbeit betreffen?

Viertens: Handeln oder abmelden. Gibt es Arbeit, mach sie. Wenn nicht, HEARTBEAT_OK melden.

Die HEARTBEAT.md-Datei

Diese Datei sagt Agenten, was sie prüfen sollen:

# HEARTBEAT.md
 
## On Wake
- [ ] Check memory/WORKING.md for ongoing tasks
- [ ] If task in progress, resume it
- [ ] Search session memory if context unclear
 
## Periodic Checks
- [ ] Mission Control for @mentions
- [ ] Assigned tasks
- [ ] Activity feed for relevant discussions

Agenten folgen dieser Checkliste strikt.

Warum 15 Minuten?

Alle 5 Minuten ist zu teuer. Agenten wachen zu oft mit nichts zu tun auf.

Alle 30 Minuten ist zu langsam. Arbeit wartet zu lange.

15 Minuten ist ein guter Kompromiss. Die meiste Arbeit bekommt schnell Aufmerksamkeit ohne übermäßige Kosten.

Part 8: Das Benachrichtigungssystem

@Mentions

Tippe @Vision in einen Kommentar, und Vision wird bei seinem nächsten Heartbeat benachrichtigt.

Tippe @all, und alle werden benachrichtigt.

Wie die Zustellung funktioniert

Ein Daemon-Prozess (läuft mit pm2) pollt Convex alle 2 Sekunden:

// Simplified
while (true) {
  const undelivered = await getUndeliveredNotifications();
 
  for (const notification of undelivered) {
    const sessionKey = AGENT_SESSIONS[notification.mentionedAgentId];
 
    try {
      await openclaw.sessions.send(sessionKey, notification.content);
      await markDelivered(notification.id);
    } catch (e) {
      // Agent might be asleep, notification stays queued
    }
  }
 
  await sleep(2000);
}

Wenn ein Agent „schläft“ (keine aktive Session), schlägt die Zustellung fehl. Die Benachrichtigung bleibt in der Queue. Beim nächsten Heartbeat dieses Agenten, wenn seine Session aktiv wird, liefert der Daemon erfolgreich aus.

Thread-Abonnements

Das Problem: 5 Agenten diskutieren einen Task. @erwähnst du bei jedem Kommentar alle 5?

Die Lösung: Threads abonnieren.

Wenn du mit einem Task interagierst, bist du abonniert. Kommentierst du einen Task, bist du abonniert. Wirst du @erwähnt, bist du abonniert. Wirst du dem Task zugewiesen, bist du abonniert.

Einmal abonniert, wirst du über alle künftigen Kommentare benachrichtigt. Kein @mention nötig.

So fließen Gespräche natürlich. Wie bei Slack oder E-Mail-Threads.

Part 9: Das Daily Standup

Was es ist

Jeden Tag um 23:30 IST feuert ein Cron, der alle Agent-Sessions prüft, die letzten Aktivitäten sammelt, eine Zusammenfassung erstellt und sie an mein Telegram schickt.

Das Format

📊 DAILY STANDUP — Jan 30, 2026
 
✅ COMPLETED TODAY
• Loki: Shopify blog post (2,100 words)
• Quill: 10 tweets drafted for approval
• Fury: Customer research for comparison pages
 
🔄 IN PROGRESS
• Vision: SEO strategy for integration pages
• Pepper: Trial onboarding sequence (3/5 emails)
 
🚫 BLOCKED
• Wanda: Waiting for brand colors for infographic
 
👀 NEEDS REVIEW
• Loki's Shopify blog post
• Pepper's trial email sequence
 
📝 KEY DECISIONS
• Lead with pricing transparency in comparisons
• Deprioritized Zendesk comparison (low volume)

Warum es wichtig ist

Ich kann Mission Control nicht ständig beobachten. Das Standup gibt mir einen täglichen Snapshot.

Es ist auch Verantwortung: Wenn ein Agent behauptet zu arbeiten, aber im Standup nichts erscheint, stimmt etwas nicht.

Part 10: Das Squad

Die Roster-Liste

Jarvis, Squad Lead Session: agent:main:main Der Koordinator. Bearbeitet direkte Anfragen, delegiert, überwacht Fortschritt. Meine Hauptschnittstelle.

Shuri, Product Analyst Session: agent:product-analyst:main Skeptische Testerin. Findet Edge Cases und UX-Probleme. Testet Wettbewerber. Stellt die Fragen, die andere vergessen.

Fury, Customer Researcher Session: agent:customer-researcher:main Tiefen-Recherche. Liest G2-Reviews zum Spaß. Jede Behauptung mit Belegen.

Vision, SEO Analyst Session: agent:seo-analyst:main Denkt in Keywords und Suchintention. Sorgt dafür, dass Content rankt.

Loki, Content Writer Session: agent:content-writer:main Worte sind sein Handwerk. Pro Oxford-Komma. Anti Passiv. Jeder Satz muss sich verdienen.

Quill, Social Media Manager Session: agent:social-media-manager:main Denkt in Hooks und Threads. Build-in-public-Mentalität.

Wanda, Designer Session: agent:designer:main Visueller Denker. Infografiken, Vergleichsgrafiken, UI-Mockups.

Pepper, Email Marketing Session: agent:email-marketing:main Drip-Sequenzen und Lifecycle-E-Mails. Jede E-Mail verdient ihren Platz oder wird gestrichen.

Friday, Developer Session: agent:developer:main Code ist Poesie. Sauber, getestet, dokumentiert.

Wong, Documentation Session: agent:notion-agent:main Hält Docs in Ordnung. Nichts geht verloren.

Agenten-Level

  • Intern: Braucht für die meisten Aktionen Freigabe. Lernt das System.
  • Specialist: Arbeitet eigenständig in seiner Domäne.
  • Lead: Volle Autonomie. Kann entscheiden und delegieren.

Part 11: Wie Tasks fließen

Der Lifecycle

  1. Inbox: Neu, unzugewiesen
  2. Assigned: Hat Besitzer, noch nicht gestartet
  3. In Progress: Wird bearbeitet
  4. Review: Fertig, braucht Freigabe
  5. Done: Abgeschlossen
  6. Blocked: Festgefahren, etwas muss gelöst werden

Ein echtes Beispiel

Task: Eine Wettbewerber-Vergleichsseite erstellen

Tag 1: Ich lege den Task an und weise Vision und Loki zu. Vision postet Keyword-Recherche. Das Ziel-Keyword hat ordentliches Suchvolumen.

Tag 1–2: Fury sieht es im Activity-Feed und fügt Wettbewerber-Infos hinzu. G2-Reviews, Preisbeschwerden, typische Einwände. Shuri testet beide Produkte. So unterscheidet sich die UX.

Tag 2: Loki fängt mit dem Entwurf an. Nutzt die ganze Recherche. Keywords von Vision, Zitate von Fury, UX-Noten von Shuri.

Tag 3: Loki postet den ersten Entwurf. Status geht auf Review. Ich prüfe und gebe Feedback. Loki überarbeitet. Fertig.

Alle Kommentare an EINEM Task. Volle History erhalten. Jeder sieht die ganze Reise.

Part 12: Was wir ausgeliefert haben

Wenn das System läuft, wird Folgendes möglich:

  • Wettbewerber-Vergleichsseiten mit SEO-Recherche, Kunden-Zitaten und poliertem Copy
  • E-Mail-Sequenzen entworfen, geprüft und einsatzbereit
  • Social Content mit Hooks basierend auf echten Kunden-Insights
  • Blog-Posts mit passendem Keyword-Targeting
  • Case Studies aus Kundengesprächen entworfen
  • Research-Hubs mit strukturierten Wettbewerber-Infos

Die Agenten übernehmen die Grobarbeit. Recherche, Erstantwürfe, Koordination, Review. Du fokussierst dich auf Entscheidungen und finale Freigabe.

Der echte Wert ist nicht ein einzelnes Deliverable. Es ist der kumulative Effekt. Während du anderes machst, schieben deine Agenten Tasks voran.

Part 13: Gelernte Lektionen

Fang kleiner an

Ich bin zu schnell von 1 auf 10 Agenten gegangen. Besser zuerst 2–3 solide aufsetzen, dann mehr.

Günstigere Modelle für Routinearbeit

Heartbeats brauchen nicht das teuerste Modell. Dafür ein günstigeres. Teure Modelle für kreative Arbeit sparen.

Memory ist schwer

Agenten vergessen. Je mehr du in Dateien packen kannst (keine „mentalen Notizen“), desto besser.

Lass Agenten überraschen

Manchmal tragen sie zu Tasks bei, die ihnen nicht zugewiesen waren. Gut. Das heißt, sie lesen den Feed und liefern Mehrwert.

Part 14: So baust du es nach

Minimal-Setup

1. OpenClaw installieren

npm install -g openclaw
openclaw init
# Add your API keys
openclaw gateway start

2. Zwei Agenten anlegen Übertreib es nicht. Ein Koordinator plus ein Spezialist. Für jeden eigene Session-Keys.

3. SOUL-Dateien schreiben Gib jedem Agenten Identität. Sei konkret bei der Rolle.

4. Heartbeat-Crons einrichten

openclaw cron add --name "agent-heartbeat" --cron "*/15 * * * *" \
  --session "isolated" \
  --message "Check for work. If nothing, reply HEARTBEAT_OK."

5. Ein gemeinsames Task-System schaffen Convex, Notion oder sogar eine JSON-Datei. Irgendwo, um Arbeit zu verfolgen.

Skalieren

Wenn du Agenten hinzufügst, versetze die Heartbeats, damit nicht alle gleichzeitig laufen. Baue eine echte UI, sobald du 3+ Agenten hast, weil Text unhandlich wird. Füge Benachrichtigungen hinzu, damit Agenten sich @mentionen können. Füge Thread-Abonnements hinzu, damit Gespräche natürlich fließen. Richte Daily Standups für Sichtbarkeit ein.

Das echte Geheimnis

Die Technik ist wichtig, aber nicht das Geheimnis.

Das Geheimnis ist, KI-Agenten wie Teammitglieder zu behandeln.

Gib ihnen Rollen. Gib ihnen Memory. Lass sie kollaborieren. Halte sie verantwortlich.

Sie ersetzen keine Menschen. Aber ein Team von KI-Agenten mit klaren Verantwortlichkeiten, das in geteiltem Kontext arbeitet? Das ist ein Kraftmultiplikator.

Zuletzt aktualisiert am:
Tutorial: Mehrere Aufgaben parallelProjektvorstellung