Ich unterhalte Fulcrum — eine local-first Agent Control Plane zur Koordination von Multi-Agent-Coding-Arbeit. Es gibt Dutzende Agent- Frameworks auf dem Markt im Jahr 2026. Die Frage “warum noch eines?” verdient eine ehrliche Antwort, und die ist: keines der anderen hat die langweiligen operativen Teile gemacht, die das Modell bei 3.400 Commits pro Jahr wirklich nutzbar machen.

Was Fulcrum tatsächlich ist

Fulcrum ist ein kleines TypeScript-Runtime, das via MCP-Server und CLI eine Handvoll Primitiven exponiert, die jeder Coding-Agent (Claude Code, Codex, Gemini, Cursor, jeder MCP-Speaker) ansprechen kann:

  • Task Tracking — starte, aktualisiere, schließe eine Arbeitseinheit ab, mit WIP-Limits und Blocker-Tracking.
  • Hybrid Memory Recall — ein FTS5 + Vector + optionaler Graph-Store mit Supersession und Confidence-Tracking, sodass Agents über Sessions hinweg dauerhaften Kontext ansammeln können, ohne jedes Mal alles neu zusammenzufassen.
  • Chief-of-Staff-Kontext — ein World-State-Snapshot, den andere Agents als “was gerade im Workspace läuft”-Briefing konsumieren können, statt ihren State pro Session neu zu entdecken.
  • Agent-Run-Lifecycle — registrieren, Heartbeat, blockieren, abschließen. Ein laufender-aber-nicht-abgeschlossener Run erscheint im CLI statt zu verschwinden.

Alles persistiert lokal. Es gibt keine gehostete Komponente, kein Telemetrie per Default, kein Vendor-Lock. Läuft auf demselben Rechner wie dein Editor und deine Agents.

Das Problem, das es löst

Die meisten Agent-Frameworks auf dem Markt 2026 sind auf eine von zwei Formen optimiert:

Form A: Der cloud-gehostete Orchestrator. LangChain-gehostet, LlamaIndex-gehostet, die vendor-spezifischen. Deren Primitiven gehen davon aus, dass du okay damit bist, dass der Task-State deines Agents auf einem fremden Rechner lebt und deren Abrechnungsplan auf jeden Schritt angewendet wird.

Form B: Das In-Editor-Runtime. Der eingebaute Agent in Claude Code, Cursor usw. Deren Primitiven gehen davon aus, dass du jeweils in einem Editor mit einem Agent arbeitest, ephemer, und dass alles Dauerhafte dein Problem ist.

Beide Formen scheitern bei dem, was ich tue: viele Agents in Rotation über mehrere Engagements, mit echtem Kontext, der über Sessions persistieren muss, und einer Engineering-Disziplin, die auf Task-Tracking angewiesen ist, das die Agents selbst sehen können.

Fulcrum lebt in der dritten Form: local-first, multi-agent, agent-visible. Die Agents können die Task-Liste und den Memory direkt abfragen; der State gehört dir, nicht dem Vendor; und die operativen Primitiven (WIP, Blocker, Heartbeats) sind First-Class.

Design-Entscheidungen, die zählen

Ein paar Entscheidungen, die ich in einem Review verteidigen würde:

1. Agents bekommen Lesezugriff, Menschen bekommen Schreibzugriff

Standardmäßig können Agents alles lesen und sehr wenig schreiben. Ein Agent kann Fortschritt auf einer Task, die er besitzt, aufzeichnen; er kann in die Memory-Schicht schreiben; er kann Heartbeat schicken. Er kann keine Tasks an andere Agents vergeben. Er kann keine Berechtigungen eskalieren. Er kann keine Teams invoken. Das machen Menschen — ich oder der Operator.

Das ist dieselbe “liberal lesen, vorsichtig schreiben”-Haltung, die man einem Junior-Engineer geben würde. Es ist auch die Haltung, die verhindert, dass Multi-Agent-Runs in einen Hobbesschen Zustand kippen, wo alle gegenseitig ihre Arbeit an sich selbst delegieren.

2. Memory ist tiered, nicht flach

Die Memory-Schicht hat drei Tiers: L0 (Raw Dumps, immutable, keinerlei Kürzung), L1 (kuratierte Wiki-artige Pages, mit Confidence und Retention, bearbeitet von einem Curator-Agent), L2 (Vectors über L1). Recall läuft über L1 mit L0-Backrefs, sodass Agents jedem Claim zu seiner Rohdatenquelle folgen können.

Diese Architektur ist nicht neu (die MemGPT-Linie und Verwandtes hat viel davon inspiriert), aber sie ist so implementiert, dass der Provenance-Trail günstig nachzuverfolgen ist. Wenn Fulcrum einem Agent etwas sagt, kann der Agent fragen: “Woher kommt das?” — und eine Antwort bekommen.

3. Rollengrenzen werden durchgesetzt, nicht empfohlen

Fulcrum hat ein Konzept von Agent-Rollen (engineer, tester, reviewer, chief-of-staff usw.). Nur chief_of_staff kann Teams invoken. Nur rollenangemessene Agents können bestimmte Tasks beanspruchen. Das sind keine Konventionen — sie werden auf der MCP-Ebene geprüft. Wenn ein software_engineer-Agent versucht, ein Team zu invoken, bekommt er einen Fehler.

Der Grund, das einzubauen: Ohne das kollabieren Agent-Workflows schnell in “alle machen alles” — genau die Pathologie, die Multi-Agent verhindern soll.

4. Es funktioniert offline

Keine Netzwerkcalls für Core-Operationen notwendig. Das Ganze läuft gegen lokales SQLite, lokale Vault-Markdown-Dateien und lokale Embeddings. Wenn das Homelab-Internet ausfällt, funktioniert Fulcrum weiter — und die Agents auch.

Was es nicht ist

Um Erwartungen zu setzen:

  • Es ist kein Frontier-Agent-Framework. Es versucht nicht, ein Modell zu sein. Es ist eine Control Plane, die neben welchem Agent auch immer sitzt, den du schon nutzt.
  • Es ist kein verwaltetes Produkt. Es gibt keine gehostete Version. Du clonest das Repo, du nutzt es, du besitzt die Daten.
  • Es ist nicht battle-tested at Scale. Es ist battle-tested auf meiner Skala — mehrere Agents, Jahre an Session-History, echte Engagements. Es wird raue Kanten zeigen, wenn jemand anderes es auf seiner Skala betreibt. Deshalb ist es OSS.

Die Antwort auf “warum der Aufwand?”

Die ehrliche Antwort auf “warum das schreiben, wenn X existiert” ist: Ich habe es geschrieben, weil das Benutzen von X mich pro Session 20 Minuten Overhead gekostet hat, und Fulcrum mich 30 Sekunden kostet. Multi-Agent-, Multi-Engagement-Arbeit hat feste Overheads, die sich schnell aufaddieren. Entweder du zahlst sie, oder du investierst einmal in ein Tool, das sie wegmacht. Ich habe einmal investiert.

Wenn du ähnliche Arbeit machst — mehrere Agents, dauerhafter Kontext, echte Task-Disziplin — probier Fulcrum aus. Wenn du One-Agent-, One-Session-, ephemere Arbeit machst, brauchst du es nicht. Das ist völlig in Ordnung. Es versucht nicht, alles zu sein.

Das Muster generalisiert

Das, worauf ich bei Fulcrum am stolzesten bin, ist nicht der Code. Es ist das Muster: local-first, agent-visible, multi-agent, persistent. Dieses Muster wird in den nächsten zwei Jahren einen großen Teil des gehosteten Orchestrator- Markts fressen. Die Teams, die auf vendor-gelockte Orchestratoren bauen, werden aufwachen und diese Form wollen — ohne sie zu haben. Ich wäre lieber auf der Seite der Leute, die die Form bauen, als auf der Seite derer, die warten, dass das jemand anderes tut.

Noch dazu: Mein Commit-Graph im letzten Jahr ist größtenteils Fulcrum und die Site, auf der du das hier liest. Wenn du wissen willst, womit between-seats-Mo seine Zeit verbringt — das ist die Antwort. Arbeitslosigkeit hat noch nie so viele Commits geshipt.