Federated Context Platform für KI-Agenten im Unternehmen
Für Architekt:innen, die Agenten in ein großes Unternehmen bringen: wie Kontextschichten dem Organigramm folgen, was Gateway und Katalog leisten und wo ihr mit dem Lesen anfangt.
Verfasst von
-
Stefan Munz Gründer & Co-CEO
Aktualisiert:
Agentic Engineering 5
Unsere Position. Für uns steht fest: Eine einzige große Kontextdatei skaliert nicht (öffnet in einem neuen Tab). Kontext gehört föderiert, in Schichten, die das Organigramm abbilden. Jede Schicht pflegen die Menschen, denen dieses Wissen ohnehin gehört. Widersprechen sich zwei Schichten, kann ein Agent als neutraler Architektur-Mediator vermitteln. Genau das ist Federated Context Governance.
Das Modell überträgt Conway’s Law auf die Agenten und lehnt sich an das Data Mesh an. Wer Daten als Produkt behandelt, gibt jeder Domäne ausdrückliche Ownership und Qualitätspflichten (Deloitte (öffnet in einem neuen Tab)). Ein einzelnes zentrales Team hält mit den Änderungen im ganzen Unternehmen nicht Schritt. Ein monolithischer Kontextspeicher wird so zum Bottleneck (Strategie und Architektur).
Der Kontext selbst liegt in Schichten:
- Plattform-Kontext: gemeinsame Policies und Guardrails
- Domänen-Kontext: Geschäftsregeln und Entscheidungen
- Technischer Kontext: Code und Architektur
- Agenten-Kontext: Aufgabenstand und Memory
Ein LLM-Gateway regelt Modellzugriff, Kosten und Guardrails. Ein Kontextkatalog hält die Metadaten, über die sich jedes Produkt finden lässt. Agenten fragen den Katalog, was es gibt, und holen den Inhalt beim Gateway. Im Idealfall läuft beides über das Model Context Protocol (öffnet in einem neuen Tab) (Die Plattformschicht).
Die Speicherung bleibt polyglott. Wo Präzision zählt, etwa bei einem Fehlercode oder einer Produkt-SKU, schlägt hybride Enterprise Search die reine Vektorsuche. Knowledge Graphs beantworten Multi-Hop-Fragen. Repositories nach Git-Vorbild geben lang laufenden Agenten ein Memory, das sich auditieren und verzweigen lässt (Speicher- und Retrieval-Architekturen). Quellcode wird über AST-Parsing und einen Code-Knowledge-Graph zu Kontext (Context Products entwickeln).
Governance gehört ab dem ersten Release in die Architektur. Zugriffskontrolle filtert die Daten in der Retrieval-Schicht, weil eine Instruktion im Prompt gegen Prompt Injection keine Sicherheitsgrenze bilden kann. Eventgetriebenes Re-Indexing, versionierte Produkte und benannte Maintainer:innen verhindern, dass Kontext veraltet (Governance und Betrieb).
Einstieg
- Strategie und Architektur: Warum Agenten im Unternehmen eine Context Fabric brauchen und wie Context as a Product ihre Architektur prägt.
- Die Plattformschicht: Die Gateway- und Katalog-Services, die föderierten Kontext auffindbar und steuerbar machen.
- Context Products entwickeln: Wie aus rohem Unternehmenswissen und Quellcode wiederverwendbare, KI-taugliche Kontextprodukte werden.
- Speicher- und Retrieval-Architekturen: Wie Vektorsuche, Enterprise Search, Graphen und Git unterschiedliche Kontextbedarfe bedienen.
- Governance und Betrieb: Wie ihr föderierten Kontext auf Dauer zusammenstellt, absichert, aktuell haltet und betreibt.
Verwandte Seiten
- Federated Factory im Enterprise-Maßstab: eine vergleichbare Aufteilung der Ownership, in drei Ebenen, für Software Factories.
- Memory und Context Engineering: Kontextarbeit im Maßstab eines Teams und eines Repositorys.
- Kontext als versioniertes Artefakt: wie Kontext mit klarer Ownership getestet, verteilt und überarbeitet wird wie Code.
- Architektur und Design: die größeren Architekturfragen, die Agenten aufwerfen.
- MCP: Protokoll und Kontextkosten: was es das Fenster eines Agenten kostet, Kontextprodukte über MCP auszuliefern.
Quellen
Dokumentation
- Model Context Protocol (öffnet in einem neuen Tab) - Offizielle Website und Spezifikation des offenen Protokolls, über das Agenten Kontextprodukte an einer gemeinsamen Schnittstelle finden und abrufen.
Studien und Berichte
- Treating data as a product in the era of GenAI (öffnet in einem neuen Tab) - Paper von Deloitte, das Data as a Product auf generative KI überträgt und jeder Domäne ausdrückliche Ownership und Qualitätspflichten gibt.
Posts
- Federated in layers that mirror the org chart (öffnet in einem neuen Tab) - LinkedIn-Post mit dem Argument, Kontext in Schichten nach dem Organigramm zu föderieren, jede gepflegt von denen, denen das Wissen gehört.
In diesem Bereich
- Context Products entwickeln
Wie aus Dokumenten, Gesprächen und Quellcode Context Products werden, Schritt für Schritt von der Ingestion bis zum Code-Wissensgraphen, für Plattform- und Datenteams.
- Governance und Betrieb
Föderierter Kontext bleibt nur sicher und nützlich, wenn ihr ihn nach dem Start steuert. Ein Orchestrator stellt genau den Kontext zusammen, den eine Aufgabe braucht. Die Zugriffskontrolle filtert Daten an der Quelle, statt dem Modell zu vertrauen. Event-getriebenes Re-Indexing, Versionierung und benannte Owner verhindern, dass Kontext veraltet.
- Die Plattformschicht
Die Plattformschicht ist der gemeinsame Teil einer Federated Context Platform: ein LLM-Gateway, das Modellzugriff, Kosten und Guardrails steuert, und ein Context Catalog, der jedes Context Product auffindbar macht. Agenten fragen den Katalog, was es gibt, und das Gateway nach dem Inhalt. So hängen sie nie davon ab, wo er gespeichert ist.
- Speicher- und Retrieval-Architekturen
Kein einzelner Speicher deckt jeden Kontextbedarf. Hybride Enterprise Search findet relevante Dokumente, Knowledge Graphs beantworten Multi-Hop-Fragen über Beziehungen, und Repositories nach Git-Art geben lange laufenden Agenten prüfbares, verzweigbares Memory. Eine reife Plattform leitet jede Anfrage an den passenden Speicher.
- Strategie und Architektur
Agenten im Unternehmen brauchen aktuellen, fachspezifischen Kontext, und ein zentraler Speicher kann ihn in dieser Größenordnung weder verantworten noch aktuell halten. Als Produkt behandelt, veröffentlicht jede Domäne eigenen, auffindbaren Kontext, und eine gemeinsame Plattform liefert Gateway, Katalog und gemeinsame Kontrollen.