Zum Inhalt springen

Wissensbasis

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.

Verfasst von

Aktualisiert:

Agentic Engineering 5

Unsere Position. Für uns ist ein Agent eine neue Art von Plattformnutzer (öffnet in einem neuen Tab). Funktionieren Delivery-Pfade nur mit einem Senior Engineer im Loop, erbt der Agent jeden Bottleneck und stößt schneller darauf. Die Plattform muss zum Self-Service werden und als Produkt geführt werden (öffnet in einem neuen Tab). Freigaben werden dabei zu Regeln.

Diese zentralen Dienste besitzen selbst keinen Kontext. Die Domänenteams besitzen ihre Context Products.

Welche gemeinsamen Dienste bringen föderierten Kontext zum Laufen?

Das zentrale Nervensystem: das LLM-Gateway als Orchestrator

Das LLM-Gateway ist der einzige, verpflichtende Einstiegspunkt für alle Interaktionen zwischen KI-Agenten und den darunterliegenden LLMs. Vor allem entkoppelt es die Agenten von der komplexen LLM-Landschaft. Zugleich setzt es plattformweite Governance durch und liefert entscheidende Einblicke in den Betrieb. Tools wie LiteLLM bieten eine robuste Grundlage für ein solches Gateway und bringen viele nötige Funktionen out of the box mit (LiteLLM (öffnet in einem neuen Tab)). Wichtig ist aber: Ein solches Tool ermöglicht viel, ist aber nicht die ganze Plattform. Es muss mit anderen, selbst gebauten Diensten wie dem Context Catalog zusammenspielen.

Kernfunktionen

Ein LLM-Gateway für den Produktivbetrieb muss die folgenden Fähigkeiten mitbringen:

  • Einheitliche API: Entwickler:innen und Agenten bekommen eine standardisierte, OpenAI-kompatible API. Sie abstrahiert die unterschiedlichen APIs von mehr als 140 LLM-Anbietern, nach LiteLLMs eigener Zählung im Oktober 2026. Das vereinfacht die Entwicklung, und das Plattformteam kann Modelle tauschen oder neue hinzufügen, ohne nachgelagerte Anwendungen zu beeinträchtigen (LiteLLM (öffnet in einem neuen Tab)).
  • Observability und Kostenmanagement: Das Gateway ist der ideale Ort für umfassendes Logging. Es erfasst jede Anfrage und jede Antwort und liefert detaillierte Metriken zu Latenz, Token-Zahlen und Fehlerraten. Diese Daten sind unverzichtbar für das Performance-Monitoring und erlauben genaues Kosten-Tracking. So lassen sich Ausgaben einzelnen Nutzer:innen, Teams oder Projekten zuordnen und weiterverrechnen (LiteLLM (öffnet in einem neuen Tab)).
  • Security-Guardrails: Als zentraler Kontrollpunkt setzt das Gateway nicht verhandelbare Sicherheitsrichtlinien durch, bevor Daten an ein externes LLM gehen. Dazu gehört, Secrets zu erkennen und zu schwärzen, nach PII zu scannen und Filter zur Content-Moderation anzuwenden. Mit diesen Guardrails setzt das Gateway die Guardrails der Plattform an entscheidender Stelle um (LiteLLM (öffnet in einem neuen Tab)).
  • Intelligentes Routing und Load Balancing: Das Gateway kann Anfragen anhand von Regeln dynamisch an das passendste Modell leiten. Komplexe Reasoning-Aufgaben gingen dann etwa an ein starkes Modell wie GPT-4o, einfachere Zusammenfassungen an ein günstigeres Modell. Diese Strategie optimiert auf der ganzen Plattform Performance und Kosten zugleich (LiteLLM - Getting Started (öffnet in einem neuen Tab)).
  • Authentifizierung und Autorisierung: Das Gateway verwaltet virtuelle API-Keys für Nutzer:innen, Agenten und Teams. Über diese Keys setzt es Zugriffskontrollen, Rate Limits (z. B. Anfragen pro Minute) und harte Budgetobergrenzen durch. Das verhindert ausufernde Kosten und Missbrauch des Systems (LiteLLM (öffnet in einem neuen Tab)).

Der Marktplatz: den Context Catalog entwerfen

Ist das LLM-Gateway das Nervensystem, dann ist der Context Catalog die Gedächtniskarte des Gehirns. In dieser zentralen Registry werden alle “Context as a Product”-Angebote veröffentlicht, dokumentiert und auffindbar gemacht. Die Kontextdaten selbst speichert der Katalog nicht. Er hält die Metadaten, die sie beschreiben und auf ihre maßgebliche Quelle verweisen (Data.world - About the AI Context Engine - Documentation (öffnet in einem neuen Tab)). Dieser “catalog of catalogs” ist der Dreh- und Angelpunkt des föderierten Modells. Er macht aus einer Sammlung verstreuter Datenquellen einen durchsuchbaren, verständlichen Marktplatz KI-fähiger Assets (DEV Community - Catalogs as Context: How Metadata is Powering the Next Wave of AI (öffnet in einem neuen Tab)).

Katalog und Gateway bilden zusammen eine starke Abstraktionsschicht. Die Agenten sind von den darunterliegenden Kontextquellen entkoppelt. Sie müssen nicht mehr wissen, ob der Kontext in einer Vektordatenbank, einem Graphen oder einer einfachen Datei liegt. Der Workflow eines Agenten sieht dann so aus: 1) Er fragt den Katalog nach der contextProductID für die benötigte Information, und 2) er fordert diesen Kontext beim Gateway an. Das Gateway holt ihn anhand der Metadaten im Katalog aus der richtigen Quelle. So können Context Producer weiterentwickeln, wie sie ihren Kontext speichern und abrufen, ohne dass die Agenten brechen, die ihre Produkte nutzen. Das ist ein Grundprinzip skalierbarer, verteilter Architektur.

Vorgeschlagenes Metadatenschema

Damit der Context Catalog wirkt, muss jeder Eintrag einem reichhaltigen, standardisierten Metadatenschema folgen. Das folgende Schema ist ein umfassender Ausgangspunkt:

  • contextProductID: Eine eindeutige, unveränderliche Kennung des Produkts (z. B. urn:context:engineering:code-style-guide).
  • productName: Ein für Menschen lesbarer Name (z. B. “Frontend Code Style Guide”).
  • description: Eine klare, knappe Zusammenfassung des Kontexts, den das Produkt liefert.
  • ownerTeam: Der Name des Teams, das für Qualität und Verfügbarkeit des Produkts verantwortlich ist.
  • sourceSystem: Der Typ des maßgeblichen Quellsystems (z. B. Confluence, Git, Neo4j, Elasticsearch).
  • accessAPI: Der Endpunkt, das Query-Template oder die Methode, über die sich die Kontextdaten abrufen lassen (z. B. https://confluence.mycorp.com/rest/api/content/{pageId} (öffnet in einem neuen Tab)).
  • dataFormat: Das Format der zurückgegebenen Daten (z. B. text/plain, application/json, text/cypher).
  • version: Die semantische Version des Context Products (z. B. 2.1.0). Sie erlaubt Änderungen, die nichts brechen.
  • freshness: Metadaten zur Aktualität der Daten, etwa die Update-Frequenz (z. B. täglich) oder eine Time-to-live (TTL) in Sekunden.
  • accessControlTags: Eine Liste von Key-Value-Paaren für Governance und Sicherheitsfilter (z. B. {“role”: “engineering”, “confidentiality”: “internal”}).

API-Design

Der Katalog muss eine einfache, robuste API anbieten, damit menschliche Entwickler:innen und KI-Agenten programmatisch mit ihm arbeiten können. Die Kern-API sollte drei grundlegende Operationen unterstützen:

  • POST /products: Registriert ein neues Context Product oder aktualisiert ein bestehendes. Das würden die CI/CD-Pipelines der Kontext-Owner nutzen.
  • GET /products/search?q={query}: Findet Context Products. Die Suche sollte alle Metadatenfelder abfragen. So finden Nutzer:innen Kontext mit Anfragen wie “API specs for payments” oder “owned by finance team”.
  • GET /products/{contextProductID}: Ruft die detaillierten Metadaten eines bestimmten, bekannten Context Products ab.

Zugriff standardisieren mit dem Model Context Protocol (MCP)

Für echte Interoperabilität sollte die Plattform eine standardisierte Kommunikationsschicht für den Kontextzugriff einführen. Das verhindert auch, dass maßgeschneiderte APIs wuchern. Das Model Context Protocol (MCP) ist ein offenes Protokoll, das KI-Anwendungen über eine einheitliche Schnittstelle mit externen Tools, Daten und Systemen verbindet (Model Context Protocol (öffnet in einem neuen Tab)).

Statt einer eigenen accessAPI pro Context Product stünde jedes Produkt über einen standardisierten MCP-Server bereit (HPE - Part 3: Model Context Protocol (MCP): The protocol that powers AI agents (öffnet in einem neuen Tab)). Das Feld accessAPI im Katalog verwiese dann auf einen MCP-Tool-Call. Ein Tool für die Dokumentationssuche würde etwa als ref_search_documentation registriert, und der Agent riefe es über einen Standard-MCP-Client auf (ref-tools - Ref MCP (öffnet in einem neuen Tab)). So kann ein “Domain Context Service” als MCP-Gateway arbeiten. Er leitet Anfragen an den passenden Backend-Dienst, ohne dass der Agent die Details der Umsetzung kennen muss (HPE - Part 3: Model Context Protocol (MCP): The protocol that powers AI agents (öffnet in einem neuen Tab)). Damit wird das ganze Kontext-Ökosystem Plug-and-play. Neue Tools und Kontextquellen lassen sich hinzufügen, und jeder MCP-konforme Agent kann sie ohne eigenen Integrationscode nutzen (Sider - Is the Model Context Protocol the Missing Link for AI Agents? A No-Fluff Review (öffnet in einem neuen Tab)).

Verwandte Seiten

Quellen

Artikel

Dokumentation

Posts

Tools und Repositories