FUSE AI Agents 2026: Plan/Scratch für zuverlässiges Reasoning

24. Januar 2026Ollie @puppyone

Wichtigste Erkenntnisse

FUSE AI Agents 2026 Plan/Scratch-Workflow

  • Die Externalisierung von Long-Context über plan.md, scratch.md, decisions.json und trace.log stabilisiert mehrstufiges Reasoning und macht Debugging zur Routine.
  • FUSE-basierte Mounts ermöglichen Agenten den Einsatz standardmäßiger POSIX-Semantik (ls/grep/mv/append), reduzieren maßgeschneiderte Tool-Wrapper und verbessern die Reproduzierbarkeit.
  • MCP fungiert als standardisierte Brücke zu Unternehmenssystemen, während das Dateisystem einen einheitlichen lokalen Arbeitsbereich bereitstellt; zusammen ermöglichen sie governante, beobachtbare Workflows.
  • Local-first/On-Prem-Deployments entsprechen Compliance- und Residency-Anforderungen; pro Task-Mounts und path-level ACLs unterstützen Least Privilege.
  • Benchmarks sind noch früh; behandeln Sie Performance-Aussagen als Hypothesen und priorisieren Sie Evaluationsmethoden und Observability.

Warum Dateien flüchtige Prompts für Long-Context schlagen

Wenn Pläne, Zwischenartefakte und Entscheidungen in Dateien erfasst werden – plan.md, scratch.md, decisions.json, trace.log – werden sie zur Ground Truth für das Reasoning statt zu verblassender Erinnerung im Token-Fenster. Dateien bringen Versionierung, Diffs und Checkpoints. Sie können nachvollziehen, wie ein Plan sich entwickelt hat, schlechte Branches zurücksetzen und einen Lauf aus einem bekannten Zustand reproduzieren. Das Dateisystem ist das überprüfbare Arbeitsgedächtnis des Agenten, kein unsichtbarer Prompt-Thread.

Jakob Emmerlings Essay von Anfang 2026 untermauert konzeptionell „filesystem-first“-Agenten und illustriert Muster wie E-Mail-als-Verzeichnisse und POSIX read/write/list/move als natürliche Agenten-Aktionen. Siehe „FUSE is All You Need – Giving agents access to anything via filesystems“. Für die Architektur-Trade-offs: How LLM Agent Architectures Work.

Der praktische Vorteil ist Reproduzierbarkeit: Dateien wie decisions.json und trace.log liefern deterministische Spuren von Was und Warum. Sie verbessern auch die Zusammenarbeit zwischen Ingenieuren und Agenten – Menschen können plan.md lesen, einen Abschnitt bearbeiten und den Agenten weitermachen lassen. Kein spezielles Tool nötig.

Laufendes Beispiel — Multi-Repo-Engineering mit Plan/Scratch-Workflows

Konkretes Workspace-Setup:

  • /workspace/repoA
  • /workspace/repoB/docs
  • /workspace/patterns
  • /workspace/plans/plan.md
  • /workspace/scratch/scratch.md
  • /workspace/logs/trace.log
  • /workspace/state/decisions.json

In diesem Setup nutzen Agenten vertraute POSIX-Ops: ls, grep, mv/cp, echo >>, diff und patch wie beschrieben.

Lifecycle: (1) plan.md anlegen/laden mit Zielen und Einschränkungen. (2) In scratch.md iterieren: Snippets ausprobieren, Erkenntnisse festhalten, Blocker notieren. (3) Entscheidungen in decisions.json mit Begründung und Timestamps festhalten. (4) Aktionen in trace.log mit Agent-Action-IDs protokollieren. (5) Validierte Artefakte aus scratch in die passenden Repo-Verzeichnisse übernehmen und PR über ein MCP-exponiertes Issue/PR-Tool öffnen.

Warum funktioniert das gut für Engineering-Wissen über mehrere Repos? Weil Agenten „in Dateien denken“ und repoubergreifend ohne eigene Adapter arbeiten können. Das Dateisystem liefert eine Abstraktion; MCP-Server exponieren externe Systeme über eine standardisierte Schnittstelle.

Implementierungsmuster für FUSE-Agenten und MCP-Interop

  • Lokales FUSE mit SQLite-Backend: für Entwicklerrechner und kleine Piloten. Siehe AgentFS-Vorschlag (Penberg).
  • DB-gestütztes virtuelles FS (lokal SQLite, später Supabase o. ä.): Tursos „AgentFS FUSE“.
  • Object-Store-backed AgentFS: für größere Organisationen, Speicher entkoppeln, virtuelles FS mit Caching mounten.

MCP als Brücke zu Issue-Trackern, CI, Dokumenten und internen Diensten. Siehe MCP Anniversary Spec, MCP Authorization Update, Anthropic Code Execution with MCP, JetBrains MCP Docs.

Governance, Sandboxing und Compliance

Filesystem-first heißt nicht Wildwuchs. Least Privilege: pro Task nur nötige Verzeichnisse mounten; path-level ACLs und Audit-Logs; OS-Kontrollen (SELinux, AppArmor, Landlock). Local-first/On-Prem unterstützt Residency und Compliance. MCP-Scopes auf dasselbe Least-Privilege-Modell wie die Dateisystemschicht abbilden.

Observability und Evaluation

POSIX-Tracing, Kernmetriken (Erfolgsrate, Latenz, Reproduzierbarkeit, Auditability), Benchmark-Methodik: filesystem-first Agent vs. API/MCP-only Toolchain vergleichen. Kontextschicht: Building a RAG Model That Scales.

Grenzen und wann APIs gewinnen

FUSE fügt Userspace-Vermittlung hinzu (mehr CPU/Latenz). Starke Schreib- oder Metadaten-Lasten können das spürbar machen. Streaming- oder Transaktionsdomänen bevorzugen oft direkte SDKs/APIs. Hybrid: Dateisystem für Plan/Scratch/State, MCP für strukturierte, transaktionale Aufrufe.

Wo eine Context Base passt

Hinweis: Puppyone ist unser Produkt.

Eine governante Context Base kann diese Architektur unterlegen: strukturiertes „Know-How“ (JSON/Graph), hybride Indizierung, lokales Deployment per Docker. Puppyone’s Context Base. How Agentic Process Automation Is Transforming Enterprise Operations in 2026.

Nächste Schritte und Ressourcen

Klein starten: lokalen FUSE-Mount mit plan/scratch über zwei Repos, MCP-Connector für PRs/Issues, POSIX-Tracing. Referenzen: FUSE is All You Need, AgentFS (Penberg), Turso AgentFS FUSE, MCP Anniversary, Anthropic MCP, JetBrains MCP.

FAQs

F1: Beeinträchtigt FUSE-Overhead die Agenten-Performance erheblich?

FUSE fügt moderate Latenz hinzu; Agenten-Workloads sind meist leselastig mit burstartigen Schreibvorgängen. Kernel-Page-Caching mildert Overhead nach den ersten Lesevorgängen. Turso-Piloten zeigen <10 ms Latenz für Engineering-Tasks wie cross-repo grep – vernachlässigbar gegenüber LLM-Inferenz. Batch-Appends oder RAM-gestützte Scratch-Partitionen bewältigen Schreibspitzen. Ein Latenz-Tradeoff von 5–15 % ist durch deterministische Nachverfolgbarkeit via trace.log und wiederabspielbare Workflows aus plan.md-Checkpoints gerechtfertigt.

F2: Wie starte ich einen filesystem-first-Pilot ohne Infrastruktur-Umbau?

Wählen Sie eine begrenzte Zwei-Repo-Aufgabe (z. B. Auth-Flow dokumentieren). Mounten Sie nur diese Repos plus leere plans/, scratch/ und logs/ lokal mit fusepy oder fuse-turso. Der Agent initialisiert plan.md, iteriert in scratch.md und schreibt trace.log. Fügen Sie einen minimalen MCP-Connector für GitHub-PRs hinzu. Alles auf dem Laptop; innerhalb von zwei Wochen Reproduzierbarkeit und Debugging-Vorteile validieren – keine Produktionsänderungen nötig.

F3: Wann sollte ich filesystem-first zugunsten direkter APIs vermeiden?

Bei High-Frequency-Streaming (Echtzeit-Marktdaten), ACID-kritischen Transaktionen (Zahlungen) oder zustandslosen Einzelschritt-Aufgaben (URL-Zusammenfassung). Hybrid: Dateisystem für Plan/Scratch/State, latenzsensitive Aufrufe über MCP-Tools. Faustregel: Wenn Sie morgen mit git diff plan.md eine Entscheidung prüfen wollen, bringt filesystem-first Mehrwert.