Graph Engineering: von Schleifen zu Wissensgraphen

Am 18. Juli 2026 stellte Peter Steinberger auf X eine augenzwinkernde Frage zum Übergang von Schleifen zu Graphen. Hamel Husain griff sie auf und veröffentlichte einen Artikel mit dem Titel Loop Engineering Is Dead. Enter Graph Engineering. Binnen einer Woche war der Begriff überall.

Es war vor allem ein Witz darüber, wie schnell dieses Feld neue Disziplinen prägt – von Prompt Engineering über Context Engineering, Harness Engineering und Loop Engineering zu Graph Engineering in rund achtzehn Monaten, mit weitgehend überlappenden Definitionen.

Der Witz zündete aber, weil er auf etwas Reales zeigt. Das ist der Teil, den man behalten sollte.

Drei Dinge, die Leute mit „Graph Engineering” meinen

Der Begriff kam mit mindestens drei verschiedenen Ideen an. Der Großteil der Online-Verwirrung besteht darin, dass Leute aneinander vorbeireden.

1. Orchestrierungsgraphen. Ein Multi-Agenten-System als expliziten Graphen entwerfen statt als while-Schleife: typisierte Knoten, typisierte Übergänge, Checkpoints zum Wiederaufsetzen. Das ist das Terrain von LangGraph und Temporal. Echtes Engineering – und vor allem relevant, wenn ihr Agenten-Infrastruktur baut.

2. Graphen aus Schleifen. Netze aus Selbstverbesserungszyklen, die einander beobachten. Konzeptionell interessant und nach überwiegender Einschätzung heute am wenigsten umsetzbar.

3. Graph-strukturiertes Wissen und Gedächtnis. Das Wissen des Agenten als typisierte Knoten und Kanten gespeichert, die er tatsächlich traversieren kann, statt als Haufen Dokumente, den er jedes Mal neu liest und neu errät.

Wer keine Orchestrierungs-Infrastruktur baut – und das sind die meisten von uns, auch jene, die zusehen, wie Agenten in den Workspace einziehen –, für den ist Nummer 3 die, die den Alltag verändert. Sie ist zugleich die älteste und am besten belegte der drei: Wissensgraphen gibt es seit Jahrzehnten vor dem Begriff.

Warum Kanten die Suche schlagen

Dieses Beispiel macht es klar.

Fragt einen Agenten: „Warum haben wir Redis für die Job-Queue aufgegeben?”

Volltextsuche liefert jedes Dokument, in dem „Redis” vorkommt – nach einiger Zeit sind das Dutzende Dateien, und keine davon ist die Antwort. Vektorsuche liefert Dokumente, die klingen wie die Frage, was oft schlimmer ist: semantisch nah, kausal irrelevant.

Ein Graph antwortet in drei Sprüngen:

Job-Queue --decided_by--> ADR-007 (Postgres-Queue)
ADR-007   --supersedes--> ADR-003 (Redis-Queue)
ADR-003   --caused------> Incident 2026-03-11

Die Antwort steht in keinem einzelnen Dokument. Sie liegt im Pfad dazwischen. Eine Suche kann keinen Pfad abrufen – sie ruft Knoten ab und hofft, dass ihr sie selbst verbindet.

Und beachtet das entscheidende Detail: Die Kanten sind benannt. supersedes ist nicht caused ist nicht decided_by. Nehmt die Labels weg, und ihr seid zurück bei „diese Dateien hängen irgendwie zusammen” – womit der Agent alle öffnen und die Beziehung erneut erschließen muss, genau die Arbeit, die ihr vermeiden wolltet.

Typisierte Kanten sind der ganze Trick. Der Rest ist Klempnerei.

Euer Markdown-Vault ist schon 80 % davon

Das ist die unterschätzte Beobachtung der ganzen Debatte: Ein gepflegter Markdown-Vault ist bereits der Großteil eines GraphRAG-Index.

Überlegt, was euch ein Notizen-Vault mit Wikilinks geschenkt gibt:

• Knoten – eine Datei pro Idee, Quelle oder Entscheidung
• Kanten – jeder [[Wikilink]] ist eine bewusst gesetzte Verbindung
• Entitätsauflösung by design gelöst – [[ADR-007]] ist überall derselbe Knoten. Kein Fuzzy Matching, keine Embedding-Kollisionen, kein „sind diese beiden Erwähnungen dasselbe?”

Letzteres ist keine Kleinigkeit. An der Entitätsauflösung zerbrechen die meisten automatischen Wissensgraph-Pipelines still und leise. Ein Vault umgeht das, weil ein Mensch die Entität einmal benannt hat und der Link die Identität ist.

Was einem schlichten Vault fehlt, sind die Labels. [[ADR-007]] sagt euch, dass zwei Notizen verbunden sind. Nicht, wie. Das sind die restlichen 20 %.

Wie das in der Praxis aussieht

Um diesen Teil herum wurde Minibase Vault gebaut, also lieber konkret zur Funktionsweise als abstrakt zur Möglichkeit.

Knoten entstehen beim Lesen. Ihr klickt die Minibase-Erweiterung auf alles Bewahrenswerte – Doku-Seite, RFC, X-Thread, Konferenzvortrag – und es landet als sauberes Markdown in einer lokalen Wissensbasis. Kein Copy-Paste, kein Exportschritt, kein „lese ich später”-Tab, der beim nächsten Browser-Absturz stirbt.

Kanten werden mit Begründung festgehalten. Der Vault führt eine _graph.json im Wurzelverzeichnis:

{
  "edges": [
    {
      "from": "AI Research/attention-paper-20260405-1200.md",
      "to": "AI Research/transformer-tutorial-20260408-0900.md",
      "reason": "Both explain the attention mechanism in transformers"
    }
  ]
}

Claude schreibt diese Kanten selbst, über den MCP-Server des Vaults, wenn es quer durch eure Notizen liest und eine Verbindung bemerkt. Sie tauchen dann als Related:-Zeilen in der _index.md jeder Wissensbasis auf, damit das Netz auch für euch sichtbar ist, nicht nur für das Modell.

Pfade verdichten sich zu Seiten. Wird ein Cluster verwandter Notizen dicht genug, kann Claude sie zu einer _topic-*.md-Seite synthetisieren, die ihre Quellen zitiert. Beim nächsten Fund in diesem Cluster ist die Seite schon da und wird aktualisiert. Das ist der Zinseszinseffekt: Der Vault wird klüger, nicht nur größer.

Verwaiste Notizen werden markiert. Ein lint-Durchlauf meldet Duplikate, verwaiste Notizen, veraltete Inhalte und Cluster, die reif für eine Synthese sind. Graphen verfallen; irgendetwas muss es bemerken.

Alles läuft lokal. Der Suchindex ist SQLite FTS5 mit BM25-Ranking, der Graph eine JSON-Datei, und nichts aus euren Notizen verlässt den Rechner.

Wo ich den Hype dämpfen würde

Zwei ehrliche Einschränkungen, denn dieser Begriff wurde in einer Woche populär, und Popularität überholt Substanz.

Minibases Kanten tragen eine Begründung, keinen formalen Typ. "reason": "Both explain the attention mechanism" ist ein Satz, kein supersedes. Weit besser als ein Wikilink ohne Label und weit entfernt von einer Ontologie. Wer strikt typisierte Relationen für Multi-Hop-Reasoning im großen Stil braucht, will eine echte Graphdatenbank – und sollte sich ehrlich über den Pflegeaufwand sein.

Die meisten brauchen nichts davon. Wenn euer Wissen aus fünfzig Notizen besteht, reicht Suche. Graphen zahlen sich aus, wenn ihr genug Material habt, um zu vergessen, was ihr habt – und wenn eure Fragen kausal sind („warum haben wir”) statt lexikalisch („wo habe ich gelesen”).

Der Begriff „Graph Engineering” überlebt das Jahr vermutlich nicht. Die Idee darunter – dass die Struktur zwischen euren Notizen mehr wert ist als die Menge der Notizen – galt lange, bevor sie einen Namen hatte, und gilt danach weiter.

Fangt mit der langweiligen Version an

1. Speichert Gelesenes als Markdown, statt es zu bookmarken. Ein Lesezeichen ist ein Zeiger auf etwas, das verrottet; eine Datei ist etwas, das ihr habt.
2. Haltet es lokal, in einem Ordner, eine Datei pro Quelle.
3. Lasst eure KI den ganzen Ordner lesen – über MCP, nicht per Copy-Paste – und stellt Fragen, die zwei Dokumente zur Beantwortung brauchen.
4. Haltet die gefundenen Verbindungen fest. Und fragt nächsten Monat erneut.

Das ist Graph Engineering für alle, die keine Orchestrierungs-Frameworks ausliefern. Es ist Context Engineering mit aufgeschriebenen Verbindungen.

---

Minibase verwandelt jede Webseite mit einem Klick in sauberes Markdown, direkt in einen lokalen Vault, den eure KI durchsuchen und verknüpfen kann. Die Erweiterung ist kostenlos mit unbegrenzten Speicherungen; Minibase Plus (5,99 $/Monat oder 34,99 $/Jahr) ergänzt KI-Vorlagen, Verlauf und Videotranskription. minibase.md.