Context Engineering bei Databricks: Warum die meisten KI-Agenten nicht am Modell, sondern am Kontext scheitern

Context Engineering bezeichnet die gezielte Steuerung aller Informationen, die ein KI-Agent zur Laufzeit im Kontextfenster erhält. Dazu gehören System-Prompts, abgerufene Daten, Werkzeuge und Gedächtnis. Das Ganze lohnt sich vor allem, sobald ein Agent produktiv arbeiten soll und nicht nur ein einzelner Prompt getestet wird. Laut MIT NANDA (2025) erzielen 95 Prozent der KI-Projekte keinen messbaren wirtschaftlichen Nutzen, oft wegen fehlendem Kontext-Management. Ohne eine saubere und gepflegte Datengrundlage bleibt jede Technik unzuverlässig.

Stellen Sie sich vor, Sie bauen einen Agenten, der Kundenanfragen beantworten soll. Manchmal antwortet er perfekt aber manchmal fehlen ihm die richtigen Informationen und er erfindet sich seine eigene Wahrheit. Genau dieses Problem wird seit 2025 unter dem Begriff Context Engineering diskutiert.

Wenn Sie deshalb über ein größeres Modell oder mehr Kontext nachdenken, liegt der Fehler in den meisten Fällen am fehlenden Context Engineering.

Unsere Einschätzung: Die meisten Unternehmen, die daran scheitern, haben kein Prompt-Problem, sondern ein Datenproblem, das sehen wir in fast jedem Projekt, in dem wir einen bestehenden Agenten überarbeiten. Dieser Ratgeber zeigt Ihnen, was Context Engineering wirklich kostet und wie Sie den passenden Ansatz für Ihr Unternehmen finden.

Was ist Context Engineering und warum reicht Prompt Engineering nicht mehr aus?

Der Begriff selbst wurde im Juni 2025 durch einen Tweet von Shopify-CEO Tobi Lütke bekannt und im selben Monat von Harrison Chase, LangChain und Phil Schmid von Google DeepMind inhaltlich ausformuliert. Anthropic lieferte im September 2025 mit “Effective context engineering for AI agents” die bis heute meistzitierte sowie praxisnahe Definition. Sie besagt, dass Context Engineering die Strategien beschreibt, mit denen Sie zur Laufzeit genau die Menge an Informationen im Kontextfenster eines Sprachmodells verwalten und pflegen können, die es für eine Aufgabe wirklich braucht.

Anthropic und LangChain zeigen übereinstimmend, dass Prompt Engineering dabei eine Teilmenge von Context Engineering darstellt und keinen Gegensatz dazu. Ein Prompt ist ein einmalig geschriebener und meist statischer Text. Context Engineering begleitet einen Agenten dagegen über seinen kompletten Lebenszyklus. Dabei beschäftigt er sich mit Fragen wie „Was wird zu Beginn geladen?“, „Welche Informationen bleiben relevant und welche veralteten und müssen raus?“ oder „Was lässt sich komprimieren und was muss erst zur Laufzeit nachgeladen werden?“

Ein KI-Agent setzt sich aus sechs Komponenten zusammen, die alle Teil des Kontexts sind, den Sie aktiv gestalten müssen:

• Modell: das Sprachmodell selbst, das Ihre Anfrage versteht und verarbeitet
• Werkzeuge: die Mittel, mit denen der Agent auf CRM-Systeme, Datenbanken oder Ticketsysteme zugreifen kann
• Gedächtnis: vergangene Interaktionen und Konversationen, die zur richtigen Zeit wieder in den Kontext einfließen
• Sprache: die Fähigkeit, natürliche Sprache als Ton aufzunehmen und wiederzugeben, vor allem relevant bei Sprachagenten
• Leitplanken: klare Grenzen, was der Agent tun darf, tun soll und explizit unterlassen soll
• Überwachung und Bewertung: die laufende Kontrolle durch Menschen oder ein zweites Sprachmodell als Prüfinstanz, wie gut der Agent tatsächlich arbeitet

Laut Salesforce und dem Deutschen Mittelstands-Bund (2026) liegt der Einsatz von KI-Agenten deutscher Unternehmen aktuell bei 16,6 Prozent. Das ist fast doppelt so viel wie 2024 mit 8,7 Prozent. Der Anteil wächst schnell, aber die meisten Unternehmen stehen dennoch am Anfang. Für Sie heißt das, dass diejenigen, die jetzt verstehen, wie Context Engineering funktioniert, sich einen Vorsprung verschaffen, den Späteinsteiger nur schwer aufholen können.

Diese fünf Ansätze stehen beim Context Engineering zur Auswahl

LangChain fasst die Techniken des Context Engineering in vier Grundstrategien zusammen:

1. Ablegen, also Informationen außerhalb des Kontextfensters speichern, etwa in einem Notizspeicher
2. Auswählen beziehungsweise gezielt relevante Informationen abrufen, klassischerweise per RAG
3. Verdichten, nur die nötigen Informationen behalten
4. Aufteilen, den Kontext auf mehrere Agenten verteilen. Für die Praxis lassen sich daraus fünf konkrete Ansätze ableiten, zwischen denen Sie wählen können:

Databricks kann bei der Entscheidung zwischen RAG und Fine-Tuning helfen. Während RAG externe, aktuelle Daten zur Laufzeit einbindet, ohne das Modell neu zu trainieren, verändert Fine-Tuning die Modellgewichte dauerhaft und eignet sich daher eher für Stil und Struktur als für Faktenwissen. Daher sehen wir in der Anwendung bei den meisten Kunden eine Kombination. Einerseits RAG für das Fachwissen und andererseits ein schlanker System-Prompt für Ton und Format.

Ein Mythos, den wir regelmäßig ausräumen müssen ist, dass ein größeres Kontextfenster reicht, um sich die ganze RAG-Architektur zu sparen. Chroma Research hat 2025 an 18 Modellen gezeigt, dass Sprachmodelle ihren Kontext nicht gleichmäßig nutzen. Mit wachsender Eingabelänge sinkt die Zuverlässigkeit der Antworten. Dieser Effekt wird als “Context Rot” bezeichnet und auf die ältere Beobachtung “Lost in the Middle” zurückverfolgt.

Auch Databricks bestätigt in einer eigenen Studie mit über 2.000 Experimenten an 13 Modellen, dass die meisten getesteten Sprachmodelle bei sehr langen Kontexten an Genauigkeit verlieren und einige sogar zunehmend die Antwort verweigern. Nur wenige Spitzenmodelle bleiben über einen weiten Bereich hinweg stabil. Mehr Kontext ist also kein Ersatz für gut kuratierten Kontext und genau das ist der Kern von Context Engineering.

Was kostet Context Engineering wirklich?

Kein einziger der von uns geprüften deutschen Artikel zu diesem Thema liefert eine belastbare Kostenrechnung. Das ist die auffälligste Lücke in den aktuell verfügbaren Inhalten zum Thema Context Engineering, obwohl die Kostenfrage für Entscheider deutscher Unternehmen meistens die erste ist, die gestellt wird.

Token-Kosten steigen mit der Architektur. Anthropic berichtet, dass einzelne KI-Agenten im Schnitt ungefähr viermal so viele Tokens verbrauchen wie ein einfacher Chat-Austausch und Multi-Agenten-Systeme sogar circa fünfzehnmal so viele. Das ist kein Grund, auf Agenten zu verzichten, aber ein guter Grund, Multi-Agenten-Architekturen nur dort einzusetzen, wo der Mehrwert die höheren Kosten auch wirklich rechtfertigt.

Gute Kontext-Pflege senkt Kosten, anstatt sie nur zu verschieben. Eine aktuelle Studie zu Agenten mit langem Aufgabenhorizont zeigt, dass gezieltes Kürzen und Zusammenfassen des Kontexts den Tokenverbrauch in einem 50-Aufgaben-Benchmark um 63 Prozent senkte, also von rund 1,48 Millionen auf 553.000 Tokens und gleichzeitig die Erfolgsquote von 71 auf 91,6 Prozent steigerte. Weniger, aber besser kuratierter Kontext schlägt in dieser Untersuchung mehr Kontext in beiden Dimensionen gleichzeitig.

Für die laufenden Infrastrukturkosten liefert der Databricks Community Blog eine Beispielrechnung für einen Kundenservice-Agenten mit RAG über Vector Search, Delta-Lake-Abfragen und Model Serving. Je nach Nutzungsintensität liegt die Gesamtschätzung bei 4.500 bis 8.000 US-Dollar pro Monat. Das ist zwar nur das Praxisbeispiel eines Databricks-Mitarbeiters und keine offizielle Preisgarantie, aber ein realistischer Ankerpunkt für Ihre eigene Budgetplanung.

Expertentipp von Laurenz, CTO bei Datasolut: 

In unseren Projekten ist der größte Kostentreiber selten das Modell selbst, sondern die Zeit, die ein Team braucht, um die eigene Datenbasis überhaupt RAG-fähig zu machen. Mit unserem DSX Machine Learning Framework, destilliert aus über 200 MLOps-Projekten, verkürzen wir genau diesen Schritt und bringen erste produktionsreife Lösungen häufig innerhalb von 4 bis 6 Wochen statt Monaten an den Start.

Beachten Sie, dass sich Preise für lange Kontextfenster derzeit schnell ändern. Anthropic beispielsweise verlangte bei der Einführung des 1-Millionen-Token-Kontexts im August 2025 noch einen Aufpreis für Prompts über 200.000 Token und heute wird dieser laut aktueller Preisdokumentation nicht mehr erhoben. Prüfen Sie aktuelle Preise also immer kurz vor einer Budgetentscheidung nach.

So finden Sie Schritt für Schritt den richtigen Ansatz für Ihr Unternehmen

Schritt 1: Datenbasis und Zuständigkeit prüfen

Bevor Sie über Modelle oder Werkzeuge entscheiden, sollten Sie prüfen, wie konsolidiert und gut geordnet Ihre Unternehmensdaten aktuell sind. Laut Salesforce und dem Deutschen Mittelstands-Bund sind fehlendes Praxiswissen (39,9 Prozent) und mangelnde Datenqualität (23,7 Prozent) die häufigsten realen Hürden im deutschen Mittelstand und nicht die KI-Technologie selbst.

Worauf Sie achten sollten:

• Liegen Ihre relevanten Daten an einem Ort mit einheitlichen Regeln, zum Beispiel über Unity Catalog?
• Wissen Sie, welche Daten aktuell und welche veraltet sind?
• Gibt es klare Zugriffsrechte für sensible oder personenbezogene Daten?

Typischer Fehler: Unternehmen starten mit dem Agenten-Prototyp, bevor die Datenbasis überhaupt sauber ist, und wundern sich anschließend über Halluzinationen.

Schritt 2: Anwendungsfall und Aufgabenkomplexität bewerten

Nicht jede Aufgabe benötigt die volle Context-Engineering-Architektur. Eine einfache, stabile Aufgabe mit wenig Variation kommt oft mit gutem Prompt Engineering aus und eine Aufgabe mit wechselnden, aktuellen Fakten braucht RAG.

Worauf Sie achten sollten:

• Wie oft ändern sich die relevanten Informationen für diese Aufgabe?
• Muss der Agent über mehrere Schritte oder Sitzungen hinweg konsistent bleiben?
• Wie hoch ist die Fehlertoleranz für diesen Anwendungsfall?

Typischer Fehler: Ein Multi-Agenten-System für eine Aufgabe bauen, die ein sauberer Einzelprompt genauso gut löst, und dabei unnötig hohe Token-Kosten produzieren.

Schritt 3: Ansatz wählen und Architektur skizzieren

Basierend auf Schritt eins und zwei legen Sie fest, welche Kombination aus Prompt Engineering, RAG, Fine-Tuning, sehr großem Kontextfenster oder Gedächtnis-Management zu Ihrer Situation passt. (Siehe auch Entscheidungsmatrix weiter unten.)

Worauf Sie achten sollten:

• Welche Werkzeuge braucht der Agent wirklich und welche würden nur das Kontextfenster verstopfen?
• Wie wird veralteter oder irrelevanter Kontext wieder entfernt?

Typischer Fehler: Dem Agenten von Anfang an Zugriff auf alle verfügbaren Werkzeuge zu geben, anstatt nur die für die jeweilige Aufgabe relevanten zu laden.

Schritt 4: Piloten bauen und Kontext iterativ verbessern

Statt direkt in die Produktion zu gehen, bauen Sie einen kleinen Piloten mit einem klar formulierten System-Prompt, definierten Teilaufgaben und einem festen Ausgabeformat. Genau so haben wir es für einen internen Recherche-Agenten eingerichtet. Er hat eine konkrete Rollenbeschreibung, strukturierte Teilaufgaben, ein festes JSON-Ausgabeformat und eine explizite Anweisung, nur die Quellen der letzten zehn Tage zu berücksichtigen.

Worauf Sie achten sollten:

• Ist die Rollenbeschreibung des Agenten konkret genug, oder bleibt Interpretationsspielraum?
• Bekommt der Agent ein Format vorgegeben, in dem er antworten soll?

Typischer Fehler: Den Piloten mit einem einzigen und allgemein formulierten Prompt starten und dann enttäuscht darüber sein, dass die Ergebnisse nicht immer konsistent sind.

Schritt 5: Laufende Überwachung und Bewertung etablieren

Ein produktiver Agent muss dauerhaft durch Menschen oder ein zweites Sprachmodell als Prüfinstanz überwacht werden. Nur so erkennen Sie frühzeitig, wenn sich die Qualität verschlechtert.

Worauf Sie achten sollten:

• Wie viele Anfragen laufen durch den Agenten und wie werden sie ausgewertet?
• Gibt es eine Rückmeldeschleife, über die schlechte Antworten erkannt und korrigiert werden?

Typischer Fehler: Den Agenten nach dem Start sich selbst überlassen, ohne laufende Qualitätskontrolle.

So sieht Context Engineering auf einer Databricks-Datenplattform aus

Eines unserer Praxisbeispiele zeigt das Prinzip gut. Für ein Telekommunikationsunternehmen haben wir einen RAG-basierten Chatbot eingerichtet, der internes Wissen aus SharePoint für Mitarbeitende schnell und gezielt auffindbar macht.

Beim Context-Engineering ist das ein klassisches Beispiel für das gezielte Auswählen von Wissen, wie es auch das LangChain-Modell beschreibt. Hier muss aus einer großen, unstrukturierten Wissensbasis und zur richtigen Zeit genau der relevante Ausschnitt in den Kontext des Sprachmodells geladen werden.

Auf einer Databricks-Plattform sieht eine vergleichbare Architektur in der Regel so aus, dass Unity Catalog Zugriffsrechte und Herkunft der Dokumente zentral verwaltet, Delta Lake die aufbereiteten Inhalte hält, Mosaic AI Vector Search die semantische Suche übernimmt und ein Model-Serving-Endpunkt die Antwort an den Agenten ausliefert.

Entscheidend ist dabei nicht die Auswahl der Komponenten, sondern die Datenaufbereitung davor. Ohne die konsolidierten, aktuellen und rechtekonform gepflegten Dokumente kann auch die beste Vector-Search-Konfiguration schlechte Ergebnisse liefern.

Für Anwendungsfälle mit stärkerem Vertriebsbezug lohnt sich ein Blick auf unseren Sales Support Agent auf Basis generativer KI. Auch hier ist die Qualität der zugrunde liegenden Daten der limitierende Faktor und nicht die Wahl des Sprachmodells.

Warum Lakehouses die Daten-Architektur der Zukunft sind

In unserem Whitepaper erfahren Sie:

• Wie sich ein Data Lakehouse von anderen Architekturen unterscheidet.
• Wie Sie durch ein Lakehouse KI-Anwendungen schneller umsetzen.
• Wie Sie ihr internes Team befähigen selbstständig KI Projekte zu implementieren.

Jetzt herunterladen

Die häufigsten Fehler beim Context Engineering und wie Sie sie vermeiden

In der Praxis lassen sich die Fehlerbilder von KI-Agenten meist auf vier wiederkehrende Muster zurückführen. Die Begriffe sind in der Branche gebräuchlich, auch wenn sie sich keiner einzelnen Quelle exklusiv zuschreiben lassen.

Fehler 1: Context Poisoning (verunreinigter Kontext)

Der Agent halluziniert einmal eine falsche Information und diese falsche Information landet in seinem eigenen Kontextfenster. Von da an baut er auf seinem eigenen Fehler weiter auf und die Antworten werden mit jeder Interaktion schlechter. Um das zu lösen, sollten Sie dem Agenten Zugriff auf geprüfte Daten und echte Datenbankabfragen geben, anstatt ihn auf sein eigenes, ungeprüftes Gedächtnis zurückgreifen zu lassen.

Fehler 2: Context Distraction (Ablenkung durch zu viel Kontext)

Je länger ein Agent arbeitet, desto voller wird sein Kontextfenster, sodass er ab einem gewissen Punkt beginnt, am bestehenden Kontext weiterzuarbeiten statt neu zu denken. Databricks hat das in einer Studie mit über 2.000 Experimenten an 13 Sprachmodellen untersucht. Die meisten getesteten Modelle verloren mit wachsender Kontextlänge an Genauigkeit und nur wenige Spitzenmodelle blieben über einen weiteren Bereich hinweg stabil. Als Lösung sollten Sie das Kontextfenster aktiv steuern, regelmäßig prüfen, welche Informationen wirklich noch gebraucht werden, und Nicht-Benötigtes komprimieren oder zusammenfassen.

Fehler 3: Context Confusion (Verwirrung durch zu viele Werkzeuge)

Viele Agenten haben heute Zugriff auf einen ganzen Werkzeugkasten. Das ist grundsätzlich sinnvoll, aber wenn zu viele Werkzeug-Beschreibungen gleichzeitig im Kontextfenster liegen, kann es passieren, dass der Agent irgendwann nicht mehr weiß, welches Werkzeug für die aktuelle Aufgabe eigentlich passt und deshalb anfängt, unsinnige Antworten zu generieren. Eine bedarfsgerechte Auswahl, bei der nur die für die jeweilige Aufgabe wirklich relevanten Werkzeuge geladen werden, wie über einen MCP-Server mit schrittweisem Nachladen, schafft hier Abhilfe.

Fehler 4: Context Clash (widersprüchliche Kontextquellen)

Wenn sich unterschiedliche Kontextquellen widersprechen, beispielsweise veraltete Daten aus einem RAG-System gegen einen aktuellen Zustand aus einem MCP-Server oder dem System-Prompt, weiß der Agent nicht, welcher Quelle er folgen soll. In der Anwendung ist das Ergebnis daher meist willkürlich und inkonsistent. Achten Sie deshalb konsequent darauf, dass sich die Datenquellen, die Sie Ihrem Agenten zur Verfügung stellen, nicht widersprechen und räumen Sie veraltete Daten aktiv aus dem System.

Wann reicht Prompt Engineering, wann brauchen Sie RAG oder Context Engineering?

Ein paar Mythen sollten Sie dabei nicht mitnehmen. “Je mehr Kontext, desto besser” stimmt nicht, das zeigt die Context-Rot-Forschung deutlich. “Context Engineering ist nur Prompt Engineering mit neuem Namen” stimmt ebenfalls nicht. Prompt Engineering ist eine Teilmenge und kein Synonym.

“Das lohnt sich nur für Tech-Konzerne mit eigenem KI-Team” trifft ebenfalls nicht zu. Laut Gartner (2026) können Unternehmen, die die Semantik und den Kontext in ihren KI-Daten priorisieren, bis 2027 bis zu 80 Prozent höhere Agenten-Genauigkeit und bis zu 60 Prozent geringere Kosten erreichen, unabhängig von der Größe des Unternehmens.

Fazit

Context Engineering ist kein zusätzlicher Aufwand, den Sie sich sparen können, sondern die Voraussetzung dafür, dass ein KI-Agent im Alltag wirklich funktionieren kann. Die vier Fehlerbilder aus diesem Artikel zeigen, dass ein stärkeres Modell allein das Problem nicht lösen kann, wenn die Datengrundlage und die Steuerung des Kontexts fehlen.

Unsere Empfehlung ist es daher: Wenn Sie aktuell einen KI-Agenten planen oder ein bestehender Agent unzuverlässig arbeitet, prüfen Sie zuerst Ihre Datenbasis, bevor Sie in ein größeres Modell oder zusätzliche Werkzeuge investieren. Wer diesen Schritt jetzt geht, ist in 12 bis 18 Monaten deutlich besser aufgestellt als Wettbewerber, die erst reagieren, wenn ihr Agent bereits Kunden verärgert hat.

Vinzent Wuttke

Geschäftsführer

Ihr nächster Schritt mit uns!

Databricks ist eine der leistungsfähigsten Plattformen für Daten und KI – aber ihr volles Potenzial entfaltet sich erst, wenn Ihr Team sie wirklich beherrscht. Lassen Sie uns gemeinsam schauen, welche Schulungspakete zu Ihrer Ausgangssituation passen.

Im kostenlosen Erstgespräch klären wir:

• Welche Rollen und Teams von welchem Paket am meisten profitieren
• Ob und wie wir Inhalte auf Ihre Datenarchitektur und Use Cases anpassen
• Wie ein realistischer Zeitplan und die nächsten Schritte aussehen

Erstgespräch vereinbaren

Häufig gestellte Fragen zu Context Engineering