Effizienz von KI-Agenten (I)

 

Je mehr KI-Agenten Unternehmen einsetzen, desto schneller steigen die Kosten. Vor allem, wenn jeder Agent Wissen, Regeln und Kontext bei jeder Aufgabe neu rekonstruieren muss. Eine gemeinsame Knowledge Layer verlagert die ureigene Geschäftslogik in eine kontrollierte Infrastruktur.

Management Summary

• Wissen zentral statt agentenweise: Geschäftsbegriffe, Regeln und Kontext gehören in eine gemeinsam verwaltete Schicht, nicht in isolierte Prompts und Tools.
• Drei Bausteine tragen die Architektur: Ontologien beschreiben Bedeutung und Beziehungen, Unternehmensdaten verankern das Modell in der Realität, Memory bewahrt bewährte Entscheidungen.
• Kosten entstehen im Betrieb: Redundanter Kontext erhöht Tokenverbrauch, Pflegeaufwand und das Risiko widersprüchlicher Ergebnisse.
• Governance ist Teil der Plattform: Fachbereiche verantworten Semantik und Regeln, Plattformteams Technik und Betrieb; zentrale Leitplanken sichern Zugriff, Qualität und Nachvollziehbarkeit.
• Der Einstieg sollte fokussiert erfolgen: Ein klar abgegrenzter Anwendungsfall mit messbarem Nutzen schafft die Basis für eine schrittweise erweiterbare Knowledge Layer.

 

KI-Agenten lassen sich schnell entwickeln – doch mit jedem neuen Einsatz wächst die Gefahr widersprüchlicher Regeln, redundanter Wissensbestände und steigender Betriebskosten. Eine zentrale Knowledge Layer bündelt Ontologien, Unternehmensdaten und Erfahrungswissen zu einer kontrollierbaren Infrastruktur. Sie schafft damit die Grundlage dafür, dass Agenten konsistent, nachvollziehbar und effizient auf den geschäftlichen Kontext zugreifen können.

Wenn KI im Unternehmen scheitert, liegt es meist nicht am Modell. Leistungsfähige LLMs werden laufend besser, auch Tools, Orchestrierung, Evaluierung und Guardrails sind gereift. Unternehmen wissen, wie sich KI-Agenten entwickeln und einsetzen lassen. Trotzdem erzielen sie mit vergleichbaren Modellen und Agenten-Stacks sehr unterschiedliche Ergebnisse. Der entscheidende Hebel liegt woanders: darin, wie gut die KI das Unternehmen und seinen geschäftlichen Kontext versteht.

Warum dieses Verständnis fehlt, hat einen einfachen Grund: Geschäftliche Semantik und institutionelles Wissen sind oft nie explizit erfasst worden. Anwendungen und Menschen brachten den nötigen Kontext bisher selbst mit. Eine Anwendung weiß, dass ein Auftrag über 100.000 Euro eine zusätzliche Freigabe erfordert; ein Sachbearbeiter ebenso. Dieses Wissen steckt im Code oder in den Köpfen der Mitarbeitenden – aber nicht dort, wo ein KI-Agent darauf zugreifen kann.

 

Warum Wissen nicht in den Agenten gehört

Die logische Reaktion wäre, jedem Agenten das benötigte Wissen direkt mitzugeben: Geschäftsdefinitionen wandern in den Prompt, Regeln in ein Tool auf einem MCP-Server, zusätzlicher Kontext kommt über eine Retrieval-Pipeline. Für einzelne Anwendungen funktioniert das gut. Doch damit verteilt sich ein Teil der Geschäftssemantik auf die jeweiligen Agenten.

Skaliert man dieses Muster auf zehn Agenten, entstehen zehn separate Abbilder des Unternehmenswissens. Solche semantischen Duplikate driften zwangsläufig auseinander. Die Definition eines »freigegebenen Lieferanten« wird beispielsweise in einem MCP-Server angepasst, später in einem anderen Agenten-Prompt – und fehlt in einem dritten vielleicht ganz. Kein Alarm weist auf den Widerspruch hin. Das Unternehmen verliert schleichend eine einheitliche Sicht auf die eigene Geschäftslogik.

Agenten sind schnell gebaut. Teuer wird es, sie so zu betreiben, dass sie dauerhaft konsistente Ergebnisse liefern. Hinzu kommt der Tokenverbrauch: Anthropic berichtete aus dem Betrieb seines Research-Systems, dass Agenten etwa viermal so viele Tokens verbrauchten wie Chat-Interaktionen, Multi-Agent-Systeme sogar rund 15-mal so viele [1]. Noch mehr Logik und Kontext in jeden einzelnen Agenten zu packen, verschärft das Problem. Jede Ergänzung schafft eine weitere Wissenskopie, die gepflegt und synchronisiert werden muss.

 

Eine einheitliche Wissens-Infrastruktur

Die Lösung folgt einem anderen Prinzip: Statt Geschäftslogik, Definitionen und Kontext in einzelne Agenten einzubauen, werden sie in einer gemeinsamen, kontrollierten Knowledge Layer gebündelt. Diese Wissensschicht stützt sich auf drei zentrale Bausteine:

• Die Ontologie bildet in einem formal definierten, vernetzten Modell ab, wie das Unternehmen tatsächlich funktioniert. Dazu gehören die fachlichen Begriffe und Domänenmodelle ebenso wie Rollen und Verantwortlichkeiten, Übergaben zwischen Teams, Geschäftsprozesse sowie die Systeme und Datenbestände, auf denen diese Prozesse beruhen. Auch Regeln und Abhängigkeiten sind Teil dieses Modells – etwa, dass eine Rückerstattung den ursprünglichen Rechnungsbetrag nicht überschreiten darf oder dass ein Datenprodukt auf einer zugänglichen Datenquelle basieren muss. Hinzu kommen die Verknüpfungen zwischen den fachlichen Elementen und den zugrunde liegenden technischen Ressourcen.
• Unternehmensdaten verankern das in der Ontologie beschriebene Domänenmodell in der betrieblichen Realität. Referenzdaten lassen sich dabei häufig als Erweiterung der Ontologie verwalten. Sie definieren beispielsweise kontrollierte Wertebereiche für bestimmte Begriffe – etwa eine verbindliche Liste zulässiger Länder statt uneinheitlicher Einträge in einzelnen Datenfeldern. Stamm- und Transaktionsdaten können dagegen in den bestehenden Systemen verbleiben und dort abgefragt oder als materialisierte beziehungsweise virtualisierte Domain Graphs in die Knowledge Layer eingebunden werden. Welcher Ansatz sich eignet, hängt von Architektur und Anwendungsfall ab.
• Die Gedächtniskomponente (Memory) erweitert die Knowledge Layer um Erfahrungswissen aus früheren Interaktionen. Jede Nutzung kann Entscheidungsspuren hinterlassen und damit festhalten, welche Vorgehensweise sich in einer bestimmten Situation bewährt hat. Muss ein Agent bei einer Kontoeröffnung beispielsweise die Identität eines Kunden prüfen, kann die Ontologie vorgeben, welche Systeme dafür grundsätzlich infrage kommen. Die Gedächtniskomponente hält dagegen fest, welche Quelle sich in vergleichbaren Fällen als schneller oder zuverlässiger erwiesen hat. Vereinfacht gesagt: Die Ontologie beschreibt, was möglich ist. Die Gedächtniskomponente hält fest, was sich in der Praxis bewährt hat. Wissen, das früher im Kopf eines Analysten oder in einem abgeschlossenen Ticket verblieb, kann so während der Arbeit erfasst und bei späteren Entscheidungen wieder genutzt werden.

 

Abb. 1.: Aufbau der Knowledge Layer aus Ontologien, Daten und Memory

 

Architektonische Schicht zwischen Daten und Agenten

Die Knowledge Layer ist mehr als eine BI Semantic Layer oder eine zusätzliche Context Layer für Retrieval. Anders als etwa ein Datenkatalog enthält sie nicht nur Definitionen, sondern lässt sich aktiv abfragen und in Prozesse einbinden. Architektonisch liegt sie zwischen den Datenbeständen eines Unternehmens und den Agenten beziehungsweise Anwendungen, die darauf zugreifen.

Dabei reicht es nicht, das benötigte Wissen einmal auszulesen und im Kontext des Agenten vorzuhalten. Dafür ist die Knowledge Layer nicht nur zu umfangreich, sondern auch zu dynamisch: Definitionen ändern sich, Datenquellen wechseln und neues Erfahrungswissen kommt hinzu. Agenten greifen deshalb während ihrer Arbeit kontinuierlich auf die Knowledge Layer zu und beziehen jeweils genau die Informationen, Regeln und Zusammenhänge ein, die sie für eine konkrete Anfrage benötigen.

 

Was bei der Umsetzung zu beachten ist

Beim Aufbau und Betrieb einer Knowledge Layer sind neben der technischen Architektur auch organisatorische und methodische Faktoren zu berücksichtigen.

• Maßgeschneidertes Wissen: Eine Knowledge Layer ist in der Regel keine fertige Standardlösung. Anbieter können jedoch die technische Basis liefern – etwa Graphplattform, Datenkatalog oder Policy Engine. Neue Tools können den Aufbau zusätzlich deutlich beschleunigen und Unternehmen dabei unterstützen, die Inhalte zu definieren und die Knowledge Layer an ihren spezifischen Anforderungen auszurichten. Dazu gehören Geschäftsbegriffe, Datenlandschaft, Governance-Regeln und Vorgaben für das Verhalten von Agenten. Graphtechnologie eignet sich dafür besonders, weil sie nicht nur einzelne Daten und Informationen abbildet, sondern auch deren Beziehungen zueinander – und damit den fachlichen Kontext, in dem sie stehen.
• Hybrider Ansatz: Beim Aufbau der Knowledge Layer schlägt die KI mögliche Definitionen, Zuordnungen oder maßgebliche Datenquellen vor; Fachverantwortliche prüfen und bestätigen sie. Branchenmodelle, Standards und bewährte Muster können den Aufbau zusätzlich beschleunigen. Die unternehmensspezifischen Entscheidungen bleiben allerdings in der Verantwortung der Organisation.
• Kontinuierliche Weiterentwicklung: Die Knowledge Layer entwickelt sich mit ihrer Nutzung weiter. Jede Anfrage, mehrdeutige Definition oder überraschende Zuordnung zeigt, wo die Wissensschicht noch zu dünn ist oder nachgeschärft werden muss. Solche Erkenntnisse fließen kontinuierlich zurück und verbessern die Qualität der Knowledge Layer im laufenden Betrieb. Vieles lässt sich dabei automatisieren, Fachverantwortliche sind weiterhin in die Prüfungs- und Freigabeprozesse eingebunden.
• Gemeinsame Infrastruktur, verteilte Verantwortung: Eine Knowledge Layer darf kein Projekt eines einzelnen Teams sein. Fachbereiche verantworten Begriffe, Regeln und Zuordnungen, Plattformteams die technische Basis. Übergreifende Governance sorgt für Konsistenz und setzt Zugriffs- und Risikovorgaben bei der Abfrage durch, während die Domänen ihre fachlichen Definitionen kontrollieren. Ähnlich wie beim Data Mesh liegt die Verantwortung damit möglichst nah an den Fachbereichen – und zwar für Bedeutung, Zuordnung und Nutzung.

Unternehmen gewinnen KI-Vorsprung durch belastbares, unternehmensweit abgestimmtes Verständnis des eigenen Geschäfts. Wer dieses Wissen strukturiert, zugänglich macht und verankert, gibt seinen Agenten den Kontext für effizientes Handeln. Die Frage ist nicht, ob Unternehmen ihr Wissen neu organisieren müssen – sondern wie lange sie es sich noch leisten können, darauf zu verzichten.

Dr. Jesús Barrasa, AI Field CTO, Neo4j

Dr. Jesús Barrasa ist Experte für semantische Technologien und Graphdatenbanken. Bei Neo4j leitet er das Solutions-Architecture-Team in EMEA und verantwortet die Entwicklung von neosemantics, einem Neo4j-Plugin für RDF. Er ist Mitautor mehrerer Fachbücher über Knowledge Graphen und Datenkontext sowie Co-Host des Live-Webcasts Going Meta. https://neo4j.com/

 

 

Tipps für den Aufbau einer Knowledge Layer

• Mit einem geschäftskritischen Use Case starten: Wählen Sie einen Prozess, dessen Regeln, Datenquellen und Erfolgskriterien klar benennbar sind.
• Begriffe zuerst klären: Dokumentieren Sie Definition, Eigentümer, zulässige Werte und Beziehungen zentral, bevor Agenten darauf zugreifen.
• Quellen und Herkunft mitführen: Jede Wissenseinheit sollte auf eine verantwortliche Quelle, Version und Freigabe zurückführbar sein.
• Zugriffe auf Wissensebene steuern: Übernehmen Sie Berechtigungen und Klassifizierungen aus den Quellsystemen auch in Graph, Index und Cache.
• Änderungen versionieren: Behandeln Sie Ontologien, Regeln und Mapping wie Produktartefakte mit Review, Tests und Rückfalloption.
• Qualität kontinuierlich messen: Beobachten Sie Trefferqualität, widersprüchliche Antworten, Quellenabdeckung, Latenz und Tokenkosten.
• Memory begrenzen: Legen Sie fest, welche Erfahrungen gespeichert werden dürfen, wie lange sie gelten und wer sie korrigieren kann.
• Fachbereiche verbindlich einbinden: Technische Teams stellen die Plattform bereit; die Verantwortung für Bedeutung und Regeln bleibt in den Domänen.

 

 

FAQ: Knowledge Layer für KI-Agenten

1. Was ist eine Knowledge Layer?

Eine Knowledge Layer ist eine gemeinsam verwaltete Wissensschicht zwischen Unternehmensdaten und den Anwendungen oder Agenten, die diese Daten nutzen. Sie verbindet fachliche Begriffe, Beziehungen, Regeln, Datenquellen und – sofern vorgesehen – Erfahrungswissen.

2. Worin unterscheidet sie sich von einer RAG-Lösung?

RAG ruft in erster Linie relevante Inhalte für eine Anfrage ab. Eine Knowledge Layer geht darüber hinaus: Sie beschreibt formale Bedeutungen, Beziehungen und Regeln, kann mehrere Retrieval-Verfahren einbinden und stellt Agenten kontrollierten Kontext bereit. OWASP weist zugleich darauf hin, dass RAG neue Angriffsflächen entlang der gesamten Datenpipeline schafft [2].

3. Welche Rolle spielen Ontologien?

Ontologien definieren Klassen, Eigenschaften, Instanzen und Beziehungen mit formal festgelegter Bedeutung. Der W3C-Standard OWL 2 bietet dafür eine etablierte technische Grundlage und kann auch Konsistenzprüfungen sowie maschinelle Schlussfolgerungen unterstützen [3].

4. Braucht jedes Unternehmen einen Knowledge Graph?

Nicht zwingend. Für überschaubare Domänen können ein kontrolliertes Glossar, Metadaten, Richtlinien und klar geregelte Datenzugriffe genügen. Ein Knowledge Graph wird besonders nützlich, wenn viele Beziehungen, Quellen und domänenübergreifende Abhängigkeiten abgefragt werden müssen.

5. Wie lässt sich die Qualität der Wissensschicht messen?

Geeignete Kennzahlen sind unter anderem Quellenabdeckung, Aktualität, Widerspruchsquote, Antworttreue, korrekte Berechtigungsdurchsetzung, Latenz und Kosten pro Aufgabe. Für das übergreifende Risikomanagement strukturiert das NIST AI RMF die Arbeit in die Funktionen Govern, Map, Measure und Manage [4].

6. Wer sollte die Knowledge Layer verantworten?

Die Plattformverantwortung liegt typischerweise bei Daten- oder Plattformteams. Fachbereiche sollten Definitionen, Regeln und maßgebliche Quellen besitzen. Ein übergreifendes Governance-Gremium koordiniert Standards, Zugriffe, Qualitätsziele und Eskalationswege.

7. Wie wird die Knowledge Layer abgesichert?

Erforderlich sind Herkunfts- und Integritätsprüfung, Berechtigungsmetadaten pro Wissenseinheit, Trennung von Mandanten und Schutzklassen, abgesicherte Indizes, Protokollierung sowie Ausgabe- und Tool-Kontrollen. Die OWASP-Empfehlungen für RAG nennen diese Maßnahmen als zentrale Kontrollen für produktive Pipelines [2].

8. Welche Daten gehören in die Memory-Komponente?

Gespeichert werden sollten nur geprüfte, zweckgebundene Entscheidungsspuren und wiederverwendbare Erfahrungen. Rohdialoge, personenbezogene Daten oder ungeprüfte Agentenannahmen benötigen klare Speicher-, Lösch- und Freigaberegeln.

9. Wie startet ein Unternehmen pragmatisch?

Geeignet ist ein begrenzter Prozess mit bekannten Datenquellen, klaren Regeln und messbarem Nutzen. Das Team modelliert zunächst die wichtigsten Begriffe und Beziehungen, bindet zwei oder drei maßgebliche Quellen an und testet den Zugriff mit realen Aufgaben, bevor weitere Domänen folgen.

10. Senkt eine Knowledge Layer automatisch die KI-Kosten?

Nein. Einsparungen hängen von Architektur, Abfrageverhalten, Caching, Retrieval-Qualität und Betriebsmodell ab. Anthropic berichtet für sein Research-System, dass agentische und insbesondere Multi-Agenten-Abläufe deutlich mehr Tokens als einfache Chat-Interaktionen benötigen; deshalb sollten Kontextumfang und Orchestrierung gemessen werden [1].

 

[1] https://www.anthropic.com/engineering/multi-agent-research-system

[2] https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html

[3] https://www.w3.org/TR/owl2-overview/

[4] https://www.nist.gov/itl/ai-risk-management-framework

Management Summary, FAQ und Bild wurden mit Hilfe von KI erstellt

 

Artikelserie:

#1 Knowledge Layer: Warum Unternehmen ihr Wissen neu organisieren müssen

#2 Context Graph: Warum KI-Agenten frühere Entscheidungen kennen müssen

#3 Agent Memory: Warum KI drei »Gedächtnisse« braucht

#4 Thin Agents: Warum schlanke KI-Agenten besser skalieren

 

Effizienz von KI-Agenten: Vier Architekturstrategien gegen unnötigen Tokenverbrauch

20. August 2026