AI Architecture · 10 Min.
KI-Agenten Datenarchitektur: Welche Daten ein Agent wirklich braucht
Ein Agent braucht nicht mehr Daten. Er braucht die richtigen Daten, im richtigen Format, mit den richtigen Rechten und klarer Herkunft.
SYSTEMS Grafik zu KI Agenten Datenarchitektur: Data -> Agent -> Outcome. Fokus: Welche Datenarchitektur brauchen KI-Agenten, um im Unternehmen verlaesslich zu arbeiten?
Kurzfassung
KI-Agenten brauchen kuratierten Kontext, keine ungefilterte Datenflut. Datenquellen muessen Herkunft, Aktualitaet, Rechte und Zweck sichtbar machen. RAG, Memory und Tool-Zugriff sind unterschiedliche Schichten und sollten nicht vermischt werden.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknuepfe es mit den naechsten Architekturentscheidungen.
Warum Datenarchitektur wichtiger ist als Prompting Ein guter Prompt kann schlechte Daten nicht retten. Wenn Dokumente veraltet sind, CRM-Felder fehlen oder Wissensquellen widerspruechlich sind, erzeugt der Agent plausible Unsicherheit.
Produktive Agenten brauchen deshalb eine Datenarchitektur: Welche Quellen gelten, wann werden sie genutzt, wer darf sie sehen und wie wird Aktualitaet geprueft?
Stand Mai 2026: Agenten brauchen eine Kontextarchitektur Moderne Agentenplattformen trennen immer staerker zwischen Runtime, Sessions, Memory, Tools, Retrieval, Tracing und Evaluation. Google Vertex AI Agent Engine nennt Sessions und Memory Bank als eigene Bausteine; OpenAI trennt File Search, Tools und Agentenlauf; MCP trennt Resources, Tools und Prompts.
Das ist die richtige Richtung: Ein Agent braucht keine Datenhalde, sondern eine Kontextarchitektur.
Die Architektur muss beantworten:
Google beschreibt fuer agentische Architektur explizit Auswahlentscheidungen rund um Runtime, Memory, Observability , Security, MCP und A2A . Das zeigt: Datenarchitektur endet nicht beim Vector Store. Sie entscheidet, wie Agenten mit State, Protokollen, Security und Betrieb verbunden werden.
Welche Daten sind dauerhaftes Wissen? Welche Daten sind Live-Systemzustand? Welche Daten sind Nutzer- oder Kundenmemory? Welche Daten duerfen nur gelesen, aber nie geschrieben werden? Welche Daten duerfen in Logs, Traces oder Evals landen? Kontext ist nicht gleich Daten Daten sind Rohmaterial. Kontext ist die Auswahl, die fuer eine Entscheidung relevant ist. Ein Agent braucht nicht alle Daten, sondern die richtige Sicht auf den aktuellen Job.
Zu viel Kontext kann die Qualitaet sogar senken. Der Agent findet dann mehr Text, aber weniger Wahrheit.
Die vier Datenarten Jede Art braucht eigene Regeln fuer Aktualitaet, Rechte und Nutzung.
Stammdaten: Kunden, Firmen, Projekte, Rollen, Produkte. Prozessdaten: Status, Aufgaben, Tickets, Pipeline-Stufen. Wissensdaten: Dokumente, Playbooks, FAQs, Richtlinien. Laufdaten: Agentenlogs, Korrekturen, Evals, Feedback. RAG ist kein Memory RAG holt relevante Informationen aus Wissensquellen. Memory speichert Learnings oder Praeferenzen fuer spaetere Laeufe. Tool-Zugriff ruft aktuelle Systemdaten ab.
Wenn diese Schichten vermischt werden, wird der Agent schwer kontrollierbar. Ein gutes System trennt: Was ist dokumentiertes Wissen, was ist Nutzerpraeferenz, was ist Live-Systemzustand?
Ein einfaches Modell:
Wer Memory als RAG missbraucht, speichert zu viel. Wer RAG als Live-Datenquelle nutzt, arbeitet mit veralteten Informationen.
RAG fuer dokumentiertes Wissen wie Playbooks, Richtlinien, FAQs und technische Doku. Memory fuer stabile Praeferenzen, wiederkehrende Fakten und Verlauf zwischen Sessions. Tools fuer aktuelle Daten wie CRM-Status, Kalender, Tickets oder Bestellungen. State fuer temporaere Daten innerhalb eines laufenden Agentenlaufs. Die RAG-Pipeline muss sichtbar sein RAG ist nicht "wir laden Dokumente hoch". Eine produktive Pipeline hat klare Schritte:
OpenAI beschreibt Vector Stores als Primitive, bei dem Dateien gechunkt, eingebettet und indexiert werden. Google beschreibt fuer RAG ebenfalls Ingestion, Parsing, Chunking und Retrieval als Architekturfluss. Genau diese Pipeline muss ein Unternehmen besitzen, nicht nur ein Tool.
Ingestion: Welche Dokumente kommen hinein? Parsing: Wie werden PDFs, Webseiten, Tabellen oder Mails zerlegt? Chunking: Wie gross sind die Einheiten und welche Metadaten tragen sie? Embedding und Index: Wie werden Inhalte auffindbar? Retrieval: Welche Treffer kommen in den Kontext? Reranking oder Filter: Was wird verworfen? Citation und Source: Welche Quelle stuetzt die Antwort? Kontextbudget ist eine Architekturgrenze Tool-Definitionen, Tool-Ergebnisse, Dokumentauszuege und Chat-History verbrauchen Kontext. Anthropic beschreibt dafuer praktische Gegenmittel: Tool Search, Programmatic Tool Calling, Prompt Caching und Context Editing. Das ist nicht nur Kostenoptimierung. Es ist Qualitaetskontrolle.
Ein Agent sollte nicht alle Tools und alle Dokumente immer sehen. Er sollte das sehen, was fuer den aktuellen Schritt relevant ist.
OpenAI unterscheidet zudem zwischen OpenAI-maintained Connectors und eigenen Remote-MCP-Servern. Fuer Datenarchitektur ist das wichtig: Ein Connector ist nicht dasselbe wie eine selbst kontrollierte Tool- und Datenzugriffsschicht.
Permissions gehoeren in die Datenarchitektur Ein Agent sollte nie Daten sehen, nur weil sie technisch erreichbar sind. Er braucht denselben oder strengeren Zugriff wie der Mensch, fuer den er arbeitet.
Das gilt besonders in Multi-Kunden-, Admin- oder Investor-Umgebungen. Datenleckage zwischen Rollen ist ein Architekturfehler, kein Promptproblem.
Jede Datenquelle braucht deshalb einen Datenvertrag:
Zweck: Wofuer darf die Quelle genutzt werden? Owner: Wer ist fuer Qualitaet verantwortlich? Frische: Wie aktuell muss sie sein? Scope: Fuer welche Rolle, welchen Kunden, welchen Workflow? Herkunft: Aus welchem System kommt sie? Retention: Wie lange darf sie in Logs, Memory oder Traces bleiben? Fallback: Was passiert, wenn die Quelle fehlt oder widerspricht? Datenqualitaet messen Gute Datenarchitektur hat Metriken: Abdeckung, Aktualitaet, Dubletten, Quellenkonflikte, fehlende Felder und Korrekturrate.
Wenn Agenten Fehler machen, sollte sichtbar werden, ob das Modell falsch lag oder die Datenbasis schlecht war.
Evals brauchen eigene Daten Produktive Agenten brauchen nicht nur Arbeitsdaten, sondern Testdaten. Gute Evals enthalten echte Grenzfaelle: veraltete CRM-Felder, widerspruechliche Dokumente, fehlende Berechtigungen, leere Suchergebnisse, doppelte Kundendatensaetze und manipulierte externe Inhalte.
Ohne Eval-Daten wird jede Datenarchitektur erst im Live-Betrieb getestet. Das ist zu spaet.
Der SYSTEMS-Blick KI-Agenten brauchen keine endlose Wissensdatenbank. Sie brauchen eine klare Kontextmaschine.
Wer Datenquellen, Rechte, RAG, Memory und Live-Tools sauber trennt, baut Agenten, die weniger raten und mehr arbeiten.
