Ein Agent mit Zugriff auf Ihre Daten kann Dinge finden. Ein Agent mit Kontext weiß, was diese Dinge in Ihrer Operation bedeuten: wofür die Aufgabe da ist, wo der Workflow gerade steht, welche Definitionen gelten, welche Quelle maßgeblich und aktuell ist, was er sehen und tun darf, welche Aktionen eine Freigabe brauchen und wie die Organisation beim letzten Mal entschieden hat. Retrieval liefert Material; Kontext ist die gestaltete Schicht aus Zustand, Herkunft, Berechtigungen und Entscheidungsregeln darum herum. Ohne diese Schicht erzeugt mehr Zugriff mehr selbstsichere Fehler.
Denken wir uns beispielhaft ein Angebotsteam. Ihr neuer Agent ist mit dem gemeinsamen Laufwerk, dem CRM, der Richtlinienbibliothek und drei Jahren früherer Angebote verbunden. Gebeten, eine Antwort zu entwerfen, erzeugt er in Minuten ein flüssiges, gut belegtes Dokument. Es zitiert eine Lieferzusage aus einem Angebot von 2023, das die Firma nicht mehr anbietet, beruft sich auf eine Sicherheitsrichtlinie, die im Frühjahr ersetzt wurde, und verspricht einen Rabatt, den nur ein Direktor genehmigen darf. Technisch ist nichts fehlgeschlagen. Jedes Retrieval war erfolgreich.
Der Agent hatte Zugriff. Er hatte keinen Kontext. Das ist die Lücke, die entscheidet, ob man einem Enterprise-Agenten einen Schritt in einem echten Workflow anvertrauen kann, und sie wird nicht geschlossen, indem man mehr Quellen anbindet. Sie wird geschlossen, indem man gestaltet, was der Agent über die Operation weiß, bevor er handelt.
Was ist Unternehmenskontext?
Unternehmenskontext ist das operative Verständnis, das ein Agent braucht, um in einer bestimmten Organisation korrekt zu handeln: der Zweck der Aufgabe, der aktuelle Zustand des Workflows und seine Abhängigkeiten, die verwendeten Geschäftsdefinitionen, welche Quellen maßgeblich und aktuell sind, was der Agent sehen und tun darf, welche Entscheidungen eine Freigabe verlangen und wie vergleichbare Situationen zuvor entschieden wurden. Er ist etwas anderes als das Rohmaterial in Dokumenten und Systemen; er macht dieses Material für eine folgenreiche Aktion nutzbar.
Anthropic beschreibt Context Engineering als Nachfolger des Prompt Engineerings: Die Frage ist nicht mehr, wie man eine Anweisung formuliert, sondern „welche Konfiguration des Kontexts am ehesten das gewünschte Verhalten unseres Modells erzeugt“. Im Unternehmen ist diese Konfiguration größtenteils kein Text, den der Agent liest. Sie besteht aus Zustand, Berechtigungen und Regeln, die das umgebende System durchsetzt.
Zugriff, Retrieval, Gedächtnis und Kontext sind verschiedene Dinge
Datenzugriff ist eine Verbindung. Retrieval findet relevante Passagen für eine Anfrage. Gedächtnis trägt Informationen über Schritte und Sitzungen hinweg. Kontext ist die gestaltete Schicht, die dem Agenten sagt, was eine Passage bedeutet, ob sie aktuell ist, wer sie nutzen darf und was damit getan werden darf. Jede Schicht ist notwendig; keine der ersten drei ersetzt die vierte.
| Schicht | Was sie dem Agenten gibt | Was sie dem Agenten allein nicht sagen kann |
|---|---|---|
| Datenzugriff | Eine Verbindung zu einem Laufwerk, einer Datenbank, einer API oder einer Anwendung | Welche der Tausende erreichbaren Elemente für diese Aufgabe zählen |
| Retrieval (RAG) | Passagen, nach Relevanz für die Anfrage gerankt | Ob eine Passage aktuell, überholt, im Geltungsbereich oder für diesen Anfragenden zulässig ist |
| Gedächtnis | Fakten und Historie über Schritte und Sitzungen hinweg | Welche erinnerten Fakten noch stimmen und welche Entscheidungen statt Fakten waren |
| Operativer Kontext | Workflow-Zustand, Definitionen, Herkunft, Berechtigungen, Freigaberegeln, Präzedenzfälle | Nichts, wofür er nicht ausgelegt wurde: Er ist nur so gut wie die Quellen und Regeln dahinter |
Retrieval-Augmented Generation, eingeführt von Lewis et al. (2020), bleibt der richtige Weg, große, sich ändernde Wissensbestände im Moment der Nutzung an ein Modell heranzuführen. Der Designfehler besteht darin, die abgerufene Passage als die Antwort zu behandeln statt als Evidenz, die noch eine Prüfung bestehen muss: Ist es die aktuelle Fassung, ist der Anfragende dazu berechtigt, und braucht das Handeln darauf eine menschliche Entscheidung?
Sieben Dinge, die ein Agent wissen muss, bevor er handelt
- Zweck und Erfolgskriterien. Wofür der Schritt da ist und wie ein akzeptables Ergebnis aussieht, damit der Agent ein vollständiges Ergebnis von einem plausiblen unterscheiden kann.
- Workflow-Zustand und Abhängigkeiten. Wo der Fall steht, was vorgelagert bereits entschieden wurde, was nachgelagert wartet und was nicht mehr geändert werden darf, sobald ein späterer Schritt es verbraucht hat.
- Geschäftsdefinitionen. Was „aktiver Kunde“, „freigegebener Lieferant“ oder „Liefertermin“ hier bedeutet, nicht allgemein. Die meisten Unternehmensbegriffe haben eine lokale Definition und einen Eigner.
- Herkunft, Version und Aktualität. Woher jede Eingabe stammt, welche Version sie ist, wann sie zuletzt bestätigt wurde und welche Quelle gewinnt, wenn zwei sich widersprechen.
- Rollen, Berechtigungen und Grenzen. Was der Agent lesen und schreiben darf, in wessen Auftrag, und welche Systeme für diese Aufgabe außerhalb des Umfangs liegen, selbst wenn sie technisch erreichbar sind.
- Richtlinien und Freigabeanforderungen. Welche Aktionen dem Agenten obliegen, welche einen benannten Freigeber brauchen und welche nie automatisiert werden.
- Entscheidungen, Ausnahmen und Ergebnisse. Wie die Organisation vergleichbare Fälle behandelt hat, welche Ausnahmen gewährt wurden und warum und was danach geschah.
Und eine Regel für den Fall, dass die Liste nicht erfüllt ist: Fehlen Informationen, sind sie veraltet oder widersprüchlich, sollte der Agent anhalten und mit dem, was er gefunden hat, eskalieren, statt die Lücke zu füllen. Ein verlässlicher Agent ist einer, dessen Verweigerungen so gut gestaltet sind wie seine Antworten.
Warum mehr gespeicherte Information nicht automatisch besser ist
Weil Aufmerksamkeit ein endliches Budget ist, kein Lager. Anthropic weist darauf hin, dass ein Transformer über n Tokens n² paarweise Beziehungen bildet, sodass jedes zusätzliche Token die Fähigkeit des Modells verdünnt, die wichtigen zu verfolgen. Liu et al. stellten fest, dass die Modellleistung nach Position einer U-Kurve folgt: am stärksten für Informationen am Anfang oder Ende einer langen Eingabe, am schwächsten in der Mitte, selbst bei Modellen, die für langen Kontext gebaut wurden. Massenhafter Kontext erweitert zudem die Angriffs- und Abflussfläche. Kuratierter, berechtigungsgesteuerter, beschrifteter Kontext schlägt mehr Kontext.
Die Sicherheitsfolgen sind dokumentiert. Die OWASP Top 10 für LLM-Anwendungen (2025) führen Excessive Agency auf: ein Agent, dem mehr Funktionalität, Berechtigungen oder Autonomie gegeben wurde, als seine Aufgabe braucht, sodass eine manipulierte oder schlicht fehlerhafte Ausgabe zu einer schädlichen Aktion wird; und Schwächen bei Vektoren und Embeddings , die vergiftete Retrieval-Speicher und mandantenübergreifenden Abfluss in RAG-Pipelines umfassen. Indirekte Prompt Injection, bei der in einem abgerufenen Dokument versteckte Anweisungen den Agenten umlenken, ist genau ein Kontextproblem: Der Agent konnte Evidenz nicht von Anweisung unterscheiden.
Die praktische Konsequenz für einen CIO oder Operations-Leiter: Die Frage an einen Anbieter oder ein Team lautet nicht „wie viel kann der Agent sehen?“, sondern „woher weiß der Agent, welches von dem, was er sieht, für diesen Schritt aktuell, zulässig und maßgeblich ist?“
Beispiel: Ein Agent für Ausschreibungsantworten, der fünf Dinge unterscheiden muss
Illustratives Szenario. Es spiegelt die Struktur eines Angebots-Workflows wider, nicht Daten oder Ergebnisse eines bestimmten Kunden. Der eigene Fall KI-gestützte Angebotserstellung von World AI X beschreibt eine im Einsatz befindliche Fassung dieses Workflows.
Eine Ausschreibung trifft ein. Aufgabe des Agenten ist es, die Compliance-Matrix aufzubauen und eine Antwort aus freigegebenem Material zu entwerfen. Um das verlässlich zu tun, muss er fünf Arten von Eingaben unterscheiden, die auf einem gemeinsamen Laufwerk gleich aussehen:
| Eingabe | Wie der Agent sie behandeln muss |
|---|---|
| Aktuelle Ausschreibungsanforderungen | Der maßgebliche Umfang für diese Antwort. Jede Anforderung wird zu einer Zeile in der Matrix; nichts anderes definiert, was „konform“ bedeutet. |
| Freigegebene Unternehmensfähigkeiten | Die einzigen Aussagen, die der Entwurf als Fakt behaupten darf, entnommen einer gesteuerten Bibliothek mit Eigner und Prüfdatum. |
| Ein älteres Angebot | Evidenz dafür, wie die Firma früher geantwortet hat, nützlich für Struktur und Ton, niemals eine Quelle aktueller Aussagen ohne erneute Freigabe. |
| Eine überholte Richtlinie | Muss anhand von Version und Gültigkeitsdatum als zurückgezogen erkannt und ausgeschlossen werden, selbst wenn sie die semantisch ähnlichste Passage ist. |
| Eine kommerzielle Zusage | Preise, Liefertermine und Haftungen werden als Platzhalter entworfen und an den benannten Freigeber geleitet; der Agent behauptet sie nie. |
Beachten Sie, dass keine dieser Unterscheidungen durch Retrieval-Qualität getroffen wird. Ein besseres Embedding-Modell findet die überholte Richtlinie nur schneller. Die Unterscheidungen kommen aus Metadaten, die das System pflegt (Status, Version, Eigner, Gültigkeitsdatum), aus Berechtigungen, die begrenzen, was der Agent behaupten darf, und aus einer Freigaberegel, die bestimmte Ausgaben in Anfragen statt Aussagen verwandelt.
Die Kontext-Checkliste: Bevor ein Agent eine folgenreiche Aktion ausführt
Vier Fragen, gestellt an jede Eingabe, auf die sich der Agent stützt, und jede Aktion, die er ausführen darf. Lautet eine Antwort „nein“ oder „unbekannt“, ist der Schritt nicht bereit für Autonomie.
✓Aufgabenzweck und Erfolgskriterien sind benannt, nicht erschlossen
✓Der aktuelle Workflow-Zustand und vorgelagerte Entscheidungen sind für den Agenten lesbar
✓Lokale Geschäftsdefinitionen existieren für die Begriffe, von denen der Schritt abhängt
✓Jede Quelle trägt eine Version, einen Eigner und ein Gültigkeits- oder Prüfdatum
✓Überholtes und Entwurfsmaterial ist markiert und standardmäßig ausgeschlossen
✓Eine Vorrangregel sagt, welche Quelle gewinnt, wenn zwei sich widersprechen
✓Der Agent handelt unter einer benannten Identität mit Least-Privilege-Zugriff
✓Lese-, Schreib- und Systeme außerhalb des Umfangs sind pro Schritt definiert, nicht pro Agent
✓Folgenreiche Aktionen haben einen benannten Freigeber; manche werden nie automatisiert
✓Jede Ausgabe lässt sich auf die verwendeten Quellen und Versionen zurückführen
✓Entscheidungen, Ausnahmen und Freigaben werden mit Begründung protokolliert
✓Fehlende oder widersprüchliche Informationen lösen eine Eskalation aus – und auch die wird protokolliert
Woher wissen Sie, dass der Agent den richtigen Kontext verwendet hat?
Testen Sie den Kontext, nicht nur die Antwort. Bauen Sie Evaluationsfälle, die veraltetes, überholtes und nicht im Umfang liegendes Material neben den richtigen Quellen enthalten, und bewerten Sie, ob der Agent die richtigen gewählt, zitiert und beachtet hat. Messen Sie das Eskalationsverhalten bei fehlenden oder widersprüchlichen Informationen. Und prüfen Sie akzeptierte Geschäftsergebnisse, nicht erfolgreiche Tool-Aufrufe; ein Agent, der jeden Schritt abschloss und einen unbrauchbaren Entwurf erzeugte, war nicht erfolgreich.
- Herkunftsabdeckung. Anteil folgenreicher Aussagen einer Ausgabe, die auf eine freigegebene, aktuelle Quelle zurückgehen.
- Ablenker-Tests. Repräsentative Aufgaben, gespickt mit zurückgezogenen Richtlinien und alten Angeboten; Bestehensbedingung ist, dass sie erkannt und nicht bloß zufällig vermieden werden.
- Eskalationsrate und -qualität. Wie oft der Agent anhält, wenn er es sollte, und ob das, was er übergibt, ausreicht, damit ein Mensch schnell entscheiden kann.
- Berechtigungstreue. Null Lese- oder Schreibzugriffe außerhalb des definierten Umfangs des Schritts, anhand von Logs verifiziert statt aus der Konfiguration angenommen.
Diese Kennzahlen gehören vor dem Bau in den Business Case, nicht in eine Nachbetrachtung danach. Sie sind der Unterschied zwischen einem Agenten, den Sie auditieren können, und einem, den Sie nur beobachten können.
Wo das in World AI OS liegt
In World AI OS ist diese Schicht Brain, die operative Kontextschicht. Sie tut drei Dinge, die sich direkt auf die obige Checkliste abbilden. Die Kontextintegration verbindet strukturierte und unstrukturierte Informationen über Dokumente, Datenbanken, Anwendungen, APIs und Betriebssysteme hinweg, lässt die Informationen in ihren bestehenden Systemen und gibt dem OS den Kontext, den es braucht, um systemübergreifend zu arbeiten. Der operative Graph strukturiert diese Umgebung rund um Beziehungen statt um isolierte Datensätze: Workflows zu Aufgaben, Menschen zu Entscheidungen, Systeme zu Daten, Assets zu Ereignissen, Aktionen zu Ergebnissen. Das operative Gedächtnis bewahrt die Evidenz, Annahmen, Entscheidungen, Änderungen und Ergebnisse, die entstehen, während Arbeit durch Studio, Factory und die Produktion wandert, sodass jede neue Transformation mit mehr Kontext beginnt als die letzte.
Der Sinn einer gemeinsamen Kontextschicht ist, dass Studio, das den Workflow neu gestaltet, und Factory, das ihn baut und betreibt, mit demselben sich entwickelnden Modell der Operation arbeiten, statt jeweils ein eigenes neu aufzubauen. Wie viel einer Operation modelliert wird und wie schnell, wird in jedem Engagement festgelegt; die Architektur ist so ausgelegt, dass sich Kontext ansammelt, statt pro Projekt rekonstruiert zu werden.
Häufig gestellte Fragen
Was ist Unternehmenskontext für einen KI-Agenten?
Das operative Verständnis, das ein Agent braucht, um in einer bestimmten Organisation korrekt zu handeln: der Zweck der Aufgabe, der aktuelle Zustand des Workflows, die verwendeten Geschäftsdefinitionen, welche Quellen maßgeblich und aktuell sind, was der Agent sehen und tun darf, welche Entscheidungen eine Freigabe brauchen und wie ähnliche Situationen zuvor behandelt wurden. Der Zugriff auf Dokumente und Systeme liefert Rohmaterial; Kontext sagt dem Agenten, was dieses Material bedeutet und was er damit tun darf.
Reicht Retrieval-Augmented Generation (RAG), um einem Agenten Kontext zu geben?
Nein, aber es ist ein notwendiger Teil der Antwort. Retrieval findet im Moment der Anfrage relevante Passagen. Es weiß von sich aus nicht, ob eine Passage aktuell oder überholt ist, ob der Anfragende sie sehen darf, ob das Handeln darauf eine Freigabe braucht oder was beim letzten Mal geschah, als die Organisation vor derselben Situation stand. Das muss um die Retrieval-Schicht herum gestaltet werden.
Warum ist es nicht automatisch besser, einem Agenten mehr Informationen zu geben?
Sprachmodelle haben ein endliches Aufmerksamkeitsbudget: Je mehr Tokens im Kontext, desto dünner verteilt sich die Aufmerksamkeit, und Forschung zeigt, dass die Erinnerung an Informationen in der Mitte langer Eingaben nachlässt. Ungefilterter Kontext erweitert zudem die Fläche für indirekte Prompt Injection und für den Abruf von Daten, die der Anfragende nicht sehen sollte. Kuratierter, berechtigungsgesteuerter, gut beschrifteter Kontext übertrifft massenhaften Kontext.
Wie bewertet man, ob ein Agent den richtigen Kontext verwendet hat?
Führen Sie jede folgenreiche Ausgabe auf die Quellen, Versionen und Berechtigungen zurück, auf die sie sich stützte; führen Sie repräsentative Aufgaben aus, die veraltetes, überholtes und nicht im Umfang liegendes Material enthalten, um zu sehen, ob der Agent es erkennt; messen Sie, wie oft er bei fehlenden oder widersprüchlichen Informationen eskaliert, statt zu raten; und prüfen Sie akzeptierte Ergebnisse, nicht nur erfolgreiche Tool-Aufrufe.