Context Engineering: warum API-Zugriff allein keinen guten Agenten macht
Du verbindest deinen KI-Agenten mit dem Google-Ads-Konto. Der API-Key sitzt, die Verbindung steht. Trotzdem liefert der Agent Unsinn: falsche Zahlen, erfundene Kampagnennamen. Das liegt selten am Modell. Es liegt daran, wie die Werkzeuge und ihr Kontext gebaut sind.
Für dieses Problem gibt es einen Namen: Context Engineering. Der Begriff beschreibt, welche Informationen wann im Kontextfenster eines Sprachmodells landen.
Was ist Context Engineering?
Context Engineering bezeichnet die Strategien, mit denen ein System einem Sprachmodell die passenden Informationen liefert. So beschreibt es Anthropic in seinem Engineering-Blog (2025). Gemeint ist alles, was im Kontextfenster landet: Anweisungen, Antworten von Werkzeugen, der bisherige Verlauf.
Das Kontextfenster ist begrenzt. Jedes zusätzliche Token zehrt an einem knappen Budget an Aufmerksamkeit. Was hineinkommt, muss also zählen.
Der Begriff stammt aus dem Sommer 2025. Shopify-CEO Tobi Lütke prägte ihn, Andrej Karpathy machte ihn populär. Karpathy zog eine klare Grenze zum älteren Prompt Engineering:
Context Engineering ist die feine Kunst und Wissenschaft, das Kontextfenster mit genau den richtigen Informationen für den nächsten Schritt zu füllen.
Ein Prompt ist die kurze Anweisung, die du tippst. Context Engineering ist alles drumherum, das über Erfolg oder Murks entscheidet. Context Engineering im Online-Marketing heißt: Der Agent bekommt deine Kampagnen-, Analytics- und Content-Daten so aufbereitet, dass er damit arbeiten kann.
Das Missverständnis: API-Key rein, Agent fertig
Die verbreitete Annahme geht so: Sprachmodell an die API hängen, Zugang freischalten, fertig. Der Agent könne den Rest. Zugang ist aber nur die Voraussetzung, nicht die Lösung.
Der Zugang selbst ist heute einfach. Ein MCP-Server verbindet den Agenten mit deinen Marketing-Konten. Was danach passiert, entscheidet über die Qualität.
Denn eine API antwortet nicht für Menschen. Sie antwortet für andere Software.
Was eine rohe API-Antwort für ein Modell bedeutet
Ein Beispiel aus der Google-Ads-API. Du willst wissen, was eine Kampagne gestern gekostet hat. Die rohe Antwort sieht ungefähr so aus:
cost_micros: 47230000
campaign.resource_name: "customers/1234567890/campaigns/22334455"
campaign.status: 2Drei Fallen stecken hier drin. Kosten kommen in Micros: Die Google-Ads-API rechnet jeden Betrag mal 1.000.000. 47230000 bedeutet also 47,23 €. Der Kampagnenname fehlt, es gibt nur eine ID. Und der Status 2 heißt „aktiviert", aber das steht nirgends.
Ein Sprachmodell muss das alles selbst deuten. Es rät, ob 47230000 Cent, Euro oder Micros sind. Es hat keinen Namen für die Kampagne. Jeder dieser Schritte ist eine Fehlerquelle.
Und das war nur eine Kampagne. Eine echte Abfrage liefert Dutzende Felder pro Zeile. Ungefiltert überflutet das jedes Kontextfenster.
Anthropic bringt es auf den Punkt: Werkzeuge sollten nur Informationen mit hohem Signalwert zurückgeben. Technische Kürzel wie interne IDs verwirren das Modell mehr, als sie helfen.
Ein gut gebautes Werkzeug liefert stattdessen: „Kampagne Sommer-Sale, 47,23 € Kosten, 3 Conversions." Dieselben Daten, aber lesbar. Das Modell muss nichts mehr raten. Wer auf Basis falsch gedeuteter Zahlen optimiert, verbrennt schnell Budget.
Die vier Ebenen von gutem Context Engineering
Gutes Context Engineering arbeitet auf vier Ebenen. Jede reduziert, was das Modell selbst deuten muss. Zusammen machen sie aus rohem Zugang ein verlässliches Werkzeug.
Defaults
Ein Werkzeug braucht sinnvolle Voreinstellungen. Fragt der Agent nach Kampagnen, sollte er nicht 500 Zeilen zurückbekommen. Ein guter Default liefert die letzten 30 Tage, sortiert nach Kosten. Anthropic empfiehlt genau solche vernünftigen Standardwerte.
Beschreibungen
Das Modell wählt Werkzeuge anhand ihrer Beschreibung. Steht dort „holt Daten", rät es. Steht dort „holt Kosten und Conversions je Kampagne für einen Zeitraum", trifft es. Anthropic betont: Schon kleine Verbesserungen an Beschreibungen bringen große Sprünge.
Guardrails
Manche Aktionen ändern etwas: Budgets, Anzeigen, veröffentlichte Texte. Solche Werkzeuge brauchen Grenzen. Eine Freigabe vor dem Schreiben, ein Limit für Ausgaben, ein Protokoll jeder Aktion. Ohne Guardrails wird ein hilfreicher Agent zum Risiko. Ein Agent, der ungefragt Budgets verschiebt, kostet mehr, als er spart.
Interpretation
Die letzte Ebene verbindet Quellen. Eine Zahl aus Google Ads sagt allein wenig. Erst neben GA4, Search Console und Clarity ergibt sie ein Bild. Wie dieser Kontext aus mehreren Quellen entsteht, ist eine eigene Aufgabe. Gutes Context Engineering reicht Daten nicht bloß durch. Es setzt sie in Beziehung.
Warum Context Engineering Wartung heißt
Ein Connector ist nie fertig, denn APIs ändern sich ständig. Google Ads veröffentlicht mehrmals im Jahr eine neue API-Version und schaltet alte ab. Meta, LinkedIn und GA4 machen es genauso.
Jede Änderung kann eine Antwort umbauen. Ein Feld heißt anders, ein Wert kommt in neuer Einheit. Läuft der Connector ungepflegt weiter, bricht er still. Das Tückische: Niemand bemerkt es sofort. Der Agent liefert dann wieder Zahlen ohne Bedeutung.
Genau hier trennt sich Werkzeug von Spielerei. Ein API-Key ist in Minuten gesteckt. Die Aufbereitung dahinter ist laufende Arbeit: Defaults, Beschreibungen, Guardrails, Interpretation. Wer selbst baut, übernimmt diese Wartung für jede Quelle. Ein gepflegter Connector nimmt sie ab.
Der Unterschied zwischen Spielerei und Werkzeug liegt selten im Modell. Er liegt im Context Engineering. Für Context Engineering im Online-Marketing heißt das: Erst die Aufbereitung macht aus rohem Zugang eine verlässliche Datenbasis.
Der Honeyfield Marketing MCP ist genau so ein gepflegter Connector. Über 200 Werkzeuge für 11 Marketing-Quellen, mit aufbereiteten Antworten, Freigaben vor Schreibaktionen und EU-Hosting. Wenn dein Agent verlässlich arbeiten soll, lohnt der Blick auf marketing-mcp.honeyfield.at.