Knowledge Graphs und Context Graphs: Wie KI-Agenten Unternehmenskontext verstehen
Je stärker KI-Agenten in Unternehmensprozesse eingebunden werden, desto wichtiger wird die Frage, wie sie Informationen einordnen. Ein Agent kann heute auf Dokumente zugreifen, Datenbanken abfragen, über APIs mit Anwendungen kommunizieren oder mithilfe von RAG Wissen aus unterschiedlichen Quellen einbeziehen. Damit ist technisch bereits viel möglich. Für verlässliches Handeln reicht dieser Zugriff allein aber nicht aus. Ein Agent muss nicht nur Informationen finden. Er muss auch verstehen, wie diese Informationen fachlich zusammengehören und was sie in einer konkreten Situation bedeuten. Genau an dieser Stelle werden Knowledge Graphs und Context Graphs interessant.
Vom Zugriff auf Informationen zum Verständnis von Zusammenhängen
Nehmen wir einen einfachen Geschäftsprozess. Ein Agent soll prüfen, ob ein Auftrag freigegeben werden kann. Dafür benötigt er möglicherweise Informationen über den Kunden, den bestehenden Vertrag, das bestellte Produkt, offene Rechnungen, Kreditlimits oder vereinbarte Konditionen. Diese Informationen können aus unterschiedlichen Systemen stammen. Technisch lassen sie sich über APIs, Datenbanken oder andere Schnittstellen verfügbar machen. Damit weiß der Agent aber noch nicht automatisch, wie diese Informationen miteinander zusammenhängen. Welcher Vertrag gehört zu welchem Kunden? Welche Produkte sind Bestandteil dieses Vertrags? Welche Rechnung gehört zu welchem Auftrag? Welche Definition gilt für einen bestimmten Status? Hier setzt ein Knowledge Graph an.
Knowledge Graphs bilden die fachliche Struktur ab
Ein Knowledge Graph beschreibt Entitäten und ihre Beziehungen zueinander. Ein vereinfachtes Modell könnte beispielsweise so aussehen:
Kunde → Vertrag → Produkt → Auftrag → Rechnung
Aus einzelnen Datenpunkten entsteht dadurch ein fachlicher Zusammenhang. Für einen KI-Agenten bedeutet das: Er erhält nicht nur Informationen, sondern auch eine explizite Beschreibung ihrer Beziehungen. Ein Knowledge Graph kann beispielsweise abbilden:
- welche Kunden zu welcher Organisation gehören,
- welche Verträge mit welchen Produkten verbunden sind,
- welche Aufträge auf Grundlage eines Vertrags entstanden sind,
- welche Verantwortlichkeiten für bestimmte Daten gelten,
- oder wie zentrale Geschäftsbegriffe definiert sind.
Damit entsteht eine semantische Struktur, die über einzelne Tabellen, Dokumente oder APIs hinausgeht. Sie beschreibt gewissermaßen das „Was“ und „Wer“ einer Organisation. Für Agentic AI reicht diese Perspektive allein jedoch nicht immer aus.
Context Graphs ergänzen das „Wie“ und „Warum“
Bleiben wir beim Beispiel der Auftragsfreigabe. Der Knowledge Graph kann dem Agenten zeigen, dass ein Kunde einen bestimmten Vertrag besitzt und welche Rechnung zu welchem Auftrag gehört. Für die konkrete Entscheidung können aber weitere Informationen relevant sein:
- Welche Freigaben wurden bereits erteilt?
- Welche Policy gilt in dieser Situation?
- Befindet sich der Auftrag in einem Sonderprozess?
- Gab es eine Ausnahme?
- Welche Entscheidung wurde in einem vergleichbaren Fall getroffen?
- Welche Informationen lagen dabei vor?
Genau hier kommt der Context Graph ins Spiel. Während ein Knowledge Graph eher stabile fachliche Beziehungen beschreibt, bildet ein Context Graph den situativen Zusammenhang ab. Er macht sichtbar, was in einem konkreten Prozess passiert ist, unter welchen Bedingungen eine Entscheidung getroffen wurde und welche Regeln dabei eine Rolle gespielt haben.
Vereinfacht gesagt: Der Knowledge Graph beschreibt die fachliche Struktur.
Der Context Graph ergänzt die konkrete Situation. Für einen Agenten entsteht damit ein deutlich vollständigeres Bild. Er weiß nicht nur, welche Objekte miteinander verbunden sind, sondern kann auch besser nachvollziehen, welche Informationen für eine konkrete Entscheidung relevant sind.
Ein Beispiel: Auftragsfreigabe durch einen KI-Agenten – Ein Agent soll entscheiden, ob ein Auftrag automatisiert weiterverarbeitet werden kann.
Der Knowledge Graph liefert beispielsweise:
Kunde
→ besitzt Vertrag
→ Vertrag umfasst Produkt
→ Kunde hat offene Rechnung
→ Rechnung gehört zu früherem Auftrag
Der Context Graph ergänzt:
Auftrag befindet sich im Prüfprozess
→ Kreditlimit überschritten
→ Sonderfreigabe liegt vor
→ zuständiger Mitarbeiter hat Ausnahme bestätigt
→ Policy erlaubt Weiterverarbeitung
Erst die Kombination beider Perspektiven liefert den Kontext, den der Agent benötigt. Der Knowledge Graph erklärt, was miteinander verbunden ist. Der Context Graph erklärt, was gerade passiert und warum eine bestimmte Entscheidung zulässig sein kann.
Abgrenzung der Architekturbausteine: RAG, APIs, MCP und Context Layer
Knowledge Graphs und Context Graphs ersetzen weder RAG noch APIs oder MCP, sondern ergänzen diese um eine andere Ebene. APIs stellen Daten und Funktionen bereit, RAG macht relevante Informationen aus Dokumenten und Wissensbeständen für ein Modell verfügbar und MCP standardisiert die Interaktion mit Tools und Kontextquellen. Damit schaffen diese Technologien vor allem den technischen Zugang. Ein semantischer und kontextueller Layer hilft zusätzlich dabei, die verfügbaren Informationen fachlich einzuordnen: Was bedeutet eine Information im jeweiligen Unternehmenskontext? Wie hängt sie mit anderen Informationen zusammen? Welche Quelle ist verbindlich und welche Regeln gelten in der konkreten Situation? Besonders relevant wird diese Unterscheidung, wenn ein Agent nicht nur Informationen bereitstellen, sondern Entscheidungen vorbereiten oder selbst Aktionen auslösen soll.
Context Engineering wird damit zur Architekturaufgabe
In unserem früheren Beitrag zu Context Engineering und Harness Engineering haben wir Context Engineering über eine zentrale Frage beschrieben: Was muss ein Agent in dieser Situation wissen, um fundiert entscheiden zu können? Knowledge Graphs und Context Graphs können eine Grundlage dafür schaffen, weil sie Unternehmenswissen nicht nur zugänglich, sondern Zusammenhänge und Kontext maschinenlesbar machen. Damit berührt Context Engineering unmittelbar klassische Themen aus Data Management und Data Governance. Dazu gehören ein gemeinsames Verständnis zentraler Geschäftsbegriffe, Data Ownership, semantische Modelle und Datenqualität ebenso wie Rollen, Berechtigungen, Business Rules und die Nachvollziehbarkeit von Entscheidungen. Für uns ist Context Engineering deshalb nicht nur ein AI-Thema, sondern ebenso eine Frage der Data Architecture und Enterprise Architecture.
Der Einstieg muss nicht das ganze Unternehmen umfassen
Das bedeutet allerdings nicht, dass Unternehmen zunächst einen umfassenden Knowledge Graph über ihre gesamte Organisation aufbauen müssen. Für einen ersten Anwendungsfall ist ein klar abgegrenzter Ansatz meist sinnvoller. Wir würden mit einer Business Domain und einem konkreten Prozess beginnen und dafür die relevanten Business Objects, ihre Beziehungen, die wichtigsten Regeln und den notwendigen situativen Kontext modellieren. So lässt sich konkret prüfen, welchen Mehrwert ein semantischer Context Layer für den jeweiligen Agenten bringt. Von dort aus kann die Struktur schrittweise um weitere Prozesse und Domänen erweitert werden.
Je autonomer der Agent, desto wichtiger wird Kontext
Solange ein KI-System Informationen zusammenfasst, recherchiert oder Inhalte erstellt, können Menschen Unklarheiten häufig noch auffangen. Mit zunehmender Autonomie verändert sich diese Situation. Wenn Agenten Entscheidungen vorbereiten, Tools einsetzen und Aktionen in operativen Systemen auslösen, müssen sie den fachlichen Kontext verlässlich einordnen können. Ein produktiver Agent muss deshalb nicht möglichst viel über ein Unternehmen wissen. Entscheidend ist, dass er die für die jeweilige Situation relevanten Informationen kennt, ihre Zusammenhänge versteht und weiß, innerhalb welcher Regeln er handeln darf. Genau hier sehen wir das Zusammenspiel von Knowledge Graphs, Context Graphs und Context Engineering als wichtigen Baustein zukünftiger Agentenarchitekturen.
Autor: Claudia Caruso
