Das Issue-Label ist das Protokoll der Agenten

Die Factory, die öffentlich auf software-factory.dev (öffnet in einem neuen Tab) entsteht, hat einen Skill namens development-workflow. Eine Anleitung ist er nicht. In ihm beschreibt die Factory sich selbst, er ist ihre eigene Landkarte.

Geladen wird er, sobald jemand wissen will, wie hier gearbeitet wird. Das kann ein Mensch sein, der fragt, wie er ein Feature einreicht. Oder ein Agent, der fragt, welche Automationen es gibt. Der Skill hat für beide die Antwort.

Ein Issue durchläuft eine State Machine

Beim Issue-Lebenszyklus bleibe ich immer wieder hängen. Er ist als State Machine gebaut, und den Zustand zeigt ein Label auf dem Issue. Angelegt wird ein Issue ohne Label. Ist es bereit, kommt status:backlog dazu. Fängt eine Automation an, wird daraus status:in-progress. Mit dem Pull Request folgt status:in-review, und sobald er gemergt ist, status:done.

Keine Automation ruft eine andere auf

Das solltet ihr euch abschauen: Die Automationen rufen einander nie auf. Nicht ein einziges Mal.

Der Feature Builder holt sich das status:backlog-Issue mit der höchsten Priorität und öffnet einen Pull Request. Der PR Reviewer wird von seinem eigenen Cron geweckt, stößt auf den offenen Pull Request, reviewt ihn und mergt ihn. Gesagt hat der Feature Builder dem Reviewer nichts. Er hat ein Label umgestellt und ist weitergezogen.

Mehr Protokoll als dieses Label gibt es nicht. Keinen Message Bus, keine Queue, kein Standup zum Abgleichen. Jede Automation liest die Labels, die für sie zählen, macht ihre Arbeit und setzt das nächste Label. Die nächste Automation stößt darauf, wann ihr eigener Zeitplan es vorsieht.

Schriftlich schlägt orchestriert

Dieses Muster bringe ich in jedes Kundengespräch über agentische Teams mit. Wer viele autonome Worker hat, will instinktiv orchestrieren: mit einem Controller, einer Queue, einem Planer, der Aufgaben verteilt. Eine gemeinsame, schriftliche und einsehbare Ebene ist all dem überlegen. Labels auf Issues bleiben bestehen, sind in der GitHub-Oberfläche zu sehen und überleben, wenn ein einzelner Agent mitten im Lauf abstürzt.

Auch die Landkarte dieser Ebene ist ein Skill, den jeder Agent bei Bedarf laden kann: der development-workflow-Skill im Repository der Factory (öffnet in einem neuen Tab).

Wenn bei euch ein Agent Arbeit an den nächsten übergibt: Wohinein schreibt er diese Übergabe? Und könnte ein Mensch sie eine Woche später noch lesen?

Weiterlesen

Die Artikel der Wissensbasis sind auf Englisch.

• Multi-Agent and Orchestration →
• Agentic Software Factory: Advanced Team Training →