{
  "title": "Was sind Context Graphs wirklich?",
  "excerpt": "Die Diskussion um Context Graphs ist explodiert, aber der Begriff selbst ist zu einem Rorschach-Test geworden. Es geht nicht darum, deinem Agenten Speicher hinzuzufügen – es geht darum, unsere Annahmen über Daten, Zeit und organisatorisches Wissen zu überdenken. Das Zwei-Uhren-Problem zeigt, warum wir die Hälfte der Zeit in Unternehmenssystemen übersehen und warum dies grundlegend ein Repräsentationsproblem ist, kein Datenbankproblem.",
  "content_html": "<p>Letzte Woche schrieb ich über meine Reaktion auf Jaya Guptas viralen Post über Context Graphs [1]. Die Idee eines \"Systems of Record für Entscheidungen\" hatte eine tiefe Resonanz und rahmte die Evolution der agentenbasierten Infrastruktur von Tools über Skills bis hin zu Memory. Aber seitdem ist die Diskussion explodiert, und es ist klar geworden, dass der Begriff \"Context Graph\" selbst ein bisschen ein Rorschach-Test ist. Jeder sieht etwas anderes.</p>\n\n<p>Animesh Koratana, Gründer von PlayerZero, hat eine Reihe von Follow-up-Posts geschrieben, die durch den Lärm schneiden und zum Kern dessen vordringen, was ein Context Graph tatsächlich ist und warum er strukturell so schwer zu bauen ist [2] [3]. Seine Erkenntnisse sind entscheidend für jeden, der ernsthaft daran interessiert ist, agentenbasierte KI im Unternehmen aufzubauen. Es geht nicht darum, \"deinem Agenten Speicher hinzuzufügen\" oder eine Graphdatenbank zu verkabeln. Es geht darum, unsere Annahmen über Daten, Zeit und die Natur organisatorischen Wissens zu überdenken.</p>\n\n<h2>Das Zwei-Uhren-Problem: Warum wir die Hälfte der Zeit verpassen</h2>\n\n<p>Koratanas wichtigste Erkenntnis ist das, was er das <strong>Zwei-Uhren-Problem</strong> nennt. Wir haben Infrastruktur im Wert von Billionen Dollar für die <strong>Zustandsuhr</strong> gebaut: was gerade jetzt wahr ist. Dein CRM speichert den finalen Deal-Wert. Dein Ticketing-System speichert \"gelöst\". Deine Codebasis speichert den aktuellen Zustand.</p>\n\n<p>Aber wir haben fast keine Infrastruktur für die <strong>Ereignisuhr</strong>: was passiert ist, in welcher Reihenfolge und mit welcher Begründung. Das Git Blame zeigt <em>wer</em> das Timeout von 5s auf 30s geändert hat, aber das <em>warum</em> ist verschwunden. Das CRM sagt \"closed lost\", aber es sagt nicht, dass du die zweite Wahl warst und der Gewinner ein Feature hatte, das du nächstes Quartal auslieferst. Wie Koratana es ausdrückt:</p>\n\n<blockquote>\n<p>\"Wir haben Infrastruktur im Wert von Billionen Dollar dafür gebaut, was jetzt wahr ist. Fast nichts dafür, warum es wahr wurde.\"</p>\n</blockquote>\n\n<p>Das ist der Kern des Problems. Wir bitten Agenten, Urteilsvermögen auszuüben, ohne Zugang zu Präzedenzfällen. Wir trainieren Anwälte mit Urteilen ohne Fallrecht. Der Context Graph ist die Infrastruktur für die Ereignisuhr. Er ist das Fallrecht des Unternehmens.</p>\n\n<h2>Das Fünf-Koordinatensysteme-Problem: Warum dies kein Datenbankproblem ist</h2>\n\n<p>Warum können wir also nicht einfach eine bessere Datenbank bauen? Weil ein Context Graph Joins über fünf verschiedene Koordinatensysteme erfordert, die keine gemeinsamen Schlüssel haben:</p>\n\n<ol>\n<li><strong>Ereignisse</strong>: Was ist passiert?</li>\n<li><strong>Zeitlinie</strong>: Wann ist es passiert?</li>\n<li><strong>Semantik</strong>: Was bedeutet es?</li>\n<li><strong>Zuordnung</strong>: Wer war dafür verantwortlich?</li>\n<li><strong>Ergebnis</strong>: Was hat es verursacht?</li>\n</ol>\n\n<p>Jedes davon hat eine andere Geometrie. Zeitlinien sind linear. Ereignisse sind sequenziell. Semantik lebt im Vektorraum. Zuordnung ist graphenstrukturiert. Ergebnisse sind kausale DAGs. Und die Schlüssel sind fließend. \"Jaya Gupta\" in einer E-Mail, \"J. Gupta\" in einem Vertrag und \"@JayaGup10\" in Slack sind dieselbe Entität ohne gemeinsamen Identifikator.</p>\n\n<p>Traditionelle Datenbanken sind für Joins auf stabilen Schlüsseln innerhalb eines einzigen Koordinatensystems gebaut. Context Graphs erfordern probabilistische Joins über alle fünf gleichzeitig. Dies ist kein Datenbankproblem; es ist ein Repräsentationsproblem.</p>\n\n<h2>Agenten als informierte Wanderer: Wie wir das Repräsentationsproblem lösen</h2>\n\n<p>Wenn die Ontologie jeder Organisation unterschiedlich und ständig im Wandel ist, wie können wir jemals hoffen, sie zu modellieren? Koratanas Antwort ist, dass wir das nicht müssen. Die Agenten tun es für uns.</p>\n\n<p>Wenn ein Agent ein Problem durcharbeitet, ist seine Trajektorie eine Spur durch den Zustandsraum der Organisation. Es ist eine implizite Karte der Ontologie, die durch Nutzung entdeckt wird, anstatt im Voraus spezifiziert zu werden. Dies ist die zentrale Erkenntnis aus dem Graph Representation Learning (node2vec): Du musst die Struktur eines Graphen nicht kennen, um Repräsentationen davon zu lernen. Du musst ihn nur durchlaufen.</p>\n\n<p>Agenten sind <strong>informierte Wanderer</strong>. Ihre Trajektorien sind nicht zufällig; sie sind problemorientiert. Durch die Akkumulation genug dieser Trajektorien können wir Embeddings lernen, die die Struktur der Organisation kodieren. Wir können lernen, dass zwei Ingenieure, die nie interagieren, strukturell äquivalent sind, weil sie dieselbe Rolle in verschiedenen Untergraphen spielen. Wir können lernen, dass eine bestimmte Abfolge von Ereignissen ein Vorbote für Churn ist, auch wenn diese Ereignisse nie explizit verknüpft wurden.</p>\n\n<h2>Was das tatsächlich für Builder bedeutet</h2>\n\n<p>Was ist also ein Context Graph wirklich? Er ist keine Graphdatenbank. Er ist kein Vector Store. Er ist eine <strong>gelernte Repräsentation organisatorischen Denkens, abgeleitet aus den Trajektorien von Agenten, die Probleme lösen</strong>.</p>\n\n<p>Dies hat tiefgreifende Implikationen dafür, wie wir agentenbasierte Systeme bauen:</p>\n\n<ol>\n<li><strong>Die Agenten bauen nicht den Context Graph; sie lösen Probleme, die es wert sind, gelöst zu werden.</strong> Der Context Graph ist eine emergente Eigenschaft ihrer Arbeit. Der Fokus sollte darauf liegen, Agenten in echte Workflows einzusetzen, nicht darauf, im Voraus eine perfekte Ontologie zu bauen.</li>\n<li><strong>Der Wert liegt in den Trajektorien, nicht im Zustand.</strong> Wir müssen unseren Fokus vom Speichern des finalen Zustands auf das Erfassen der vollständigen, wiederabspielbaren Historie verlagern, wie dieser Zustand erreicht wurde.</li>\n<li><strong>Dies ist ein Machine-Learning-Problem, kein Data-Engineering-Problem.</strong> Das Ziel ist nicht, ein perfektes Datenmodell zu bauen, sondern eine Repräsentation zu lernen, die für das Denken nützlich ist.</li>\n</ol>\n\n<p>Einen Context Graph zu bauen bedeutet nicht, eine neue Software zu kaufen. Es bedeutet einen fundamentalen Wandel darin, wie wir über Daten, Zeit und die Natur der Arbeit im agentenbasierten Zeitalter denken. Es bedeutet zu erkennen, dass unser wertvollstes Asset nicht unsere Daten sind, sondern die akkumulierte Weisheit der Entscheidungen, die wir jeden Tag treffen. Und es bedeutet, die Infrastruktur zu bauen, um diese Weisheit endlich zu erfassen und zum Einsatz zu bringen.</p>\n\n<p><strong>Referenzen:</strong></p>\n\n<p>[1] <a href=\"https://x.com/JayaGup10/status/2003525933534179480\">Gupta, J. (2025, 23. Dezember). <em>AI's trillion-dollar opportunity: Context graphs</em>. X.</a></p>\n\n<p>[2] <a href=\"https://www.linkedin.com/pulse/why-context-graphs-rare-wild-animesh-koratana-3wzte/\">Koratana, A. (2026, 1. Januar). <em>Why context graphs are rare in the wild</em>. LinkedIn.</a></p>\n\n<p>[3] <a href=\"https://www.linkedin.com/pulse/how-build-context-graph-animesh-koratana-6abve\">Koratana, A. (2025, 28. Dezember). <em>How to build a context graph</em>. LinkedIn.</a></p>",
  "source_hash": "sha256:c9f8cb57d671053bc8f97aa3c11eeb86305f270ab5994d742a815877626e63fb",
  "model": "claude-sonnet-4-5-20250929",
  "generated_at": "2026-01-02T02:10:03.460388+00:00"
}