Zum Inhalt springen

Wissensbasis

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.

Verfasst von

Aktualisiert:

Agentic Engineering 5

Unsere Position. Was nie passieren darf, verhindert ihr aus unserer Sicht, indem ihr begrenzt, was der Agent überhaupt erreichen kann (öffnet in einem neuen Tab). Zu filtern, was er anfragt, reicht nicht. Kontext hat Owner wie Code: Er wird reviewt, versioniert und gegen das tatsächliche Verhalten der Agenten getestet (öffnet in einem neuen Tab), weil er driftet.

Wie stellt ihr Kontext im Betrieb zusammen, sichert ihn ab und haltet ihn aktuell?

Zusammen bilden die Komponenten der Plattform eine kognitive Architektur. Das ist ein Rahmen dafür, wie das System Informationen verarbeitet, speichert und abruft, ähnlich wie menschliche Kognition (Cognee - Cognitive Architectures for AI Agents (CoALA): Explained (öffnet in einem neuen Tab)). Sie zu betreiben heißt: Kontext pro Aufgabe zusammenstellen, den Zugriff absichern und den Kontext über seinen Lebenszyklus aktuell halten.

Dynamische Kontext-Zusammenstellung: Orchestrierungsmuster für KI-Agenten

Steht ein reiches Ökosystem an Context Products bereit, ist die Aufgabe des Agenten kein einfacher Abruf mehr, sondern dynamische Orchestrierung. Context Engineering ist die Disziplin, für eine bestimmte Aufgabe den richtigen Kontext klug auszuwählen, zu filtern, zu komprimieren und zu strukturieren, bevor er an ein LLM geht (Context Engineering in LLM-Based Agents (öffnet in einem neuen Tab)). Diesen Prozess steuert eine Orchestrierungsschicht. Sie kann Teil der Logik des Agenten sein oder ein eigener vermittelnder Dienst.

Den Ablauf der Orchestrierung könnt ihr euch als ECL-Pipeline (Extract, Cognify, Load) vorstellen, ein Muster, mit dem ihr dynamisches Memory für Agenten baut:

  1. Extract (Intent-Analyse und föderierter Abruf): Zuerst analysiert der Orchestrator den Prompt der Nutzer:innen, um die Absicht zu verstehen und die nötigen Kontextarten zu bestimmen. Ein Prompt wie “Refactor the UserService to use our new logging library and ensure it meets our performance standards” braucht zum Beispiel mehrere Kontextarten: technischen Kontext (den Quellcode von UserService, die API der neuen Logging-Bibliothek) und Domänenkontext (die Dokumentation der Performance-Standards). Danach fragt er den Context Catalog ab, um die passenden contextProductIDs zu finden. Zuletzt stellt er parallele Anfragen, idealerweise über ein standardisiertes Protokoll wie MCP. So holt er die Daten jedes gefundenen Context Products aus den passenden Backend-Systemen.
  2. Cognify (Prompt-Synthese): Die abgerufenen Kontextteile werden zu einem finalen Prompt zusammengesetzt. Dieser kritische Schritt ist mehr als einfaches Aneinanderhängen. Der Orchestrator muss die gesamte Token-Zahl steuern, damit alles ins Kontextfenster des LLM passt. Dafür fasst er etwa weniger wichtige Informationen zusammen oder komprimiert redundanten Text (Reddit - 6 Techniques You Should Know to Manage Context Lengths in LLM Apps (öffnet in einem neuen Tab)). Klare Überschriften strukturieren die Informationen, damit das LLM die Kontextquellen auseinanderhält (zum Beispiel “Source Code:”, “Relevant Documentation:”, “API Specification:”).
  3. Load (Interaktion mit dem LLM): Der finale, kontextreiche Prompt geht zur Verarbeitung an das LLM.

Fortgeschrittene Orchestrierungsmuster

Für anspruchsvollere Anwendungsfälle lassen sich ausgefeiltere Orchestrierungsmuster einsetzen:

  • Schwierigkeitsabhängige Orchestrierung: Einfache Routineanfragen können eine Standard-RAG-Pipeline auslösen. Schätzt der Orchestrator eine Anfrage aber als sehr komplex ein, kann er dynamisch einen ausgefeilteren Ablauf zusammenstellen. Er startet dann etwa eine Debatte mehrerer Agenten oder eine tiefe GraphRAG-Abfrage über mehrere Hops, um umfassenderen Kontext zu sammeln (arXiv - Difficulty-Aware Agent Orchestration in LLM-Powered Workflows (öffnet in einem neuen Tab)).
  • Multi-Agent-Workflows: Für kreative und komplexe Aufgaben, etwa eine neue Softwarekomponente zu erzeugen, reicht ein einzelner Agent womöglich nicht. Frameworks wie Archon zeigen einen Multi-Agent-Ansatz, in dem verschiedene Agenten zusammenarbeiten (Decentralised-AI - Archon - AI Agent Builder (öffnet in einem neuen Tab)). Ein “Planner”-Agent skizziert zuerst die Aufgabe. Ein “Coder”-Agent schreibt mit dem verfügbaren technischen Kontext die erste Implementierung. Ein oder mehrere “Refiner”-Agenten verbessern den Code dann schrittweise anhand von Feedback und Tests. Diese Trennung der Zuständigkeiten spiegelt ein menschliches Entwicklungsteam und kann deutlich robustere Ergebnisse liefern.

Die Fabric absichern: föderierte Zugriffskontrolle

In jedem Unternehmenssystem hat Sicherheit oberste Priorität. Verlasst ihr euch darauf, dass ein LLM Instruktionen befolgt, um Zugriffskontrolle durchzusetzen (etwa “Do not reveal financial data”), ist das grundsätzlich unsicher. LLMs sind anfällig für Prompt-Injection-Angriffe (LaunchDarkly - AI application development best practices: From prototype to production (öffnet in einem neuen Tab)). Ein robustes Sicherheitsmodell setzt die Zugriffskontrolle auf der Datenschicht durch. So sieht das LLM nie Informationen, für die die Nutzer:in keine Berechtigung hat.

Diese nötige Sicherheitsgarantie liefert ein Modell für Role-Based Access Control (RBAC), das in der RAG-Pipeline umgesetzt ist (Ping Identity - Understanding RBAC, PBAC, and ABAC: Access Control Explained (öffnet in einem neuen Tab)). Föderierter Abruf kann auch richtlinienbasierte Kontrollen an der Quelle durchsetzen (MIT (öffnet in einem neuen Tab)). Die Umsetzung sieht so aus:

  1. Authentifizierung und Rollenerkennung: Arbeitet eine Nutzer:in mit einem Agenten, wird ihre Anfrage an das LLM Gateway authentifiziert. Das Gateway ist an das Identity and Access Management (IAM) des Unternehmens angebunden und erkennt die Rolle oder Rollen der Person (zum Beispiel Engineer, Sales, Admin).
  2. Kontextbewusster Abruf: Jede Abrufanfrage für Kontext enthält die Rolleninformation der Nutzer:in.
  3. Filtern an der Quelle: Die darunterliegenden Abrufsysteme sind dafür zuständig, die Zugriffskontrolle durchzusetzen. Gefiltert wird über die Metadaten accessControlTags, die an jedem Context Product und seinen Daten-Chunks gespeichert sind. Fragt etwa eine Nutzer:in mit der Rolle Sales nach “Q4 performance”, hängt die Suchmaschine automatisch den Filter AND (role:sales OR role:public) an ihre Abfrage. So kommen Performance-Kennzahlen, die nur für Engineering bestimmt sind, nie zurück (Building a Role-Based RAG System: Implementing Secure Document Access with Retrieval-Augmented Generation (öffnet in einem neuen Tab)).

In dieser Architektur setzen deterministische Filterregeln in den Datenspeichern die Sicherheit durch, nicht das probabilistische Verhalten eines LLM. Die Metadaten zur Zugriffskontrolle im Context Catalog werden damit zu einem Grundpfeiler des Sicherheits- und Governance-Modells der Plattform.

Den Lebenszyklus steuern: veralteter und sich wandelnder Kontext

Eine Kontextplattform ist kein statischer Data Lake, sondern ein lebendes Ökosystem. Ihre Informationen ändern sich ständig: Code wird committet, Dokumente werden aktualisiert, Geschäftsprozesse entwickeln sich weiter. Entscheidend ist, diesen Lebenszyklus zu steuern, damit der Kontext nicht veraltet. Sonst geben Agenten auf Basis alter Informationen veraltete oder falsche Antworten (Scalable RAG Architectures: How Context Length, Model Choice, and Business Needs Drive Latency (öffnet in einem neuen Tab)).

Kontext bleibt mit diesen Strategien aktuell:

  • Event-getriebene Ingestion: Am wirksamsten sind event-getriebene Pipelines. Webhooks aus Quellsystemen, etwa ein Git-Post-Commit-Hook oder ein Update-Event einer Confluence-Seite, können die Re-Indexing-Pipeline automatisch auslösen, und zwar für genau das Context Product, das sich geändert hat. So kommen Updates mit geringer Latenz an.
  • Geplantes Re-Indexing: Für Systeme ohne Webhooks sichern periodisches Polling und Re-Indexing (zum Beispiel nächtlich) ein Grundmaß an Aktualität.
  • Versionierung und Caching: Alle Context Products im Katalog sollten versioniert sein. Das ermöglicht stabiles, reproduzierbares Verhalten der Agenten. Das LLM Gateway kann eine Caching-Schicht umsetzen. Anhand der Aktualitäts-Metadaten aus dem Katalog (zum Beispiel TTL) entscheidet sie, wie lange ein Stück Kontext im Cache bleibt. So wägt sie Performance gegen den Bedarf an den neuesten Informationen ab.

Die Gründerin von Atlan teilt Unternehmenskontext in Geschäftsfakten, prozedurales Know-how und Entscheidungsnormen. In ihrem Praxisbericht als Anbieterin trugen isolierte Task-Agenten getrennte Memories, drifteten auseinander und sperrten Kontext im jeweiligen Agenten-Framework ein. Als Ersatz beschreibt sie ein gemeinsames Repository, in dem Domain-Owner wiederverwendbare Skills für Allzweck-Agenten pflegen. Damit kommt zu den Aktualitätsmechanismen oben eine Grenze der Ownership: Lokale Teams bearbeiten Kontext, und gemeinsame Profile halten für jeden Skill Abhängigkeiten, Maintainer:in, Freigebende und Mitwirkende fest. Eine Kontextänderung kann nachgelagerte Skills brechen. Deshalb brauchen Abhängigkeitskanten dieselben Review- und Versionskontrollen wie Code (WTF Is the Context Layer? (öffnet in einem neuen Tab), Juli 2026, Anbieter).

Agent-Traces liefern ein zweites Signal für Aktualität. Ein spezialisierter Harness rekonstruiert mögliche Kontextänderungen und schickt jede einer Maintainer:in zur Freigabe oder Ablehnung. So werden Fehler im Betrieb und Randfälle zu gesteuerten Updates statt zu privatem Agenten-Memory. Für ein erstes Company Brain empfiehlt der Talk, zuerst die Beziehungen über die Geschäftssysteme hinweg zu rekonstruieren. Erst danach kommt der Abruf über MCP, SQL, Vektoren oder hybride Zusammenstellung dazu. Das sind Aussagen von Atlan aus der Praxis, keine kontrollierten Belege für Ergebnisse (WTF Is the Context Layer? (öffnet in einem neuen Tab), Juli 2026, Anbieter).

Zuletzt muss die Architektur den Einsatz von RAG klug gegen die Fähigkeiten neuer Long-Context-LLMs abwägen. Beide Ansätze schließen sich nicht aus, der Orchestrator nutzt sie als einander ergänzende Tools. RAG glänzt, wo Wissen sehr dynamisch ist und sich oft ändert, weil es zum Zeitpunkt der Abfrage die neuesten Informationen holt. Long-Context-Modelle passen besser, wo Wissen eher statisch und grundlegend ist (zum Beispiel ein großes technisches Handbuch oder eine Sammlung von Unternehmensrichtlinien). Dann lässt sich der gesamte Korpus vorab ins Kontextfenster laden, und die Latenz des Abrufs entfällt (Scalable RAG Architectures: How Context Length, Model Choice, and Business Needs Drive Latency (öffnet in einem neuen Tab)). Ein ausgefeilter Orchestrator kann die beste Strategie dynamisch wählen, je nachdem, wie aktuell das angefragte Context Product sein muss.

Fazit und strategische Roadmap

Eine Organisation, die das Paradigma “Context as a Product” übernimmt, kann ein skalierbares, steuerbares und sehr leistungsfähiges KI-Ökosystem bauen. Dazu setzt sie eine mehrschichtige kognitive Architektur um, getragen von einem zentralen LLM Gateway, einem Context Catalog und standardisierten Protokollen wie MCP. Der empfohlene polyglotte Ansatz für die Kontextspeicherung nutzt Enterprise Search, Knowledge Graphs und fortgeschrittene Memory-Plattformen. So haben Agenten für jede Aufgabe Zugriff auf das richtige Tool. Das eigentliche Ziel dieser Architektur ist ein “cognitive context layer”. Dieses intelligente System versteht die Absicht der Nutzer:innen selbstständig, findet den nötigen Kontext auf einem föderierten Marktplatz und ruft ihn ab. Daraus synthetisiert es einen stimmigen, sicheren und genauen Input für ein LLM.

Wir empfehlen eine Umsetzung in Phasen, um die Komplexität zu beherrschen und den Nutzen schrittweise zu liefern.

Phase 1: Fundament

  • Ziel: Die Kernplattform aufbauen und ersten Nutzen zeigen.
  • Zentrale Aktivitäten:
    • Ein LLM Gateway deployen (zum Beispiel mit LiteLLM), mit grundlegender Observability und Kostenverfolgung.
    • Die erste Version des Context-Catalog-Dienstes mit dem festgelegten Metadaten-Schema und der API entwickeln.
    • Die erste Ingestion-Pipeline für eine Quelle mit hohem Wert und geringer Komplexität bauen, etwa die Confluence-Dokumentation.
    • Ein Pilotteam mit einem einfachen RAG-basierten Agenten an Bord holen, um die Plattform zu validieren.

Phase 2: Skalieren und föderieren

  • Ziel: Das Ökosystem ausbauen und Domänenteams befähigen, beizutragen.
  • Zentrale Aktivitäten:
    • Die Rolle “Context Product Owner” in der Organisation formal verankern und Schulungen anbieten.
    • SDKs und CI/CD-Templates entwickeln, mit denen andere Teams leicht eigene Context Products erstellen und veröffentlichen. Für den Zugriff lässt sich dabei womöglich auf MCP standardisieren.
    • Die fortgeschrittene Pipeline für Code-Kontext umsetzen, einschließlich AST-Parsing und dem Aufbau eines Code Knowledge Graph.
    • Das RBAC-Sicherheitsmodell an das IAM-System des Unternehmens anbinden.
    • Mehrere neue fachliche und technische Domänen auf die Plattform holen.

Phase 3: Agentische Automatisierung

  • Ziel: Fortgeschrittene, autonome agentische Workflows ermöglichen.
  • Zentrale Aktivitäten:
    • Die ausgefeilte Orchestrierungslogik entwickeln, mit der Agenten Kontext aus mehreren Products dynamisch finden und kombinieren.
    • Fortgeschrittene Abrufmuster wie GraphRAG umsetzen und für Konversations-Agenten eine eigene Langzeit-Memory-Plattform wie Zep integrieren.
    • Das Muster Git-Context-Controller (GCC) für Agenten einführen, die lang laufende Coding-Aufgaben in mehreren Schritten erledigen.
    • Meta-Agenten (Agenteers) ermöglichen: Die Entwicklung von Agenten unterstützen, die nach dem Vorbild von Frameworks wie Archon mit den Context Products der Plattform selbstständig neue Agenten bauen (Decentralised-AI - Archon - AI Agent Builder (öffnet in einem neuen Tab)).
    • Schwierigkeitsabhängiges Routing und hybride Strategien aus RAG und Long Context erkunden, um Performance und Kosten im großen Maßstab zu optimieren.

Anhang: Checkliste der Kontext-Artefakte

Ein Arbeitsinventar der Artefakte, die die Schichten oben speisen, gruppiert nach Domäne.

Verwandte Seiten

Quellen

Kontext im Betrieb