Strategie und Architektur

Unsere Position. Kontext gehört für uns föderiert in Schichten, die das Organigramm spiegeln (öffnet in einem neuen Tab). Eine einzige Datei bedeutet einen Owner für Wissen, das viele Owner hat. Und sie veraltet an dem Tag, an dem sie geschrieben wird.

Woraus besteht eine föderierte Kontextplattform?

Die Architektur unterscheidet vier Schichten:

• Plattform-Kontext liefert gemeinsame Policies, Fähigkeiten und Infrastruktur.
• Domänen-Kontext hält Geschäftsbegriffe, Regeln und Entscheidungen fest.
• Technischer Kontext macht Code, Architektur und Laufzeitverhalten lesbar.
• Agenten-Kontext trägt den Aufgabenstand und das operative Gedächtnis eines einzelnen Agenten.

Drei Plattform-Komponenten verbinden diese Schichten. Ein LLM-Gateway regelt den Zugriff auf Modelle und die Policies. Ein Context Catalog macht Context Products auffindbar. Über interoperable Schnittstellen wie MCP rufen Agenten sie ab. Die Speicherung bleibt polyglott, weil jedes Retrieval-Problem eine andere Form hat:

• Enterprise Search findet relevante Dokumente.
• Knowledge Graphs unterstützen Fragen mit vielen Beziehungen und über mehrere Hops.
• Memory-Systeme bewahren eine sich entwickelnde Interaktionshistorie, wo Persistenz nützt.
• Versionierte Dateien liefern prüfbaren Kontext für Engineering und lang laufende Arbeit.

Das Design ruht auf fünf Säulen:

1. Behandelt Kontext als Produkt, mit Owner, Konsument:innen, Qualitätserwartungen und Lebenszyklus.
2. Trennt Plattform-, Domänen-, technischen und Agenten-Kontext, statt einen undifferenzierten Speicher zu bauen.
3. Wählt Suche, Graphen, Memory und Dateien nach dem Retrieval-Problem, statt jedem Anwendungsfall dieselbe Datenbank aufzuzwingen.
4. Föderiert Auffindbarkeit und Policies über gemeinsame Gateway- und Katalog-Services.
5. Stellt mit bewusstem Context Engineering nur den Kontext zusammen, den eine Aufgabe braucht.

Governance gehört zur Architektur. Zugriffskontrolle, Aktualität, Herkunft und Ausmusterung entscheiden, ob der föderierte Kontext nach seinem ersten Release sicher und nützlich bleibt.

Warum scheitert zentraler Kontext im Enterprise-Maßstab?

Die Qualität des Kontexts begrenzt, was ein Agent leisten kann. Im Unternehmen verteilt sich dieser Kontext über Dutzende Systeme. Die Lösung ist erst organisatorisch und dann technisch. Sie beginnt mit benannten Ownern für Kontext, danach folgen das Paradigma “Context as a Product” und eine Architektur in Schichten.

Die Kontext-Herausforderung für KI im Unternehmen

Wie gut Large Language Models (LLMs) und die darauf gebauten KI-Agenten arbeiten, ist direkt proportional zu Qualität und Relevanz ihres Kontexts. In einem komplexen Unternehmensumfeld ist dieser Kontext riesig, verteilt und ständig in Bewegung. Schlecht verwalteter Kontext ist die Hauptursache der üblichen Schwächen von KI.

Problemstellung

Heutige Ansätze behandeln Kontext für KI-Agenten oft als monolithisches Problem der Datenaufnahme. Die so gebauten Systeme sind fragil und schwer zu skalieren. LLMs sind durch den Stichtag ihrer Trainingsdaten und durch endliche Kontextfenster begrenzt. Fehlt ihnen ausreichendes externes Wissen, halluzinieren sie häufig oder liefern syntaktisch gültige, aber logisch falsche Antworten (Enhancing LLM Code Generation with RAG and AST-Based Chunking (öffnet in einem neuen Tab)).

Im Unternehmen verschärft sich das, weil der Kontext über Dutzende Systeme zersplittert ist. Quellcode liegt in Git-Repositories, Dokumentation in Confluence und Anforderungen in Jira. Gespräche laufen in Team-Chats, und Geschäftslogik steckt in Legacy-Anwendungen.

Grenzen der Skalierung

Eine Organisation skaliert ihre KI-Initiativen, setzt mehr Agenten in mehr Teams ein und bindet mehr Datenquellen an. Dann wird eine zentrale Kontextarchitektur zum unhaltbaren Bottleneck. Ein einzelnes Team, das alle Kontextquellen verwaltet, hält mit dem Änderungstempo im Unternehmen nicht Schritt. Das zentrale Modell wiederholt die Probleme monolithischer Data Warehouses, die sich mit Agilität und fachspezifischer Expertise schwertun.

Eine föderierte Architektur erlaubt dezentrales Management und Zusammenarbeit zwischen unabhängigen Komponenten. Für Skalierbarkeit und Fehlertoleranz ist sie entscheidend (GeeksforGeeks - Federated Architecture - System Design (öffnet in einem neuen Tab)). Ohne ein solches Modell wird die Kontextplattform selbst zum Single Point of Failure. Sie bremst dann Innovation, statt sie zu ermöglichen.

Was schlechter Kontext kostet

Eine unzureichende Kontextstrategie hat Folgen über die Technik hinaus, mit direkten und erheblichen Auswirkungen auf das Geschäft. Analyst:innen und Entwickler:innen verbringen einen großen Teil ihrer Zeit, in manchen Fällen bis zu 70 %, mit “data wrangling”, um Daten nutzbar zu machen. Derselbe Aufwand spiegelt sich direkt darin, Kontext für KI-Agenten aufzubereiten (Deloitte - Treating data as a product in the era of GenAI (öffnet in einem neuen Tab)).

Ungenaue oder veraltete Antworten von KI-Agenten untergraben das Vertrauen der Nutzer:innen. Die Akzeptanz sinkt, und der Business Case für KI-Investitionen wackelt. Ein schlecht gesteuertes Kontextsystem ist außerdem ein ernstes Sicherheitsrisiko. Ohne robuste Kontrollen greifen Agenten womöglich versehentlich auf sensible oder personenbezogene Daten (PII) zu und legen sie offen. Die Folgen sind Compliance-Verstöße und Reputationsschäden (LaunchDarkly - AI application development best practices: From prototype to production (öffnet in einem neuen Tab)).

Ein neues Paradigma: “Context as a Product”

Skalierung, Qualität und Governance verlangen einen grundlegenden Perspektivwechsel. Kontext gilt dann nicht mehr als rohes Nebenprodukt des Geschäftsbetriebs, sondern als vollwertiges Produkt. Das Paradigma “Context as a Product” lehnt sich stark an die Prinzipien von Data Mesh an. Es legt das organisatorische und architektonische Fundament für ein skalierbares föderiertes System (Deloitte - Treating data as a product in the era of GenAI (öffnet in einem neuen Tab)).

Der Wandel ist vor allem organisatorisch und kulturell. Er gelingt, wenn Ownership klar geregelt ist und interne Konsument:innen von Daten, KI-Agenten eingeschlossen, als geschätzte Kund:innen gelten. Der erste Schritt ist organisatorisch, nicht technisch: Wichtige Domänen bekommen “Context Product Owners”.

Grundprinzipien

In diesem Paradigma wird jede Kontexteinheit als Produkt verwaltet und ausgeliefert, mit definiertem Lebenszyklus und Qualitätsstandards. Ein Context Product muss sein:

• Auffindbar: im zentralen, durchsuchbaren Context Catalog registriert und dokumentiert.
• Adressierbar: über eine stabile, klar definierte Schnittstelle oder API erreichbar.
• Vertrauenswürdig: mit Metadaten zu Quelle, Lineage, Qualitätsmetriken und Ownership versehen. So können sich Nutzer:innen und Agenten auf seine Genauigkeit verlassen.
• Sicher: durch explizite Policies zur Zugriffskontrolle geregelt.
• Interoperabel: an ein standardisiertes Metadatenschema gebunden, damit verschiedene Agenten und Systeme es leicht integrieren.
• Aus sich heraus wertvoll: direkt nützlich für bestimmte Anwendungsfälle wie Codegenerierung, Geschäftsanalyse oder Kundensupport.

Föderierte Ownership

Ein Kernsatz dieses Modells ist dezentrale, an Domänen ausgerichtete Ownership. Das Team, das eine Datenquelle erzeugt und versteht, verantwortet das zugehörige Context Product am besten. So gehört der “Codebase Dependency Graph” dem Engineering-Team und die “Feature Requirements” aus Jira dem Produktteam. Die “Contract Clause Library” gehört dem Rechtsteam.

Diese föderierte Ownership spiegelt den Aufbau erfolgreicher dezentraler Organisationen und verteilter Rechnerarchitekturen. Sie bündelt Verantwortung dort, wo die Expertise sitzt, und sichert die Qualität des Kontexts an der Quelle (GeeksforGeeks - Federated Architecture - System Design (öffnet in einem neuen Tab)).

Arten von Context Products

Context Products lassen sich danach einteilen, wie stark sie transformiert und wie bereit sie für KI sind. Daraus ergibt sich eine klare Wertschöpfungskette von Rohdaten bis zu handlungsrelevantem Wissen:

• Raw Context Products: Daten im Originalformat des Quellsystems, nur minimal bereinigt. Ein Beispiel ist ein roher JSON-Dump einer API-Spezifikation.
• Conformed Context Products: bereinigte, standardisierte Daten, angereichert mit einheitlichen Metadaten. Ein Beispiel sind Confluence-Seiten, die geparst, in Chunks zerlegt und mit standardisierten Schlagwörtern getaggt wurden.
• AI-Ready Context Products: stark kuratierte, strukturierte Daten, gezielt für LLMs gebaut. Dazu gehören vektorisierte Dokumente für RAG, strukturierte Knowledge Graphs für komplexe Abfragen oder Datensätze für Fine-Tuning.

Architektur-Blaupause: ein mehrschichtiges Modell für föderierten Kontext

Eine mehrschichtige Architektur setzt das Paradigma “Context as a Product” um und ordnet Kontext nach Art und Zweck. Das Modell trennt Zuständigkeiten klar und legt eine Hierarchie der Abhängigkeiten fest. Sie leitet, wie Agenten Informationen zusammenstellen und nutzen.

Die Schichten liegen nicht bloß übereinander, sie bilden einen Abhängigkeitsgraphen. Der Aufgabenkontext eines Agenten stützt sich auf den technischen Kontext seiner Umgebung. Dieser muss wiederum die übergeordneten Vorgaben von Domäne und Plattform einhalten. Eine wirksame Orchestrierungs-Engine muss diesen Graphen auflösen, damit übergeordnete Vorgaben wie Security-Policies immer gelten.

Die Schichten

Die Architektur besteht aus vier getrennten Schichten. Jede liefert eine andere Facette des gesamten Kontexts, den ein KI-Agent braucht.

Dieses Schichtenmodell gibt einen strukturierten Rahmen, um Kontext im ganzen Unternehmen zu ordnen, zu verantworten und auszuliefern. Es bildet die Blaupause für die föderierte Plattform.

---

Verwandte Seiten

• Die Plattformschicht: Gateway und Katalog, die die vier Schichten verbinden.
• Context Products entwickeln: wie eine Domäne ihre Quellen in ein Produkt verwandelt.
• Speicher- und Retrieval-Architekturen: welcher Speicher welches Retrieval-Problem bedient.
• Governance und Betrieb: wie Zugriff, Aktualität und Ownership nach dem Launch halten.
• Federated Factory im Enterprise-Maßstab: dieselbe Idee der Föderation, angewandt auf Software Factories.

Quellen

Artikel

• AI application development best practices: From prototype to production (öffnet in einem neuen Tab) - Blogpost von LaunchDarkly darüber, wie KI-Anwendungen in Produktion gehen, samt Kontrollen, die Agenten am Offenlegen sensibler Daten hindern.
• Enhancing LLM Code Generation with RAG and AST-Based Chunking (öffnet in einem neuen Tab) - Blogpost darüber, warum Modelle ohne ausreichenden externen Kontext Code halluzinieren und wie AST-basiertes Retrieval ihn liefert.
• Federated Architecture - System Design (öffnet in einem neuen Tab) - Erklärartikel von GeeksforGeeks zu föderierter Architektur als dezentralem Management unabhängiger Komponenten, der Antwort auf zentrale Bottlenecks beim Skalieren.

Papers und Berichte

• Treating data as a product in the era of GenAI (öffnet in einem neuen Tab) - Paper von Deloitte über Daten als Produkt für generative KI, das Data-Mesh-Modell hinter Context as a Product.

Posts

• Föderiert in Schichten, die das Organigramm spiegeln (öffnet in einem neuen Tab) - LinkedIn-Post mit dem Argument, dass eine einzige Kontextdatei einen Owner für Wissen mit vielen Ownern bedeutet und am Tag ihres Entstehens veraltet.