Vous venez de lancer un deuxieme agent Claude Code. Maintenant vous avez un probleme.

Le premier agent est en plein refactoring. Le deuxieme doit construire une fonctionnalite qui touche certains des memes fichiers. Aucun ne sait que l'autre existe. Vous etes le routeur, le state store et le resolveur de conflits, tout a la fois, et votre seul outil est le copier-coller de contexte entre les fenetres de terminal.

C'est la que la plupart des developpeurs se heurtent au mur avec Claude Code. Pas parce que l'agent code mal. Parce qu'il n'y a pas de systeme pour lui dire sur quoi travailler.

Le probleme du copier-coller

La plupart des workflows Claude Code commencent de la meme facon. Vous avez une tache en tete (ou dans Jira, ou dans une issue GitHub), et vous collez la description dans le prompt de l'agent. "Construis un flux d'authentification." "Corrige le bug de pagination." "Ajoute le support du mode sombre."

Pour un seul agent, ca marche bien. L'agent a tout le contexte, vous pouvez observer sa sortie, et vous savez quand c'est fini parce que vous le regardez.

Ajoutez un deuxieme agent et les fissures apparaissent immediatement.

L'Agent A refactorise la couche API. L'Agent B construit un nouvel endpoint. Les deux touchent server/routes.ts. Aucun ne connait les modifications de l'autre. Vous decouvrez le conflit quand l'un pousse et que le travail de l'autre casse. Ou pire : les deux reussissent localement mais le resultat fusionne est casse de facons qu'aucun diff ne revele.

La cause profonde n'est pas que les agents soient negligents. C'est l'absence d'etat partage. Il n'y a pas d'endroit ou "l'Agent A est responsable du refactoring API" est enregistre. Il n'y a pas de statut qui dit "le fichier de routes est en cours de modification, attends ton tour." Les agents operent sur des prompts individuels avec zero conscience du tableau d'ensemble.

Ajoutez un troisieme agent et vous passez plus de temps a coordonner qu'a coder.

Ce que les agents ont vraiment besoin d'un systeme de taches

Avant de chercher un outil, ca vaut la peine de se demander : de quoi un agent Claude Code a-t-il reellement besoin pour faire du bon travail ?

Etonnamment peu.

Un identifiant unique. Quelque chose qu'il peut referencer dans les commits et commentaires. "Corrige le bug" est inutile dans un log multi-agent. "Complete PROJ-47 : la pagination renvoie un mauvais compte sur les vues filtrees" est tracable.

Un perimetre clair. Titre, description et criteres d'acceptation. Pas un roman. Pas une user story avec des personas. Une declaration concrete de ce a quoi ressemble "termine." "L'endpoint /users renvoie des resultats pagines. La taille de page est de 25 par defaut. Le champ next_cursor est null sur la derniere page."

Un statut qu'il peut mettre a jour. L'agent doit pouvoir signaler ou il en est : reclame, en cours, termine. Sans ca, vous en revenez a jeter un oeil aux fenetres de terminal et a deviner.

La conscience des dependances. "Ne commence pas ca tant que PROJ-46 n'est pas merge" previent l'echec multi-agent le plus courant : construire sur du code qui n'existe pas encore.

Remarquez ce qui manque dans cette liste. Planification de sprints. Suivi de velocite. Tableaux Kanban. Story points. Epics avec des etiquettes colorees. Les agents n'ont pas besoin de theatre de gestion de projet. Ils ont besoin d'une tache, d'un statut et d'un moyen de dire "j'ai termine."

Le contrat CLAUDE.md

Le systeme de taches dit aux agents sur quoi travailler. Le fichier CLAUDE.md leur dit comment travailler.

Si vous executez plusieurs agents Claude Code, chacun devrait avoir un CLAUDE.md qui definit son identite et ses limites. Ce n'est pas une configuration optionnelle. C'est la difference entre des agents qui se coordonnent et des agents qui se marchent dessus.

Voici un exemple simplifie pour un agent d'ingenierie :

## 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

La section des limites est la partie porteuse. Sans appropriation explicite des fichiers, les agents derivent. Un agent d'ingenierie refactorise "serviablement" la configuration de deploiement. Un agent QA "corrige" un test en changeant le code sous test au lieu du test lui-meme. Les limites explicites empechent ces modes d'echec.

Le protocole de completion compte tout autant. Il previent l'echec d'agent le plus courant : declarer quelque chose comme termine alors que ca compile simplement. "Executer la suite de tests complete" et "verifier manuellement" sont des gates concrets. Un agent qui suit ce protocole produit du travail auquel un humain peut faire confiance. Un agent sans produit du travail que vous devez reverifier ligne par ligne.

Mettez ca a l'echelle sur plusieurs agents et vous obtenez une flotte ou chaque membre connait sa voie, son protocole de passation et ce que signifie "termine."

Gestion de taches CLI-first

Voici une observation de workflow qui m'a pris plus de temps a integrer qu'elle n'aurait du : les agents Claude Code travaillent radicalement mieux avec des outils CLI qu'avec des interfaces GUI.

Ca a du sens quand on y reflechit. Un agent Claude Code vit dans le terminal. Il peut executer des commandes, lire des sorties et agir en fonction des resultats. Lui demander de naviguer dans une interface web, de cliquer sur des boutons et d'interpreter des pages rendues, c'est aller contre l'interface naturelle de l'agent.

Un systeme de taches base sur CLI signifie que l'agent peut faire tout ca en un seul flux :

# 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

Pas de changement de contexte. Pas de fenetres navigateur. Pas de captures d'ecran d'un tableau Kanban. L'agent lit une tache, fait le travail et met a jour le statut, le tout sans quitter l'environnement ou il opere.

La sortie est aussi lisible par les machines. Quand vous avez besoin de verifier ce qui se passe entre les agents, vous pouvez interroger :

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?

C'est la forme de l'outillage qui fonctionne. Un CLI qui parle le langage de l'agent.

Beads : suivi d'issues local-first pour les agents

Le workflow que j'ai decrit ci-dessus n'est pas hypothetique. C'est ce que j'utilise tous les jours avec beads, un tracker d'issues open-source et local-first construit exactement pour ce type de developpement pilote par des agents.

beads stocke les issues (appelees "beads") dans une base de donnees Dolt locale a cote de votre codebase. Chaque bead a un ID, un titre, une description, un statut, une priorite, des dependances et un fil de commentaires. Le CLI s'appelle bd, et c'est l'interface que les agents utilisent pour lire les taches, mettre a jour les statuts et laisser des commentaires structures.

Voici un workflow reel. Je cree une tache :

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

Un agent la reclame :

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

Avant d'ecrire du code, l'agent commente son 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"

C'est un checkpoint. Si le plan est faux, vous l'attrapez en 30 secondes au lieu de decouvrir une mauvaise implementation 45 minutes plus tard.

L'agent fait le travail, lance les tests, puis commente la completion :

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

La tache a maintenant une piste d'audit complete : ce qui a ete demande, ce que l'agent a planifie, ce qu'il a reellement fait, et le hash de commit a revoir. Un deuxieme agent faisant du QA peut la prendre et verifier independamment.

Ca fonctionne parce que beads parle le meme langage que les agents. Tout est une commande CLI. Tout produit une sortie structuree. Il n'y a pas de decalage d'impedance entre l'outil et l'agent.

Voir le tableau d'ensemble

Le workflow CLI tient jusqu'a 3 ou 4 agents avant d'atteindre un nouveau plafond. Pas un plafond d'outils. Un plafond cognitif.

A 5 agents, lancer bd list et assembler mentalement l'etat du projet, c'est comme lire un tableur en essayant de garder un graphe de dependances en tete. Quelles taches sont bloquees ? Quel agent n'a pas mis a jour son statut depuis 20 minutes ? L'epic de la fonctionnalite est a 60% ou 80% ? L'information est toute la dans la sortie CLI, mais la reconstituer demande un effort qui se cumule avec chaque agent supplementaire.

C'est la que Beadbox s'insere. C'est un tableau de bord en temps reel qui se pose par-dessus beads et vous montre l'etat de toute votre flotte d'agents. Des arbres de dependances rendus visuellement. Des barres de progression d'epics. Des fils de commentaires d'agents que vous pouvez scanner sans lancer cinq commandes bd show.

Beadbox ne remplace pas le CLI. Les agents continuent d'utiliser bd pour tout. Beadbox est la couche que vous ouvrez quand vous avez besoin du tableau d'ensemble : quels chantiers avancent, lesquels sont bloques, et ou sont les goulots d'etranglement. Il surveille la base de donnees beads pour les changements et se met a jour en temps reel, donc vous ne regardez jamais des donnees perimees.

C'est gratuit pendant la beta et tourne entierement sur votre machine. Pas de comptes, pas de cloud, vos donnees restent locales.

Pour commencer

Vous n'avez pas besoin de 13 agents pour tirer de la valeur de la gestion structuree de taches. Commencez avec deux agents Claude Code et une regle : chaque tache obtient un bead, chaque agent commente son plan avant de coder, chaque completion inclut des etapes de verification.

Le pattern se compose. Une fois que les agents ont un systeme de taches partage, vous pouvez ajouter des agents QA qui verifient le travail independamment. Vous pouvez ajouter un coordinateur qui distribue les taches depuis une file de priorite. Vous pouvez passer a 5, 10, 15 agents sans que la charge de coordination augmente lineairement, parce que les protocoles gerent ce qui etait auparavant du changement de contexte manuel.

Les outils :

beads pour la gestion de taches local-first. Open source.
Claude Code comme runtime d'agents.
Beadbox pour la supervision visuelle quand la flotte grandit.

Si vous construisez des workflows comme celui-ci, mettez une etoile a Beadbox sur GitHub.

Comment gerer les taches pour les agents Claude Code