Sie haben gerade einen zweiten Claude Code Agenten gestartet. Jetzt haben Sie ein Problem.

Der erste Agent ist mitten in einem Refactoring. Der zweite soll ein Feature bauen, das einige der gleichen Dateien betrifft. Keiner weiss vom anderen. Sie sind gleichzeitig Router, State-Store und Konfliktloeser, und Ihr einziges Werkzeug ist das Kopieren von Kontext zwischen Terminalfenstern.

Hier stossen die meisten Entwickler mit Claude Code an eine Wand. Nicht weil der Agent schlecht programmiert. Sondern weil es kein System gibt, das ihm sagt, woran er arbeiten soll.

Das Copy-Paste-Problem

Die meisten Claude Code Workflows beginnen gleich. Sie haben eine Aufgabe im Kopf (oder in Jira, oder in einem GitHub Issue) und fuegen die Beschreibung in den Prompt des Agenten ein. "Baue einen Auth-Flow." "Fix den Pagination-Bug." "Fuege Dark-Mode-Support hinzu."

Fuer einen einzelnen Agenten funktioniert das gut. Der Agent hat den vollen Kontext, Sie koennen seine Ausgabe beobachten, und Sie wissen, wann er fertig ist, weil Sie auf den Bildschirm schauen.

Fuegen Sie einen zweiten Agenten hinzu und die Risse zeigen sich sofort.

Agent A refactored die API-Schicht. Agent B baut einen neuen Endpoint. Beide aendern server/routes.ts. Keiner weiss von den Aenderungen des anderen. Sie entdecken den Konflikt, wenn einer pusht und die Arbeit des anderen kaputtgeht. Oder schlimmer: beide haben lokal Erfolg, aber das zusammengefuehrte Ergebnis ist auf Weisen kaputt, die keiner der Diffs zeigt.

Die Ursache ist nicht, dass Agenten schlampig arbeiten. Es ist das Fehlen eines gemeinsamen Zustands. Es gibt keinen Ort, an dem "Agent A ist fuer das API-Refactoring zustaendig" festgehalten wird. Es gibt keinen Status, der sagt "die Routes-Datei wird gerade geaendert, warte." Die Agenten arbeiten mit einzelnen Prompts ohne jedes Bewusstsein fuer das Gesamtbild.

Fuegen Sie einen dritten Agenten hinzu und Sie verbringen mehr Zeit mit Koordination als mit Programmieren.

Was Agenten tatsaechlich von einem Aufgabensystem brauchen

Bevor Sie nach einem Tool greifen, lohnt sich die Frage: Was braucht ein Claude Code Agent eigentlich, um gute Arbeit zu leisten?

Ueberraschend wenig.

Einen eindeutigen Bezeichner. Etwas, das er in Commits und Kommentaren referenzieren kann. "Bug gefixt" ist in einem Multi-Agent-Log nutzlos. "Abgeschlossen PROJ-47: Pagination liefert falsche Anzahl bei gefilterten Ansichten" ist nachverfolgbar.

Einen klaren Umfang. Titel, Beschreibung und Akzeptanzkriterien. Keinen Roman. Keine User Story mit Personas. Eine konkrete Aussage, wie "fertig" aussieht. "Der /users-Endpoint liefert paginierte Ergebnisse. Seitengroesse ist standardmaessig 25. Das Feld next_cursor ist null auf der letzten Seite."

Einen Status, den er aktualisieren kann. Der Agent muss signalisieren koennen, wo er steht: beansprucht, in Bearbeitung, fertig. Ohne das sind Sie wieder beim Blick in Terminalfenster und Raten.

Abhaengigkeitsbewusstsein. "Fang damit nicht an, bis PROJ-46 gemerged ist" verhindert den haeufigsten Multi-Agent-Fehler: auf Code aufbauen, der noch nicht existiert.

Beachten Sie, was auf dieser Liste fehlt. Sprint-Planung. Velocity-Tracking. Kanban-Boards. Story Points. Epics mit farbcodierten Labels. Agenten brauchen kein Projektmanagement-Theater. Sie brauchen eine Aufgabe, einen Status und eine Moeglichkeit zu sagen "Ich bin fertig."

Der CLAUDE.md-Vertrag

Das Aufgabensystem sagt den Agenten, woran sie arbeiten sollen. Die CLAUDE.md-Datei sagt ihnen, wie sie arbeiten sollen.

Wenn Sie mehrere Claude Code Agenten betreiben, sollte jeder eine CLAUDE.md haben, die seine Identitaet und Grenzen definiert. Das ist keine optionale Konfiguration. Es ist der Unterschied zwischen Agenten, die koordinieren, und Agenten, die sich gegenseitig in die Quere kommen.

Hier ein vereinfachtes Beispiel fuer einen Engineering-Agenten:

## Identity

Engineer for the project. You implement features, fix bugs,
and write tests. You own implementation quality.

## What You Own

- All files under `components/` and `lib/`
- Unit tests in `__tests__/`
- You may read but not modify files under `server/`

## What You Don't Own

- Deployment configuration (that's ops)
- Issue triage and prioritization (that's the coordinator)
- QA validation (QA tests your work independently)

## Completion Protocol

Before marking any task done:
1. Run the full test suite: `pnpm test`
2. Verify your change works manually
3. Comment what you did with the commit hash
4. Push before reporting completion

Der Abschnitt ueber Grenzen ist das tragende Element. Ohne expliziten Dateieigentum wandern Agenten ab. Ein Engineering-Agent refactored "hilfsbereit" die Deployment-Konfiguration. Ein QA-Agent "fixt" einen Test, indem er den getesteten Code statt des Tests aendert. Explizite Grenzen verhindern diese Fehlermodi.

Das Completion Protocol ist genauso wichtig. Es verhindert den haeufigsten Agent-Fehler: etwas als fertig zu melden, das lediglich kompiliert. "Fuehre die vollstaendige Test-Suite aus" und "verifiziere manuell" sind konkrete Gates. Ein Agent, der diesem Protokoll folgt, liefert Arbeit, der ein Mensch vertrauen kann. Ein Agent ohne liefert Arbeit, die Sie Zeile fuer Zeile nachpruefen muessen.

Skalieren Sie das ueber mehrere Agenten und Sie erhalten eine Flotte, in der jedes Mitglied seine Spur, sein Uebergabeprotokoll und die Bedeutung von "fertig" kennt.

CLI-first Aufgabenverwaltung

Hier eine Erkenntnis zum Workflow, die laenger gebraucht hat als sie sollte: Claude Code Agenten arbeiten dramatisch besser mit CLI-Tools als mit GUI-Interfaces.

Das ergibt Sinn, wenn man darueber nachdenkt. Ein Claude Code Agent lebt im Terminal. Er kann Befehle ausfuehren, Ausgaben lesen und basierend auf Ergebnissen handeln. Ihn aufzufordern, eine Web-UI zu navigieren, Buttons zu klicken und gerenderte Seiten zu interpretieren, arbeitet gegen das natuerliche Interface des Agenten.

Ein CLI-basiertes Aufgabensystem bedeutet, dass der Agent das in einem einzigen Ablauf erledigen kann:

# Read the task
task show PROJ-47

# Claim it
task update PROJ-47 --status in_progress --assignee agent-1

# Do the work...

# Report completion
task comment PROJ-47 "DONE: Fixed pagination. Commit: abc1234"
task update PROJ-47 --status done

Kein Kontextwechsel. Keine Browserfenster. Keine Screenshots eines Kanban-Boards. Der Agent liest eine Aufgabe, erledigt die Arbeit und aktualisiert den Status, alles ohne die Umgebung zu verlassen, in der er arbeitet.

Die Ausgabe ist auch maschinenlesbar. Wenn Sie pruefen muessen, was ueber alle Agenten passiert, koennen Sie abfragen:

task list --status in_progress    # What's being worked on?
task list --assignee agent-2      # What is agent-2 doing?
task list --blocked               # What's stuck?

Das ist die Form des Toolings, das funktioniert. Ein CLI, das die Sprache des Agenten spricht.

Beads: Local-first Issue-Tracking fuer Agenten

Der oben beschriebene Workflow ist nicht hypothetisch. Es ist das, was ich taeglich mit beads betreibe, einem Open-Source, Local-first Issue-Tracker, der genau fuer diese Art der agentengesteuerten Entwicklung gebaut wurde.

beads speichert Issues (genannt "Beads") in einer lokalen Dolt-Datenbank neben Ihrer Codebase. Jeder Bead hat eine ID, Titel, Beschreibung, Status, Prioritaet, Abhaengigkeiten und einen Kommentar-Thread. Das CLI heisst bd und ist das Interface, ueber das Agenten Aufgaben lesen, Status aktualisieren und strukturierte Kommentare hinterlassen.

Hier ein realer Workflow. Ich erstelle eine Aufgabe:

bd create --title "Fix pagination on filtered views" \
  --description "The /users endpoint returns wrong count when filters are applied. Page size defaults to 25. next_cursor should be null on the last page." \
  --priority p2

Ein Agent beansprucht sie:

bd update bb-r3k2 --claim --actor eng1
bd update bb-r3k2 --status in_progress

Bevor er Code schreibt, kommentiert der Agent seinen Plan:

bd comments add bb-r3k2 --author eng1 "PLAN:
1. Fix count query in /users to apply filters before COUNT()
2. Add cursor boundary check for last page
3. Add test cases for filtered pagination

Files:
- server/routes/users.ts - fix count query
- server/routes/users.test.ts - add filtered pagination tests"

Das ist ein Checkpoint. Wenn der Plan falsch ist, erkennen Sie es in 30 Sekunden, statt eine schlechte Implementierung 45 Minuten spaeter zu entdecken.

Der Agent erledigt die Arbeit, fuehrt Tests aus und kommentiert den Abschluss:

bd comments add bb-r3k2 --author eng1 "DONE: Fixed filtered pagination count.

- COUNT() now applies the same WHERE clause as the data query
- next_cursor returns null when offset + page_size >= total_count
- Added 4 test cases covering filtered + unfiltered pagination

Commit: a1b2c3d"

bd update bb-r3k2 --status ready_for_qa

Die Aufgabe hat jetzt einen vollstaendigen Audit-Trail: was angefordert wurde, was der Agent geplant hat, was er tatsaechlich getan hat, und den Commit-Hash zum Review. Ein zweiter Agent, der QA betreibt, kann sie aufgreifen und unabhaengig verifizieren.

Das funktioniert, weil beads die gleiche Sprache spricht wie die Agenten. Alles ist ein CLI-Befehl. Alles liefert strukturierte Ausgabe. Es gibt keine Impedanzmismatch zwischen Tool und Agent.

Das grosse Bild sehen

Der CLI-Workflow skaliert auf 3 oder 4 Agenten, bevor man an eine neue Grenze stoesst. Keine Tool-Grenze. Eine kognitive.

Bei 5 Agenten ist bd list ausfuehren und mental den Projektzustand zusammensetzen wie eine Tabelle lesen und versuchen, einen Abhaengigkeitsgraphen im Kopf zu halten. Welche Aufgaben sind blockiert? Welcher Agent hat seit 20 Minuten keinen Status aktualisiert? Ist das Feature-Epic zu 60% oder 80% fertig? Die Information steckt komplett im CLI-Output, aber sie zusammenzusetzen erfordert Aufwand, der sich mit jedem weiteren Agenten aufaddiert.

Hier passt Beadbox hinein. Es ist ein Echtzeit-Dashboard, das auf beads aufsetzt und Ihnen den Zustand Ihrer gesamten Agenten-Flotte zeigt. Visuell gerenderte Abhaengigkeitsbaeume. Epic-Fortschrittsbalken. Agenten-Kommentar-Threads, die Sie scannen koennen, ohne fuenf bd show-Befehle auszufuehren.

Beadbox ersetzt nicht das CLI. Die Agenten nutzen weiterhin bd fuer alles. Beadbox ist die Schicht, die Sie oeffnen, wenn Sie das grosse Bild brauchen: welche Arbeitsstroeme sich bewegen, welche feststecken und wo die Engpaesse sind. Es ueberwacht die beads-Datenbank auf Aenderungen und aktualisiert in Echtzeit, sodass Sie nie veraltete Daten sehen.

Es ist waehrend der Beta kostenlos und laeuft vollstaendig auf Ihrem Rechner. Keine Accounts, keine Cloud, Ihre Daten bleiben lokal.

Erste Schritte

Sie brauchen keine 13 Agenten, um von strukturierter Aufgabenverwaltung zu profitieren. Beginnen Sie mit zwei Claude Code Agenten und einer Regel: jede Aufgabe bekommt einen Bead, jeder Agent kommentiert seinen Plan vor dem Programmieren, jeder Abschluss enthaelt Verifikationsschritte.

Das Muster potenziert sich. Sobald Agenten ein gemeinsames Aufgabensystem haben, koennen Sie QA-Agenten hinzufuegen, die Arbeit unabhaengig verifizieren. Sie koennen einen Koordinator hinzufuegen, der Aufgaben aus einer Prioritaetswarteschlange verteilt. Sie koennen auf 5, 10, 15 Agenten skalieren, ohne dass der Koordinationsaufwand linear waechst, weil die Protokolle das uebernehmen, was frueher manuelles Context-Switching war.

Die Tools:

beads fuer Local-first Aufgabenverwaltung. Open Source.
Claude Code als Agent-Runtime.
Beadbox fuer visuelle Uebersicht, wenn die Flotte waechst.

Wenn Sie Workflows wie diesen aufbauen, geben Sie Beadbox einen Stern auf GitHub.

Aufgaben fuer Claude Code Agents verwalten