Mit gezieltem Context Engineering zu skalierbaren KI-Agenten

Damit verändert sich auch die Art, wie solche Systeme entwickelt werden. Die entscheidende Frage lautet nicht mehr nur: «Wie formulieren wir den richtigen Prompt?» Sondern: «Welchen Kontext, welche Fähigkeiten, Werkzeuge und Rückkopplungen braucht ein Agent, um zuverlässig auf ein Ziel hinzuarbeiten?». Genau hier setzt Context Engineering an.

Context Engineering ist die systematische Gestaltung, Bereitstellung und Steuerung des Kontexts, den ein KI-System für seine Entscheidungen benötigt. Dies geschieht innerhalb der Runtime (Laufzeitumgebung) – jener technischen Infrastruktur und Ausführungsschicht, die es autonomen KI-Agenten ermöglicht, kontinuierlich zu laufen, ihren Zustand zu verwalten, Tools aufzurufen und Aufgaben abzuarbeiten. Es geht also nicht darum, möglichst viel Wissen in ein Kontextfenster zu laden. Es geht darum, dem System im richtigen Moment genau jene Informationen, Regeln, Fähigkeiten und Zustände verfügbar zu machen, die es für den nächsten sinnvollen Schritt benötigt. Aus einem Prompt wird damit ein System und aus einem linearen Workflow ein agentischer Prozess mit Schleifen.

Inhalte

1. Vom Prompt zum System
2. Context Engineering: der richtige Kontext zur richtigen Zeit
3. Was einen produktiven KI-Agenten ausmacht
4. Context Engineering wird technisch
5. Loops machen aus Workflows agentische Systeme
6. Agenten werden kontinuierlich verbessert
7. Fazit

Prompt Engineering war eine der ersten Disziplinen rund um generative KI. Mit klaren Rollenbeschreibungen, guten Instruktionen und Beispielen lässt sich die Qualität eines Modells erheblich beeinflussen.

Für einfache Aufgaben funktioniert das nach wie vor gut. Ein produktiver Agent braucht jedoch mehr: Er muss ein Ziel verstehen, verbindliche Quellen und Regeln berücksichtigen, den aktuellen Prozesszustand kennen, die passenden Skills und Tools einsetzen und entscheiden können, ob er weiterarbeitet, iteriert oder einen Menschen einbezieht.

Ein einzelner System Prompt kann vieles davon enthalten. Je komplexer das System wird, desto schwieriger wird dieser Ansatz jedoch zu warten, zu testen und weiterzuentwickeln. Deshalb verschiebt sich der Fokus: Vom Prompt Engineering zum Context Engineering.

Prompt Engineering optimiert eine konkrete Instruktion. Context Engineering gestaltet das Informations- und Handlungssystem, in dem ein Agent arbeitet.

Ein Sprachmodell verfügt über enormes allgemeines Wissen. Es kennt aber weder die spezifischen Ziele eines Unternehmens noch dessen Kund:innen, Prozesse, Produkte, Markenstandards oder internen Regeln.

Genau hier liegt eine der zentralen Herausforderungen beim produktiven Einsatz von KI: Unternehmen besitzen sehr viel relevantes Wissen, dieses liegt jedoch häufig verteilt in Präsentationen, Websites, Guidelines, Datenbanken, Wikis, Fachapplikationen oder in den Köpfen einzelner Mitarbeitender.

Context Engineering macht dieses Wissen operativ nutzbar. Wichtig ist dabei eine klare Unterscheidung: Knowledge ist nur ein Teil von Context. Kontext umfasst alles, was eine konkrete Entscheidung des Agents beeinflusst: Instruktionen, fachliches Wissen, aktuelle Daten, Policies, Nutzerinput, Tool-Ergebnisse, Zwischenergebnisse, State oder – wo sinnvoll – Memory. Context Engineering ist deshalb mehr als Retrieval oder RAG. Das Wissen beantwortet die Frage, was ein Agent wissen kann. Der Kontext bestimmt, was er in diesem Moment tatsächlich wissen und berücksichtigen soll.

Die Nielsen Norman Group beschreibt diesen Wandel aus UX-Perspektive treffend: Wenn KI zunehmend selbst Artefakte produziert, müssen Research- und Design-Erkenntnisse nicht mehr nur für Menschen dokumentiert, sondern als kuratierter Kontext für KI-Systeme verfügbar gemacht werden.

Vier Ebenen von Kontext

Für die Architektur eines Agentensystems ist es hilfreich, vier Kontextebenen zu unterscheiden. Sie beschreiben, welche Funktion der Kontext im System erfüllt. Die Übersichtsgrafik zeigt ergänzend, aus welchen Quellen die Informationen dafür stammen.

• System Context: umfasst stabile Vorgaben wie Rolle, Ziel, Policies, Brand Guidelines oder Output-Regeln.
• Knowledge Context: wird bei Bedarf aus Dokumenten, Datenbanken, Fachapplikationen, Suchsystemen oder APIs geladen.
• Current State: beschreibt, was in der aktuellen Aufgabe bereits passiert ist: ausgeführte Schritte, Tool-Ergebnisse, Zwischenergebnisse oder offene Fragen.
• Persistent Context: speichert Informationen über einzelne Sessions oder Prozessinstanzen hinaus. Solches Memory kann sinnvoll sein, sollte aber bewusst und sparsam eingesetzt werden.

Der Grundsatz bleibt: Der beste Kontext ist nicht der grösste, sondern der kleinste Kontext, der eine zuverlässige Entscheidung ermöglicht. Zu viel Kontext erhöht Kosten und Latenz und kann relevante Signale in irrelevanten Informationen untergehen lassen.

Ein produktiver KI-Agent ist mehr als ein Sprachmodell. Er verbindet ein Modell mit Kontext, Skills und Tools und orchestriert diese Bausteine entlang eines definierten Ziels.

Die Kontextquellen können dabei sehr unterschiedlich sein: Guidelines und Policies, Dokumente und Daten, angebundene Systeme oder persistentes Memory. Context Engineering entscheidet, welche Informationen daraus für die aktuelle Aufgabe tatsächlich relevant sind.

Innerhalb des Agenten übernimmt das Modell sprachliche und interpretative Aufgaben. Skills kapseln wiederkehrende Fähigkeiten, Tools ermöglichen den Zugriff auf externe Systeme und Daten. Die Orchestrierung verbindet diese Komponenten und steuert, welcher nächste Schritt ausgeführt wird.

Querschnittlich sorgen Guardrails, Evals und Observability dafür, dass das System kontrollierbar und nachvollziehbar bleibt.

Entscheidend ist nicht nur, welche Quellen einem Agenten zur Verfügung stehen, sondern auch ihre Hierarchie, Aktualität und Verbindlichkeit. Ein Agent sollte beispielsweise wissen, welche Quelle bei widersprüchlichen Informationen Vorrang hat und wann zusätzliche Informationen eingeholt werden müssen.

Skills und Tools erfüllen dabei unterschiedliche Aufgaben. Ein Skill beschreibt, wie eine bestimmte Aufgabe gelöst wird – beispielsweise einen Produkttext erstellen, Fakten validieren oder Inhalte klassifizieren. Ein Tool ermöglicht dem Agenten dagegen, mit seiner Umwelt zu interagieren – etwa über Search, APIs, Datenbanken, CMS oder CRM.

Ebenso wichtig ist die Trennung zwischen probabilistischer KI und deterministischer Logik. Kreative, sprachliche oder interpretative Aufgaben können beim Modell liegen. Harte Geschäftsregeln, Berechtigungen und sicherheitskritische Entscheidungen sollten dagegen explizit im System verankert werden. Wenn beispielsweise eine Transaktion ab einem bestimmten Betrag zwingend eine Freigabe benötigt, darf dies keine Interpretation des LLM sein.

Je stärker Agenten handeln dürfen, desto wichtiger werden zudem Identity und Permissions. Ein Agent sollte nur jene Daten sehen und jene Aktionen ausführen können, die für seine Aufgabe erforderlich sind.

Schliesslich braucht ein produktives System Observability. Nur wenn nachvollziehbar ist, welchen Kontext und welche Tools ein Agent verwendet hat, wo Fehler oder Eskalationen entstanden sind und welche Runtime (Laufzeit) oder Kosten angefallen sind, lässt sich das Verhalten zuverlässig betreiben und verbessern.

Context Engineering ist nicht einfach eine neue Bezeichnung für längere Prompts. Sobald Agenten produktiv eingesetzt werden, wird Kontext zu einem technischen Artefakt.

Relativ stabile Regeln, Skills oder Qualitätskriterien können beispielsweise in einem Git-Repository gepflegt werden. Der Vorteil liegt weniger im Dateiformat als im Prinzip dahinter: Kontext wird versionierbar, reviewbar und nachvollziehbar. Änderungen lassen sich kontrolliert ausrollen und mit Evals gegen bestehendes Verhalten testen.

Git ist dabei nur eine mögliche Komponente. Aktuelle Produktdaten gehören meist in Datenbanken oder APIs, Dokumentenwissen kann über Retrieval eingebunden werden und laufende Prozesszustände werden als State verwaltet.

Die eigentliche Architekturfrage lautet deshalb: Welcher Kontext lebt wo, wann wird er geladen und wie wird seine Qualität kontrolliert?

DESIGN.md als aktuelles Beispiel

Google Labs verfolgt genau diese Richtung mit DESIGN.md. Das Format ermöglicht es, Designregeln als agentenfreundliche Markdown-Datei zwischen Stitch und anderen Design- oder Coding-Tools auszutauschen. Google hat die Draft Specification 2026 als Open Source veröffentlicht. Der Gedanke dahinter ist grösser als DESIGN.md selbst. Warum sollte es neben einem Designsystem nicht auch geben:, BRAND.md, CONTENT.md, UX.md, LEGAL.md, PRODUCT.md usw.

Ob diese Informationen tatsächlich in einzelnen Markdown-Dateien, einer Knowledge Base, über Retrieval, Skills oder einen MCP-Server bereitgestellt werden, ist letztlich eine Architekturfrage.

Entscheidend ist die Idee dahinter: Unternehmenswissen wird so strukturiert, dass Menschen und KI-Systeme auf dieselbe verbindliche Grundlage zugreifen können.

Nicht jeder mehrstufige KI-Prozess ist automatisch ein Agent. Ein klassischer Workflow folgt einem weitgehend definierten Ablauf. Ein agentischer Workflow verfügt dagegen über Entscheidungsspielraum: Das System kann auf Basis von Ziel, State und Zwischenergebnis bestimmen, welcher nächste Schritt sinnvoll ist.

Agentisch wird ein Workflow dort, wo das System nicht nur Schritte ausführt, sondern innerhalb definierter Leitplanken über den nächsten Schritt entscheiden kann. Dadurch entsteht ein Execution Loop:

Planen → Handeln → Evaluieren → neu planen oder abschliessen

Ein Content-Agent kann beispielsweise einen ersten Entwurf erstellen, das Ergebnis gegen definierte Kriterien evaluieren und bei Bedarf zusätzlichen Kontext laden, ein anderes Tool verwenden oder einen Teil der Aufgabe erneut bearbeiten. Der Loop ist also nicht einfach ein «nochmals generieren», sondern eine kontrollierte Neubewertung des nächsten Schritts.

Human-in-the-Loop

Nicht jeder Fall sollte vollständig autonom behandelt werden. Bei Unsicherheit, erhöhtem Risiko oder einer definierten Freigabepflicht kann ein Human Review ausgelöst werden. Der Mensch gibt das Ergebnis frei oder liefert Feedback, das zurück in den agentischen Loop fliesst.

Mit steigender Reife kann der Mensch dabei unterschiedlich stark eingebunden sein: regelmässig im Prozess, überwachend oder nur bei definierten Ausnahmefällen.

Der Agent bearbeitet eine Aufgabe und übergibt das Ergebnis an eine Evaluation. Diese kann aus deterministischen Regeln, Evals oder – wo sinnvoll – einem separaten Eval Agent bestehen.

Das anschliessende Quality Gate entscheidet über drei Pfade: Ist die Qualität ausreichend, folgt die Aktion. Werden Kriterien nicht erfüllt, erhält der Agent Feedback und plant den nächsten Schritt neu. Bei Unsicherheit, Risiko oder Freigabepflicht wird ein Mensch eingebunden.

Damit wird sichtbar, was einen agentischen Workflow von einem linearen Ablauf unterscheidet: Das System reagiert auf Zwischenergebnisse und bestimmt daraus den nächsten Schritt.

Produktive Agenten sind nach dem ersten Setup nicht fertig. Kalibrierung, Evaluation und Beobachtung sind deshalb zentrale Bestandteile der Entwicklung.

Evals spielen dabei eine besondere Rolle. Sie sind für Agentensysteme in vieler Hinsicht das, was Tests für klassische Software sind: Sie prüfen beispielsweise, ob ein Agent das richtige Tool wählt, verbindliche Quellen nutzt, Policies einhält oder bei Unsicherheit korrekt eskaliert. So lassen sich nicht nur einzelne Ergebnisse bewerten, sondern auch Regressionen nach Änderungen an Kontext, Skills oder Tools erkennen.

Fehler werden dadurch zum Input für die Weiterentwicklung des Systems. Wenn ein Agent wiederholt eine Information falsch interpretiert, kann die Ursache in einer unklaren Quelle, schlechtem Retrieval, einer fehlenden Regel, einem unpassenden Skill oder einer falschen Business Logic liegen.

So entsteht ein kontinuierlicher Zyklus:

Beobachten → verstehen → System anpassen → testen → deployen → erneut beobachten.

Das Modell selbst wird dabei nicht zwingend verändert. Die Verbesserung findet häufig auf Systemebene statt – durch besseren Kontext, präzisere Skills, robustere Tools, klarere Regeln und zusätzliche Evals.

Ein systematischer Context-Engineering-Ansatz macht KI-Systeme vor allem steuerbarer, nachvollziehbarer und skalierbarer. Wissen, Regeln und Fähigkeiten bleiben nicht in einzelnen Prompts verborgen, sondern werden als eigenständige Bestandteile des Systems gepflegt und über verschiedene Agenten und Anwendungsfälle hinweg wiederverwendbar.

Gleichzeitig lässt sich aktuelles Wissen gezielt zur Runtim (Laufzeit) einbinden, während State, Berechtigungen und deterministische Geschäftsregeln explizit kontrolliert werden. Evals und Observability schaffen die notwendige Transparenz, um Verhalten zu testen, Fehler nachzuvollziehen und das System kontinuierlich weiterzuentwickeln. Menschen werden dabei nicht pauschal aus dem Prozess entfernt, sondern gezielt dort eingebunden, wo ihre Beurteilung oder Verantwortung relevant bleibt.

Vor allem aber trennt dieser Ansatz die eigentliche Unternehmenslogik vom verwendeten Sprachmodell. Foundation Models entwickeln sich rasant weiter und werden in vielen Anwendungsszenarien austauschbarer. Das spezifische Wissen eines Unternehmens, seine Prozesse, Qualitätsstandards und Entscheidungslogiken sind dagegen einzigartig.

Der strategische Wert liegt deshalb zunehmend weniger im einzelnen Modell. Er liegt in der Fähigkeit eines Unternehmens, Kontext, Fähigkeiten, Systeme und Feedback-Loops zu einer belastbaren operativen Architektur zu verbinden.

Wir bewegen uns von Software, die einzelne Funktionen bereitstellt, zu Systemen, die Ziele verstehen und innerhalb definierter Leitplanken selbständig nach dem besten nächsten Schritt suchen. Damit verändert sich auch die Entwicklungsarbeit. Es reicht nicht mehr, einzelne Prompts zu optimieren. Entscheidend ist, Kontext gezielt verfügbar zu machen, Fähigkeiten modular aufzubauen, Systeme und Daten anzubinden und das Verhalten des Gesamtsystems mit Evals, Observability und Feedback-Loops kontinuierlich weiterzuentwickeln.

Prompt Engineering bleibt ein Bestandteil davon, verliert aber seine Rolle als zentrales Gestaltungselement. Der entscheidende Schritt ist grösser: vom Prompt zum Kontext, vom Modell zum Agenten und vom linearen Workflow zum adaptiven, agentischen System. Unternehmen, die diese Architektur heute aufbauen, schaffen nicht einfach bessere KI-Anwendungen. Sie schaffen eine neue operative Grundlage dafür, wie Menschen und KI künftig gemeinsam arbeiten. Mehr über die KI-Adoption von Unternehmen erfährst du in unserem Beitrag «Vom Pilot zum produktiven Betrieb in Organisationen».