Gleich vorweg: Keine Sorge, ich habe hier nicht Moltbook neu erfunden.
Jedes Startup, das ich kenne, hat mindestens drei Tools zu viel im Einsatz. Ein Board hier, ein Notion-Doc da, ein Slack-Thread, der stillschweigend zur Spezifikation mutiert ist. Bei fluado, wo wir KI-Agenten für Geschäftsabläufe bauen, hat sich in den letzten Wochen eine neue Schicht reingemogelt: Agenten, die Markdown direkt in unser Doc-Repo schreiben. Sprint-Tickets, Abschlussberichte. Dutzende Dateien. Plötzlich war das Dateisystem die Source of Truth. Das Projekt-Board dagegen nicht.
Arbo und ich reden jeden Tag. Mehrmals. Aber gesprochene Worte lassen sich nicht tracken. Dafür hatten wir Jira. Als wir es heute Morgen öffneten, war der Stand vier Wochen alt. Niemand war in der Zwischenzeit drin gewesen.
Ich habe schon mal geschrieben, dass KI ein Produktivitäts-Multiplikator ist, wenn das eigene Fundament schon steht. Das gilt offenbar auch für das Projekt-Board.
Also meinte ich zu Arbo: Was, wenn wir ein winziges Board bauen, das einfach die Markdown-Dateien ausliest, die ohnehin schon existieren? Nur ein Fenster, das auf die Realität schaut.
Er war skeptisch. Ich war mir selbst nicht sicher, ob die Idee überhaupt den Nachmittag überlebt. Aber die Alternative war, den Vormittag damit zu verbringen, das Jira Board zu aktualisieren – nur damit es nach einer Woche wieder verstaubt.
Am späten Nachmittag war Jira Geschichte. Alle Tickets rübergezogen. Arbo, ich und die Agenten – alle zusammen im selben Board. Später haben wir das Ergebnis als Faru: Das Kanban-Board für KI-Agenten als Open Source veröffentlicht.
Das Board
Unsere Agenten arbeiten eh in Markdown. Sie erstellen Dateien mit YAML-Frontmatter und schreiben Berichte. Warum sollen wir das also alles in ein SaaS-Tool zwingen, das für Leute gemacht ist, die auf Buttons klicken wollen?
Jede Aufgabe liegt als Ordner unter backlog/. Der Ordnername enthält das Datum und die Kategorie. Darin: ein ganzer Schwung Markdown-Dateien.
backlog/
├── 2026-03-26-CHAT-UX/
│ ├── chat-ux-milestones.md # the plan
│ ├── chat-ux-tickets.md # broken into tasks
│ ├── CUX0-report.md # agent completion report
│ └── CUX1-report.md
├── 2026-03-27-AGENT-I18N/
│ ├── agent-i18n-milestones.md
│ ├── agent-i18n-tickets.md
│ ├── I0-report.md
│ ├── I1-report.md
│ └── i18n-audit-report.md
└── 2026-04-01-OPS-DEPLOY-STAGING/
└── CARD.md # simple card, no sub-tasks
Das Milestones-File ist unser Plan. In den Tickets stehen die Details. Reports sind das, was der Agent ausspuckt, wenn er einen Milestone abschließt. CARD.md nutzen wir für simple Aufgaben ohne weitere Unterteilung. Das Board zieht sich die Metadaten einfach aus dem YAML-Frontmatter der Hauptdatei:
---
title: Chat UX Improvements
type: product
status: wip
assigned: yves
created: 2026-03-26
edited: 2026-04-01
---
Ein Agent, der eine Aufgabe erstellt, führt einfach ein mkdir aus und schreibt eine Markdown-Datei mit dem passenden Frontmatter. Das Schema ist so überschaubar, dass sich der Agent die Struktur bei den anderen Ordnern abschaut. Wenn er das Frontmatter doch mal verhaut, ignoriert das Board die Datei einfach. Ich seh das dann im Git-Log und fixe das YAML in zehn Sekunden.
In der IDE scrolle ich durch den Ordnerbaum. Das Board baut exakt dieselbe Struktur im Browser nach. Es gibt drei Spalten: todo, wip, done. Drag-and-Drop ändert den Status, ein Klick auf den Titel lässt dich umbenennen. Bei jeder Karte springt über „Open in Editor“ direkt die Datei auf.
Wenn jemand eine Backlog-Datei in der IDE bearbeitet, merkt der Server das sofort. Ein File-Watcher überwacht backlog/, wartet zur Sicherheit 5 Sekunden und committet dann automatisch. Du speicherst, Git synct.
Der Sync
Was ist der einfachste Weg, um zwei Leute und ihre Agenten synchron zu halten? Git.
Jede Aktion im Board feuert sofort einen Commit und Push ab:
[15:42:06] 📝 committed: move CHAT-UX to done
[15:42:07] ⬆ pushed
[15:43:12] 📝 committed: create OPS-DEPLOY-STAGING as todo
[15:43:13] ⬆ pushed
[15:44:30] 📝 committed: rename AGENT-I18N
[15:44:31] ⬆ pushed
Für eingehende Änderungen pollt der Server alle 5 Sekunden git ls-remote. Ein SSH-Roundtrip, ein SHA-Vergleich. Sobald neue Commits auf dem Remote liegen, werden sie per Pull geholt und ins Log geschrieben:
[15:45:10] ⬇ synced from remote:
abc1234 board: move AGENT-I18N to wip
def5678 board: update 2026-04-01-SURFACE
Der Browser holt sich die Updates über Server-Sent Events. Das Board rendert unsichtbar im Hintergrund. Wenn du also gerade eine Karte bearbeitest oder ein Formular ausfüllst, fliegt dir nichts um die Ohren. Das musste ich auf die harte Tour lernen. Die erste Version startete noch hart per location.reload() neu. :D
Andersrum geht es genauso: Wenn ein Agent einen Milestone abschließt, committet er einen Report in den Backlog-Ordner und pusht in Git. Fünf Sekunden später taucht die neue Datei von ganz allein in der Detailansicht der Karte auf. Ich muss den Agenten nicht mehr fragen, ob er fertig ist. Ich sehe es auf dem Board.
Der Code für das Board liegt im gleichen Repo. Er läuft über nodemon. Wenn einer von uns einen Fix auf den Server pusht, fängt der Remote-Poll das ab, nodemon startet neu, und das frische Frontend lädt über SSE. Ich habe heute um 15:00 Uhr das CSS geändert. Als ich danach wieder in den Browser tabte, war alles schon da. Arbo hat es auch sofort gesehen.
Die Karten rutschen nach oben, je nachdem, wann sie zuletzt angefasst wurden. Ich wollte erst eine manuelle Sortierung via Fractional-Indexing bauen. Fünf Minuten lang genutzt. Dann wieder rausgeworfen. Das Dateisystem weiß eh schon lange, woran ich arbeite.
Was sich eigentlich geändert hat
Wir arbeiten einfach weiter, wie wir vorher schon gearbeitet haben. Arbo und ich im Editor und im Board, die Agenten committen in backlog/. Git klebt alles zusammen. Der gesamte Stack ist Vanilla HTML/CSS/JS, kein einziger Build-Step, null npm-Dependencies. http.createServer, etwas YAML-Parsing und fs.watch.
Ein Wort zur Skalierung
Die ganze Timeline ist voll mit „SaaS ist tot, KI baut dir alles“-Beiträgen. Für zwei Leute und unsere Agenten funktioniert unser Setup exzellent. Ich weiß nicht, ob es ein Jira für Entwickler-Teams mit 10 Leuten ersetzen kann oder sollte. Ob dieses Board 6 Monate überlebt? Keine Ahnung.
Was ich sicher weiß: Wir haben einen Vormittag gebraucht, um es zu bauen, und einen Nachmittag, um darin zu arbeiten. Gegen Abend lagen 14 Karten in 3 Spalten. Gerade während ich das hier tippe, zieht Arbo eine auf WIP. Ich konnte im Browser dabei zuschauen.
Uns ging es nie darum, Jira abzulösen, weil wir unzufrieden damit waren. Jira war einfach nur eine Kopie unseres Dateisystems, um die sich am Ende niemand kümmern wollte. Also haben wir die Kopie gelöscht und uns stattdessen ein Dashboard für das Original gebaut.
Das Tool passt zu unserer Arbeitsweise, weil wir es exakt dafür programmiert haben. Das ist nicht das Rezept für alle. Es ist unseres.
Wenn du sehen willst, was wir als Nächstes bauen, abonniere den Newsletter oder folge uns auf LinkedIn, Mastodon oder Bluesky.
Hast du einen Prozess, der einen Agenten vertragen könnte? Lass uns reden.