Goal
Das Ziel oder die Leitfrage des Arbeitsprozesses. Ohne Goal wird der Graph schnell nur ein Log.
Architektur-Detail · Agenten-Kontext
Jeder Reasoning-Schritt eines Agenten wird als Knoten im Graphen gespeichert — mit Zeitstempel, Ausgangszustand, Entscheidung und Ergebnis. Kanten verbinden Entscheidungsschritte zu nachvollziehbaren Kausalketten. Für regulierte Branchen ist das oft eine Voraussetzung, nicht ein Nice-to-have.
Kuratierte Architekturentscheidung auf Basis der lokalen Compass-Daten
Relevant wenn
Wenn Agenten-Handlungen auditierbar sein müssen, regulatorische Anforderungen bestehen oder Entscheidungen über Zeit rekonstruierbar sein sollen.
Quellenlage
Compass-Komposition aus realen Bausteinen: LangGraph-State, Tracing, Graphiti/Zep-Kontextgraphen und Auditierbarkeit. Der Name ist ein Compass-Begriff, kein offizieller Standard.
Agenten-Handlungen, Reasoning-Schritte und Entscheidungen sollen nachvollziehbar, auditierbar und persistent sein.
Systemkarte
Die Motion Map verdichtet das Muster auf seine wichtigsten Stationen: Eingabe, Daten- oder Graphschicht, Retrieval, Kontrolle und Antwort. Sie ist bewusst kleiner als die Referenzarchitektur darunter und soll zuerst die Leserichtung und die Systemgrenzen sichtbar machen.
Architekturblick
Diese Seite ist eine Entscheidungshilfe für den Stack. Der Blick liegt auf Datenfluss, Failure Modes, Evaluation, Tooling und dem nächsten sinnvollen Migrationsschritt.
Während einer Aufgabe werden Ziele, Quellen, Claims, Tool-Ergebnisse, Entscheidungen und offene Fragen als Arbeitsgraph gepflegt. Der Graph steuert nächste Schritte und macht Herleitung sichtbar.
Mit Task Graph für einzelne Arbeitsschritte starten, dann Tool Traces, Decision Graph und auditierbare Übergaben ergänzen.
Referenzarchitektur
Ein Context Graph beschreibt den aktuellen Arbeitszustand eines Agenten oder Workflows. Anders als Agent Memory ist er ein strukturierter Zwischenstand: Ziel, Quellen, Claims, Tool-Ergebnisse, Entscheidungen und offene Fragen bleiben explizit sichtbar.
01
Ein Ziel, eine Frage, ein Nutzerauftrag oder ein Workflow startet den Context Graph. Der Graph beschreibt den aktuellen Arbeitszustand.
02
Quellen, Claims, Annahmen, offene Fragen, Entscheidungen, Tool-Ergebnisse und Zwischenergebnisse werden als eigene Knoten sichtbar.
03
Kanten zeigen, welche Quelle welchen Claim stützt, welche Entscheidung aus welcher Analyse folgt und welche Frage noch offen ist.
04
Der Agent nutzt den Context Graph, um nächste Schritte zu planen, Lücken zu erkennen und nicht dieselbe Arbeit mehrfach zu tun.
05
Neue Beobachtungen, Tool-Antworten, Nutzerkorrekturen und Entscheidungen verändern den Graph während der Aufgabe.
06
Am Ende bleibt nachvollziehbar, welche Quellen, Zwischenschritte und Entscheidungen zur Antwort geführt haben.
Implementierungs-, Integrations- und Betriebsaufwand.
Qualität, Struktur und Zugänglichkeit der Daten vor dem Pilot.
Erfahrung mit RAG, Graphdenken, Infrastruktur und Evaluation.
Tracing, Archivierung und Löschkonzepte noch nicht geklärt sind.
Audit-Graphen wachsen schnell — Archivierungs- und Pruning-Strategien müssen von Anfang an mitgeplant werden. Jeder Reasoning-Schritt kostet zusätzliche Schreib-Latenz. Debugging komplexer Kausalketten erfordert spezialisiertes Graph-Tooling.
Graphmodell
Der Context Graph wird nützlich, wenn Arbeitszustände typisiert werden. Dann kann ein Agent gezielt fragen: Welche Claims sind belegt? Welche Quellen fehlen? Welche Entscheidungen wurden schon getroffen?
Das Ziel oder die Leitfrage des Arbeitsprozesses. Ohne Goal wird der Graph schnell nur ein Log.
Dokument, API-Antwort, Datenbankauszug, Mail, Ticket oder Webseite, aus der Kontext stammt.
Eine prüfbare Aussage, die aus Quellen oder Tool-Ergebnissen abgeleitet wurde.
Eine getroffene Entscheidung inklusive Begründung, Alternativen und verantwortlichem Schritt.
Eine Lücke im Kontext, die noch recherchiert, geklärt oder vom Nutzer beantwortet werden muss.
Ein konkretes Ergebnis eines Tools, inklusive Parameter, Zeitpunkt, Status und möglicher Fehler.
Qualitätshebel
Context Graphs können Agentenarbeit transparent machen, aber auch sehr schnell unübersichtlich werden. Die Architektur muss entscheiden, was wirklich als Zustand zählt und wie lange dieser Zustand lebt.
Wenn jeder Zwischenschritt ungefiltert gespeichert wird, entsteht Rauschen. Der Graph braucht klare Typen und Speicherkriterien.
Eine Quelle ist nicht automatisch eine Wahrheit. Claims sollten explizit mit Evidenz, Unsicherheit und Herkunft verbunden werden.
Ein Context Graph ist besonders nützlich, wenn er Wissen speichert und zeigt, was noch unklar ist.
Context Graphs sind oft auf Aufgaben oder Fälle bezogen. Ohne Archivierungs- und Löschstrategie werden sie zu unkontrolliertem Memory.
Ausbaustufen
Der Context Graph kann klein starten: ein Ziel, ein paar Quellen, Claims und offene Fragen. Erst wenn dieser Arbeitszustand nützlich ist, lohnt sich der Ausbau zu Tool-Traces, Entscheidungsgraphen und auditierbaren Workflows.
Stufe 1
Starte mit Ziel, Quellen, Claims und offenen Fragen für eine einzelne Aufgabe.
Stufe 2
Ergänze Tool-Aufrufe, Parameter, Ergebnisse und Fehler, damit Agentenarbeit nachvollziehbar wird.
Stufe 3
Modelliere Entscheidungen, Begründungen, Alternativen und Auswirkungen über mehrere Schritte.
Stufe 4
Ergänze Rollen, Aufbewahrung, Review, Export und Verbindung zu Agent Memory oder Governance.
In welchem Kontext das Muster typischerweise Sinn ergibt und welchen Beitrag es dort leistet.
Ein Agent recherchiert, filtert Quellen und erstellt eine Empfehlung.
Der Context Graph hält Zwischenschritte und Kontextzustände fest.
Risiken, Entscheidungen und Verantwortlichkeiten ändern sich fortlaufend.
Die Pipeline aktualisiert Kontext, Verlauf und neue Textchunks gemeinsam.
Ein Agent soll Tools und Plattformen für GraphRAG vergleichen. Während der Arbeit entstehen Quellen, Claims, offene Fragen, Zwischenentscheidungen und ausgeschlossene Optionen.
Der Context Graph hält diesen Arbeitszustand fest, damit später nachvollziehbar bleibt, warum eine Empfehlung entstanden ist.
Audit-Ereignisse modellieren
Aufbewahrungsregeln festlegen
Tracing vor autonomen Aktionen einführen