Warum KI-Agenten nicht am Modell scheitern, sondern am Kontext

Warum der Modellfokus zu kurz greift

Viele Teams kennen das Muster: Der erste Agent wirkt im Demo-Modus beeindruckend, wird im Alltag aber sprunghaft, vergisst Zwischenschritte, greift zum falschen Tool oder arbeitet mit veraltetem Wissen. Die reflexhafte Antwort lautet dann oft: besseres Modell, größeres Kontextfenster, neuer Anbieter. Genau diese Denkbewegung stellt der Anlassbeitrag infrage. Seine These ist nicht, dass Modelle unwichtig geworden sind. Sondern dass sie für viele Unternehmensprobleme nicht mehr der engste Flaschenhals sind.

Das ist plausibel. Ein Agent ist kein einzelner Modellaufruf, sondern ein System, das Informationen einsammelt, Werkzeuge nutzt, Zustände über mehrere Schritte hält und unter Berechtigungen handeln muss. OpenAI beschreibt Agenten entsprechend als Kombination aus Modell, Tools, Instruktionen, Guardrails und Orchestrierung. Anthropic geht noch einen Schritt weiter und beschreibt „Context Engineering“ als die eigentliche Disziplin hinter verlässlichen Agenten: also die Frage, welche Informationen dem Modell wann, in welcher Form und mit welchem Zweck überhaupt vorliegen.

Für IT- und Plattformteams verschiebt sich damit die Priorität. Der Engpass liegt seltener nur bei der reinen Modellintelligenz, sondern bei drei viel bodenständigeren Fragen: Bekommt der Agent den richtigen Kontext zur richtigen Zeit? Darf er nur das, was er wirklich tun soll? Und ist sein Verhalten im laufenden Betrieb beobachtbar, testbar und korrigierbar?

Genau deshalb ist die Debatte für Cloud- und Infrastrukturverantwortliche relevanter, als es auf den ersten Blick wirkt. Wer Agenten produktiv machen will, baut nicht nur Prompts. Er baut eine Zugriffsschicht auf Daten, APIs, Berechtigungen, Historie und Laufzeitzustände. Wenn diese Schicht schwach ist, kompensiert ein stärkeres Modell das nur begrenzt.

Das passt auch zu einer breiteren Marktbewegung: Unternehmen diskutieren wieder nüchterner, wo kleine, passende Modelle reichen und wo Architektur wichtiger ist als reine Modellgröße. Dazu passt auch unsere Einordnung zu Warum kleine KI-Modelle im Unternehmen plötzlich wieder gewinnen.

Was der Ausgangsartikel wirklich behauptet

Wichtig ist dabei die Reichweite der These sauber einzuordnen. Der Anlasstext ist kein Benchmark-Paper und keine Messstudie. Er ist eine Architektur- und Betriebseinordnung aus dem Infrastrukturumfeld. Sein Wert liegt deshalb nicht in harten Prozentzahlen, sondern in einer Korrektur der Blickrichtung: Wer Ausfälle, Halluzinationen oder Unzuverlässigkeit von Agenten nur als Modellproblem liest, unterschätzt die Rolle von Kontext, Datenwegen und Tool-Design.

Die belastbareren Primärquellen stützen genau diesen Punkt. Anthropic definiert Kontext ausdrücklich breiter als Prompttext: Dazu gehören Systemanweisungen, Tools, externe Daten, Nachrichtenhistorie und weitere Informationen, die während der Inferenz in das Modellfenster gelangen. OpenAI formuliert Agenten ebenfalls nicht als Chat mit Extra-Schritten, sondern als Systeme, in denen Modelle mit Werkzeugen und klaren Laufzeitregeln verbunden werden. Die redaktionelle Schlussfolgerung daraus ist: Der Begriff „Kontextschicht“ ist kein Buzzword für längere Prompts, sondern eine eigene Architekturfrage.

Was die Kontextschicht bei Agenten wirklich meint

Mit „Kontext“ ist in der Praxis deutlich mehr gemeint als das, was in einem Eingabefeld steht. Für Unternehmen besteht die Kontextschicht meist aus mindestens sechs Bausteinen.

Erstens: Arbeitsanweisungen. Dazu gehören Systemprompt, Rollenbeschreibung, Zieldefinition und Ausgaberegeln. Das ist die sichtbarste Ebene, aber nicht die wichtigste allein.

Zweitens: Retrieval und Dokumentenzugriff. Der Agent braucht oft aktuelle Informationen aus Wikis, Tickets, Datenbanken, Dateien oder Produktdokumentation. Entscheidend ist dabei nicht nur, ob er Daten findet, sondern ob er die relevanten, aktuellen und berechtigten Daten findet.

Drittens: Tooling. Sobald ein Agent nicht nur lesen, sondern suchen, schreiben, buchen, deployen oder Dateien verändern soll, wird das Tool-Design zentral. Anthropic betont, dass Tools klar, robust und mit möglichst wenig funktionaler Überlappung gestaltet sein sollten. Wenn schon ein Mensch nicht eindeutig sagen kann, welches Tool wann zu nutzen ist, wird ein Agent daran erst recht scheitern.

Viertens: Zustand und Historie. Ein Agent, der über mehrere Schritte arbeitet, muss Entscheidungen, Zwischenergebnisse und offene Punkte übergeben können, ohne dabei in einem wachsenden Datenberg zu versinken. Anthropic beschreibt dafür Muster wie Verdichtung, strukturierte Notizen und just-in-time geladenen Kontext statt permanenter Vollbefüllung.

Fünftens: Identität und Berechtigungen. Ein Agent braucht eine definierte Identität in den angeschlossenen Systemen. Sonst ist nicht sauber geregelt, auf welche Daten er zugreifen darf, welche Aktionen erlaubt sind und wie sich sein Verhalten auditieren lässt.

Sechstens: Policies und Guardrails. Gemeint sind Regeln, wann der Agent abbrechen, eskalieren, nachfragen oder eine Aktion nur read-only ausführen soll. Ohne diese Leitplanken wird Kontext schnell zur Fehlsteuerung.

Genau an dieser Stelle wird auch klar, warum Integrationsstandards Aufmerksamkeit bekommen. MCP ist im Kern interessant, weil es ein standardisiertes Muster für die Anbindung von Modellen an Tools und externe Kontexte anbietet. Das löst nicht automatisch Datenqualität, Governance oder Berechtigungschaos. Aber es zeigt, dass der Markt das Problem inzwischen als Schnittstellen- und Plattformthema behandelt, nicht nur als Modellfrage.

Wer den Punkt aus der Entwicklungsperspektive weiterdenken will, findet denselben Architekturkonflikt auch in unserer Analyse Warum KI-Code ohne Kontextstore schnell zur Architekturfalle wird.

Was das für Kosten und Nutzen im Alltag heißt

Für viele Teams ist die wichtigste Folge finanzieller Natur: Die Kostenlogik von Agenten verschiebt sich. Natürlich bleiben Modellaufrufe relevant. Aber mit wachsendem Ernstgrad wandert der eigentliche Aufwand in andere Schichten: Datenaufbereitung, Retrieval-Qualität, Tool-Wartung, Berechtigungsverwaltung, Evaluierung, Logging und Monitoring.

Das ist zunächst ernüchternd, aber auch hilfreich. Denn es macht Pilotprojekte ehrlicher. Wenn ein Agent nur in einer sauberen Demo funktioniert, weil Datenquellen manuell vorbereitet, Rechte großzügig gesetzt und Fehlerfälle ausgeblendet wurden, liegt der künftige Aufwand eben nicht primär im nächsten Modellupgrade. Er liegt im Nachrüsten einer tragfähigen Kontextarchitektur.

Ein einfaches Beispiel: Ein interner Support-Agent soll Kundenfälle zusammenfassen und Lösungsvorschläge machen. In der Demo reicht ein gutes Modell plus Wissensdatenbank. Im Betrieb kommen sofort schwierigere Fragen dazu: Welche Ticket-Historie ist maßgeblich? Darf der Agent auf Vertragsdaten zugreifen? Welche Produktversion ist beim Kunden installiert? Welche Informationen sind aktuell, welche nur Altlast? Muss vor einer Antwort noch ein CRM-Feld geprüft werden? Schon dieses banale Szenario zeigt: Der Nutzwert steigt oder fällt mit Kontextqualität, nicht nur mit Formulierungsstärke.

Darum ist auch der Satz wichtig, dass Unternehmensinfrastruktur historisch selten für „kontexthungrige“ Agenten gebaut wurde. Viele Landschaften bestehen aus SaaS-Silos, getrennten Identitäten, unterschiedlichen Datenfrischen und kaum standardisierten Tool-Schnittstellen. Ein Agent legt diese Brüche schonungslos offen.

Wo Kontext zum Sicherheitsrisiko wird

Je leistungsfähiger die Kontextschicht wird, desto gefährlicher wird sie auch. Das Risiko beginnt nicht erst bei spektakulären Fehlaktionen. Es beginnt oft viel früher: mit zu breiten Rechten, schlecht getrennten Lese- und Schreibpfaden, unklarer Herkunft von Kontext und fehlender Beobachtbarkeit.

Ein Agent kann formal „richtig“ schlussfolgern und trotzdem operativ falsch handeln, wenn sein Kontext veraltet, unvollständig oder vermischt ist. Er kann das falsche Kundenticket priorisieren, eine überholte Policy anwenden oder ein Tool auf der Grundlage eines missverstandenen Status aufrufen. Das Problem ist dann nicht reine Halluzination, sondern falsche Einbettung in die Systemrealität.

Besonders kritisch wird es, wenn ein Agent nicht nur lesen, sondern handeln darf. Dann müssen Unternehmen Rechte möglichst klein schneiden: getrennte Tool-Scopes, just-in-time Freigaben, saubere Audit-Trails und klare Grenzen zwischen Lesen, Schreiben und Ausführen. Sonst wird aus Komfort schnell eine neue Angriffs- und Fehlerfläche. Wer diese Seite vertiefen will, findet sie auch in unserer Analyse OpenAI lässt KI gegen KI testen: Was GPT-Red für Unternehmen bedeutet.

Welche Workflows sich für Agenten eignen

Die Kontextthese hilft auch bei der Auswahl sinnvoller Einsatzfelder. Geeignet sind vor allem Workflows mit vier Eigenschaften: klare Ziele, gute Datenlage, begrenzte Aktionsräume und nachvollziehbare Erfolgskriterien.

Dazu zählen etwa interne Recherche mit definierten Quellen, Ticket-Triage mit festen Feldern, Runbook-gestützte Supportschritte oder Vorarbeiten in Entwickler- und Ops-Prozessen, bei denen ein Mensch freigibt. In solchen Fällen lässt sich Kontext gezielt kuratieren und das Toolset relativ schmal halten.

Schwieriger wird es bei offenen, langlaufenden und hochriskanten Aufgaben. Je mehr Interpretationsspielraum, Systemgrenzen und irreversible Aktionen im Spiel sind, desto anspruchsvoller wird die Kontextarchitektur. Dann reichen „mehr Daten“ oder „mehr Kontextfenster“ gerade nicht. Im Gegenteil: Zu viel unkuratierter Kontext kann die Qualität sogar verschlechtern, weil Relevanz, Aufmerksamkeit und Zustandsklarheit leiden.

Ein nützlicher Merksatz für Entscheider lautet deshalb: Nicht jeder Prozess mit viel Text ist agententauglich. Agententauglich sind vor allem Prozesse, deren Kontext sich kontrolliert bereitstellen, begrenzen und überwachen lässt.

Wo die Grenze der heutigen Agenten noch liegt

Die Engpassverschiebung zur Kontextschicht ist kein Gegenbeweis gegen Modellfortschritt. Bessere Modelle helfen zweifellos bei Planung, Fehlerkorrektur und Tool-Nutzung. Aber sie heben ein strukturelles Problem nicht auf: Ein Agent bleibt von der Qualität seiner angeschlossenen Realität abhängig.

Deshalb ist die strategische Schlussfolgerung weder AI-Skepsis noch Modellfetisch. Sie lautet nüchterner: Agenten werden dort nützlich, wo Unternehmen Kontext als Produktivschicht behandeln. Also als etwas, das versioniert, berechtigt, verdichtet, überwacht und bei Bedarf begrenzt wird.

Offen bleibt, wie schnell sich dafür belastbare Standards und Benchmarks herausbilden. Der Markt bewegt sich sichtbar in Richtung besserer Tool-Protokolle, stärkerer Agenten-Frameworks und saubererer Laufzeitmuster. Aber die Architekturarbeit verschwindet dadurch nicht. Sie wird nur expliziter.

Für B2B-Teams ist das am Ende die wichtigste Entlastung: Wenn ein Agent im Alltag scheitert, ist das nicht automatisch ein Urteil über das Modell. Oft ist es ein Hinweis darauf, dass Kontext, Rechte und Systempfade noch nicht produktionsreif sind.

Was die Kontextschicht im Betrieb konkret verlangt

Sobald man die Theorie verlässt, wird die Kontextschicht zu einer Betriebsdisziplin. Die praktische Frage lautet nicht mehr nur, welche Daten „theoretisch hilfreich“ wären, sondern welche Daten in welchem Moment mit vertretbarem Risiko und vertretbaren Kosten in den Arbeitskontext eines Agenten gelangen dürfen.

Anthropic beschreibt dafür einen wichtigen Perspektivwechsel: Kontext ist eine endliche Ressource. Mehr davon ist nicht automatisch besser. Je größer und unstrukturierter das Fenster wird, desto höher das Risiko, dass Relevantes untergeht, Unwichtiges dominiert oder der Agent falsche Prioritäten setzt. Für Unternehmen heißt das: Gute Kontextarchitektur ist weniger ein Sammelproblem als ein Selektionsproblem.

Daraus folgen vier praktische Prinzipien.

1. Kontext sollte möglichst gezielt statt maximalistisch bereitgestellt werden. Ein Agent braucht nicht jede Datenquelle permanent. Häufig ist es sinnvoller, mit schlanken Referenzen zu arbeiten und Informationen erst bei Bedarf nachzuladen. Anthropic beschreibt genau diese just-in-time-Logik: Statt alles upfront in den Kontext zu kippen, hält der Agent Verweise, nutzt Tools und lädt relevante Inhalte zur Laufzeit nach. Das spart Tokens und verringert die Chance, dass veraltete oder irrelevante Informationen das Verhalten prägen.

2. Tools sind Teil des Kontextdesigns, nicht nur Anhängsel. Viele Teams behandeln Tool-Integration als technischen Nachbau eines vorhandenen UI-Flows. Für Agenten reicht das nicht. Ein Tool muss aus Modellsicht eindeutig, robust und sparsam sein. Wenn drei ähnlich benannte Funktionen ähnliche Daten liefern, ist das kein Komfort, sondern Ambiguität. Gute Agentensysteme reduzieren Wahlstress für das Modell.

3. Persistenz braucht Verdichtung. Längere Agentenläufe erzeugen Verlauf, Nebenpfade, Zwischenstände und Tool-Ergebnisse. Wenn all das ungefiltert in der Historie bleibt, wächst nicht nur der Token-Verbrauch. Es wächst auch die Unschärfe. Darum sind Kompaktierung, strukturierte Notizen und explizite Zwischenstände so wichtig. Sie ersetzen rohe Länge durch Arbeitsgedächtnis mit Priorisierung.

4. Kontext ohne Observability ist Blindflug. Teams müssen nachvollziehen können, welche Informationen ein Agent tatsächlich gesehen hat, welches Tool er wann aufgerufen hat und woran Entscheidungen hingen. Sonst lassen sich weder Fehlerbilder sauber reproduzieren noch Policies wirksam kontrollieren.

Gerade im Unternehmensumfeld ist das der eigentliche Reifeunterschied zwischen Spielerei und Produktionssystem. Ein brauchbarer Agent beantwortet nicht nur eine Anfrage. Er macht seine Kontextabhängigkeiten indirekt prüfbar: über Logs, Traces, Tool-Historien, Versionsstände und klar zuordenbare Identitäten.

Darum ist die Kontextschicht am Ende auch eine organisatorische Frage. Datenverantwortliche, Plattformteams, Security und Fachbereich müssen sich auf gemeinsame Regeln einigen: Welche Quellen gelten als verlässlich? Welche Aktionen brauchen Freigabe? Wie werden veraltete Informationen erkannt? Wer entscheidet bei Konflikten zwischen Systemen? Ohne diese Antworten skaliert kein Agent sauber, selbst wenn das Modell stark genug wäre.