11. April 2026

DecisionNode: Geteiltes strukturiertes Memory für alle AI-Coding-Tools über MCP

Wer parallel mit mehreren AI-Coding-Tools arbeitet, kennt das Problem: Jedes Tool hat sein eigenes Briefing-Format. Claude Code liest CLAUDE.md, Cursor hat .cursorrules, OpenAI-Agents schauen in AGENTS.md, Windsurf wiederum hat seine eigene Konvention. Projektentscheidungen, Constraints und Domain-Wissen landen in jeder dieser Dateien redundant und driften über die Zeit auseinander. DecisionNode, ein am 10. April auf Hacker News vorgestelltes Open-Source-Projekt von AmmarSaleh50, will dieses Silo-Problem auf MCP-Ebene lösen.

Das Problem: Briefing-Duplikation über Tool-Grenzen hinweg

Die gängigen Memory-Dateien haben laut Autor zwei Schwächen: Sie sind per-Tool (wer von Claude Code zu Cursor wechselt, schreibt dieselben Projektregeln nochmal anders) und sie sind statisch -- sie werden pauschal in jede Session injiziert, unabhängig davon ob der aktuelle Task den Kontext überhaupt braucht. Das trägt zum Context-Bloat bei, den auch die Skills-vs-MCP-Debatte gegen kontextintensive Erweiterungsmechanismen anführt. DecisionNode dreht den Spieß um: Decisions liegen in einem zentralen strukturierten Store, und AI-Tools holen sich nur das, was zur aktuellen Anfrage passt -- semantisch gefiltert, nicht pauschal durchgereicht.

Architektur: CLI plus MCP-Server über einem lokalen Vector-Store

Technisch besteht das Projekt aus zwei Schnittstellen zum selben Datenspeicher unter ~/.decisionnode/: einer CLI (decide) für Menschen und Skripte sowie einem MCP-Server (decide-mcp) mit neun Tools (add_decision, search_decisions, update_decision, delete_decision, History-Abfrage usw.) für die AI-Tools.

Eine Decision ist ein JSON-Objekt mit Feldern wie id, scope, decision, status, rationale, constraints, createdAt. Beim Anlegen wird der Text mit Googles gemini-embedding-001 zu einem Vektor konvertiert und lokal in vectors.json abgelegt. Die Suche läuft über Cosine Similarity, der Default-Threshold liegt bei 0.3.

Der entscheidende Designpunkt: Retrieval ist explizit. Im Gegensatz zu CLAUDE.md, das beim Session-Start automatisch geladen wird, gelangt nichts aus DecisionNode in den Prompt, solange der Agent nicht aktiv search_decisions aufruft. Das reduziert Token-Verbrauch, setzt aber voraus, dass das Modell die Such-Tools zuverlässig einsetzt -- genau das "Memory-as-a-Tool"-Muster aus dem Artikel zu Kurzzeit- und Langzeit-Memory.

Installation ist knapp:

npm install -g decisionnode
cd your-project
decide init
decide setup
claude mcp add decisionnode -s user decide-mcp

Laut README werden Claude Code, Cursor, Windsurf und Antigravity als Clients explizit genannt -- prinzipiell funktioniert jeder MCP-fähige Client.

Was man sinnvoll teilt -- und was lokal bleibt

Der Autor selbst zieht eine klare Grenze zwischen CLAUDE.md und DecisionNode: CLAUDE.md bleibt für Regeln, die der Agent permanent im Kontext braucht, DecisionNode übernimmt die Memories, die nur situativ relevant sind. Übersetzt auf die Praxis heißt das:

In DecisionNode: punktuelle Architektur-Entscheidungen ("Kein Connection Pooling für die Embeddings-DB -- nur ein Writer, revisiten bei Sync-Daemon"), Constraints mit Ablaufdatum, Domain-Knowledge das nur bei bestimmten Modulen greift, globale Policies wie "nie .env committen".
In CLAUDE.md / .cursorrules / AGENTS.md: tool-spezifische Kommandos, Build-Prozess, Code-Style-Regeln die in jeder Session gelten, Teststrategien, Skills-Verweise.

Das ist dieselbe Unterscheidung, die auch Beyond RAG zwischen semantischem und prozeduralem Memory macht. DecisionNode adressiert die episodisch-semantische Schicht, nicht das prozedurale Daily-Briefing.

Feinheiten und Einschränkungen

Über das Grundmuster hinaus fällt bei der Lektüre der README auf: Beim Anlegen wird gegen existierende Decisions auf 75% Similarity geprüft -- Conflict Detection, damit sich nicht leise Widersprüche einschleichen. Deprecated Decisions bleiben als Soft-Delete erhalten inklusive Embedding. Jede Änderung wird mit Ursprung geloggt (cli, claude-code, cursor, windsurf), man sieht also nachträglich welches Tool was geschrieben hat. Global Decisions gelten projektübergreifend, das Agent-Behavior-Setting (strict vs. relaxed) passt die Tool-Description an, um das Modell mehr oder weniger aggressiv zur Suche zu zwingen.

Drei Einschränkungen sollte man kennen. Erstens hängt der Store derzeit fest an Gemini-Embeddings. Auf HN fragte KellyMCP genau danach -- der Autor verweist auf Geminis Free-Tier ohne Kreditkarte und nennt OpenAI-Support als Roadmap-Punkt. Zweitens ist der Speicher lokal unter ~/.decisionnode/; Team-Sync läuft über decide export/import oder externe Tools, es gibt keinen gemanagten Multi-Device-Modus. Drittens ist das Retrieval nur so gut wie die Query -- Cosine Similarity auf kurzen Decision-Texten ersetzt keinen Reranker oder Hybrid-Retrieval.

Einordnung und Bewertung

Die Entscheidung, MCP als Integrationsschicht zu nutzen, ist konsequent und folgt demselben Muster, das Pinterest und Elgato bereits in Produktion bringen: ein Standardprotokoll statt N proprietärer Integrationen.

Für wen lohnt sich der Einsatz? Wer nur mit einem einzigen Coding-Agent arbeitet, bekommt mit CLAUDE.md plus einem der etablierten Memory-Frameworks (Mem0, Letta) vermutlich dasselbe. Wer drei oder mehr AI-Tools parallel bedient und schon mehrfach dieselben Policies in mehreren Markdown-Dateien gleichzeitig ändern musste, bekommt hier einen konkreten Ausweg. Das Projekt ist mit 21 Punkten auf Hacker News noch Nischen-Sichtbarkeit, aber der Ansatz ist konzeptionell sauber. Einen Blick wert für alle, die das Silo-Problem täglich spüren und bereit sind, einen zusätzlichen Dienst in die MCP-Config aufzunehmen.

Quellen

Nach oben