Fulcrum: eine local-first Agent-Control-Plane

An den meisten Arbeitstagen laufen bei mir fünf KI-Coding-Agents parallel. Claude Code, Codex, Gemini CLI, Pi, OpenCode - jeder fähig, jeder vollständig unwissend darüber, was die anderen tun. Vor Fulcrum war meine “Orchestrierungsschicht” ein Post-it und ein Gebet. Das ist keine Übertreibung. Es gab tatsächlich ein Post-it.

Warum es das gibt

Das Problem ist nicht, dass einzelne Agents schlecht sind. Sie sind bemerkenswert. Das Problem ist die Lücke zwischen einer einzelnen produktiven Agent-Session und einem Multi-Agent-Workflow, der das Gehirn nicht zum Schmelzen bringt.

Jedes Vendor-Framework, das ich evaluierte, war entweder an einen Anbieter gebunden (hartes Nein), für Stateless-Request-Response-Loops ausgelegt (nutzlos für Sessions, die Stunden dauern), oder erforderte ein Cloud-Backend, dem ich meinen work-in-progress-Kontext nicht anvertrauen wollte. Ich wollte etwas, das lokal läuft, einen Laptop-Neustart übersteht und mich nicht zwingt, jedes Mal, wenn ich einen neuen Terminal-Tab öffne, meine komplette Projekthistorie von vorne zu erklären.

Also baute ich das Ding, das ich benutzen wollte. Es heißt Fulcrum, weil der Agent der Hebel ist; die Control-Plane ist das, was bestimmt, wo der Hebel tatsächlich ansetzt.

Wie es funktioniert

Fulcrum exposes einen MCP-Server - das Model-Context-Protocol, das Anthropic als standardmäßige Tool-calling-Surface für Claude Code ausliefert. Jeder Agent, der sich verbindet, bekommt Zugriff auf denselben Satz von Primitives: Task-Management, Run-Lifecycle-Tracking und einen Hybrid-Memory-Store.

Die Storage-Schicht ist SQLite mit FTS5 für Volltext-Suche, ergänzt durch einen Vektor-Index für semantischen Abruf. Wenn ein Agent sich an etwas erinnern will - “was haben wir letzten Dienstag über das Auth-Schema entschieden?” - führt Fulcrum einen dreistufigen Abruf durch: FTS5-Keyword-Match, Vektor-Cosinus-Ähnlichkeit und ein Graph-Traversal über im Query genannte Entitäten. Die Ergebnisse werden via gewichteter Reciprocal-Rank-Fusion fusioniert und nach Confidence-Floor gefiltert, bevor irgendetwas das Agent-Context-Window betritt.

Memory hat drei Tiers. L0 sind Raw-Dumps - verbatim, immutable, append-only. L1 sind kuratierte Wiki-Seiten, die ein LLM-Kurator mit Confidence-Scores, Retention-Tiers und Back-References zu ihren L0-Quellen pflegt. L2 ist der Vektor-Index über L1. Wenn du Fulcrum bittest, sich etwas zu erinnern, bekommst du L1-Seiten mit angehängter L0-Provenienz, sodass du immer einen Claim zum rohen Session-Transcript zurückverfolgen kannst, der ihn generierte.

Task-Management setzt WIP-Limits durch. Wenn dein Team tief in fünf Dingen steckt und jemand versucht, ein sechstes zu starten, pushes Fulcrum back. Das ist nicht kleinlich - es ist das Wirksamste, was ich gefunden habe, um Agent-Context-Fragmentation zu verhindern. Ein Agent, der zwölf offene Tasks jongliert, produziert schlechteren Output als einer, der sich auf zwei fokussiert.

Die Chief-of-Staff-Rolle ist die Orchestrierungs-Tier: sie baut World-State-Snapshots aus aktiven Tasks, laufenden Agents und kürzlichen Events und nutzt diese Snapshots, um Arbeit an Spezialistenrollen zu dispatchen. COS kann keinen Code schreiben. Spezialistenrollen können keine Sub-Orchestrierung spawnen. Die Rollenhierarchie wird auf der Tool-Ebene erzwungen, nicht auf der Prompt-Ebene.

Was interessant ist

Das, was mich während der Entwicklung am meisten überraschte: der schwierigste Teil war nicht der Memory-Abruf. Es war der Run-Lifecycle.

Agents stürzen ab. Terminals schließen sich. Laptop-Deckel gehen runter. Ein Run, der vor zwei Stunden “in progress” war, ruft möglicherweise seinen complete_agent_run-Call nie ab. Fulcrum hat einen Stale-Run-Sweeper, der beim Session-Start läuft und jeden Run abbricht, dessen letzter Heartbeat älter als der Staleness-Threshold ist. Ohne das füllt sich der Workspace-State mit Phantom-Running-Agents und dein Chief-of-Staff beginnt, Planungsentscheidungen auf Basis von Gespenstern zu treffen.

Das andere nicht-offensichtliche Ding: Memory-Write-Paths idempotent zu machen ist viel schwieriger als es klingt, wenn man fünf concurrent Agents hat, die alle dieselbe Architekturentscheidung aus leicht verschiedenen Winkeln erfassen könnten. Der Kurator muss deduplizieren, supersedieren und eine kohärente L1-Oberfläche pflegen - was bedeutet, dass die rohe L0-Schicht hohes Write-Volumen tolerieren muss und der Curation-Pass Konfliktauflösung sauber handhaben muss.

Ich habe angefangen, die Memory-Schicht weniger wie eine Datenbank zu denken und mehr wie ein Zeitungsarchiv: die Raw-Dumps sind die täglichen Ausgaben (niemals wegwerfen), die kuratierten Seiten sind die Enzyklopädie (aktualisiert, wenn neue Evidenz eintrifft), und der Confidence-Score ist der redaktionelle Konsens darüber, ob ein Claim über die Zeit Bestand gehalten hat.

Was ich ändern würde

Der Vektor-Index ist aktuell pro Workspace, und das ist ein Fehler. Workspace-übergreifender Recall - “ich habe letzten Monat im Payments-Service-Repo ein ähnliches Problem gelöst” - wäre genuinely nützlich, und das Abruf-Plumbing ist bereits da. Ich habe den Scope einfach noch nicht korrekt verdrahtet.

Ich möchte auch die Conflict-Resolution-Logik des Kurators härten. Momentan, wenn zwei Agents widersprüchliche Informationen über dieselbe Entität erfassen, wählt der Kurator die Version mit höherem Confidence. Das funktioniert in der Praxis gut, verwirft aber still die Minderheitsmeinung. Das richtige Verhalten wäre wahrscheinlich, den Widerspruch als ein markiertes Paar zu surfacen und einen Menschen oder den COS es explizit auflösen zu lassen.

Der Dispatch-Pfad - wo COS tatsächlich einen Claude-Code-Subprocess für eine Spezialistenrolle spawnt - ist aktuell Fire-and-Forget. Ich will richtiges Stdout-Streaming, damit der COS beobachten kann, was passiert, und eingreifen kann, wenn ein Run schiefläuft, ohne auf den Heartbeat warten zu müssen, der kalt wird.

Fulcrum ist das Infrastruktur-Stück, das ich gewünscht hätte, als ich ernsthaft mit Agents anfing zu arbeiten. Es zu bauen lehrte mich, dass Multi-Agent-Orchestrierung hauptsächlich ein Distributed-Systems-Problem mit einer dünnen Schicht LLM-spezifischer Concerns darüber ist - und die Distributed-Systems-Probleme sind die, die dich zuerst beißen.