Von Prompt Engineering zu Harness Engineering: die dritte Stufe der KI-Entwicklung

Wer 2026 einen produktiven KI-Agenten betreibt, sei es für Kundensupport, Vertrieb oder interne Prozesse, kennt das Phänomen: Das Modell ist nicht das Problem. GPT-5.5, Claude Opus 4.7, Mistral Large 3 oder Gemini 3.1 sind in synthetischen Benchmarks kaum mehr unterscheidbar. Trotzdem scheitern Agenten in der Praxis. Sie halluzinieren. Sie verlieren den Kontext. Sie machen denselben Fehler immer wieder. Sie verbrennen Tokens.

Die Ursache liegt in der Umgebung, in der das Modell läuft. Diese Umgebung, die Orchestrierungsinfrastruktur rundherum, heißt Harness. Sie ist der wichtigste Hebel der nächsten KI-Generation.

Drei Evolutionsstufen: eine kurze Geschichte

Die Entwicklung produktiver LLM-Anwendungen lässt sich in drei klare Stufen unterteilen.

Stufe 1: Prompt Engineering (2022 bis 2023)

Der erste Hype nach dem ChatGPT-Launch. Die Annahme: Ein guter Prompt ist alles. „Du bist ein Experte für …“, „Antworte schrittweise …“, „Nimm folgende Rolle an …“. Es entstanden ganze Kurse, Bücher und Berufsbezeichnungen rund um die Kunst, einem Modell die richtige Frage zu stellen.

Das Problem: Prompts skalieren nicht. Was bei einer einzelnen Anfrage funktioniert, bricht zusammen, sobald mehrere Tools, Datenquellen oder Sessions ins Spiel kommen. Prompt Engineering war eine notwendige erste Lektion. Als Fundament für produktive Systeme trägt es nicht.

Stufe 2: Context Engineering (2024 bis 2025)

Mit Retrieval-Augmented Generation (RAG), Wissensdatenbanken und längeren Kontextfenstern verschob sich der Fokus auf den gesamten Kontext: Systemnachricht, Vorgeschichte, abgerufene Dokumente, Tool-Definitionen, User-Profil.

Context Engineering brachte massive Qualitätssprünge. Das eigentliche Problem blieb: Macht ein Agent einen Fehler, macht er ihn beim nächsten Mal wieder. Es gibt keine Lernschleife. Jede Session beginnt bei null. Bei Multi-Agent-Workflows multiplizieren sich die Fehler und die Tokenkosten.

Stufe 3: Harness Engineering (2026)

Die dritte Stufe verschiebt den Fokus von „Was sage ich dem Modell?“ zu „Wie baue ich die Umgebung, in der das Modell arbeitet?“

Mitchell Hashimoto, Mitgründer von HashiCorp, hat das Prinzip auf den Punkt gebracht:

„Jedes Mal, wenn ein Agent einen Fehler macht, engineere die Umgebung so, dass er diesen spezifischen Fehler nie wieder machen kann.“

Das ist Harness Engineering: den Käfig so bauen, dass der Fehler mechanisch unmöglich wird.

Was Harness Engineering konkret bedeutet

Ein Harness ist die Gesamtheit aller Strukturen, die einem KI-Agenten beim Arbeiten Halt geben und ihn vor Fehlern schützen. Vier Komponenten wirken dabei zusammen.

Komponente 1: Context-Firewall mit MASTER und SCOPE

Klassische Setups laden alle verfügbaren Dokumente in den Kontext jedes Agenten. Das verbrennt Tokens und verwässert die Aufmerksamkeit des Modells. Ein Harness trennt scharf zwischen einem MASTER-Dokument (gilt für alle Agenten: Werte, Constraints, Kommunikationsregeln) und SCOPE-Stubs (gelten nur für den jeweiligen Spezialagenten: Backend, Frontend, Infrastruktur).

In der Praxis heißt das: Ein Backend-Agent sieht nur Datenbankschemas und API-Routen. Ein Frontend-Agent sieht nur Komponenten und Stylesheets. Beide teilen sich denselben MASTER für übergeordnete Regeln. Das spart in unseren Messungen rund 60 Prozent Tokens pro Agentenaufruf.

Komponente 2: Mechanische Durchsetzung mit dem Constraint Guard

Constraints in einem Prompt sind ein Wunsch. „Bitte verwende keine Icons aus Material Design Icons“ befolgt das Modell mal, mal nicht. Ein Constraint Guard ist Code: ein Pre-Commit-Hook, der jede Änderung gegen eine Regel-Liste prüft, bevor sie das Repository erreicht.

Bei getVIA enthält unser Constraint Guard derzeit über 30 Regeln, von „Niemals tenant_id in WHERE-Klauseln vergessen“ bis „Kein hardcodierter Preis im Frontend, immer aus der Datenbank ziehen“. Verstöße werden mechanisch geblockt. Das Modell kann den Fehler nicht mehr machen, weil die Umgebung ihn unmöglich macht.

Komponente 3: Externalisiertes Fehler-Gedächtnis

Ein Agent hat kein persistentes Gedächtnis über Sessions hinweg. Was er heute lernt, weiß er morgen nicht mehr. Ein Error Learning System löst das durch Externalisierung: Jeder dokumentierte Fehler landet in einer durchsuchbaren Wissensbasis und wird bei jedem neuen Auftrag in den Kontext gezogen, kategorisiert nach Domäne (Security, Frontend, Billing, AI System).

In unserem System sind aktuell 186 dokumentierte Lessons in 17 Kategorien aktiv. Bei jeder neuen Aufgabe weiß der Agent, welche Fallen seine Vorgänger gestellt haben. Er macht denselben Fehler nicht zweimal, weil ein System ihn daran erinnert.

Komponente 4: Rollenbasierte Orchestrierung

Multi-Agent-Setups scheitern oft an unklaren Verantwortlichkeiten. Wer entscheidet? Wer führt aus? Wer kontrolliert? Ohne klare Rollen kommunizieren Agenten endlos miteinander, ohne Fortschritt.

Wir nutzen ein dreistufiges Rollenmodell. Der Bauherr definiert die Vision: der Mensch, also der Nutzer. Der Architekt plant und koordiniert: der hochwertige Steuerungsagent. Die Baumeister sind die Spezialisten für Backend, Frontend, Infrastruktur und Wissensbasen: günstigere Modelle, die gegen klar abgesteckte Aufgaben arbeiten.

Diese Trennung erlaubt wirtschaftliches Routing: ein Premium-Modell für die Planung, kostengünstige Modelle für die Ausführung. Der Effekt ist messbar.

Was es bringt: die Zahlen

Harness Engineering ist aufwendig. Der Return ist erheblich.

In unseren internen Messungen kostet ein naiver Multi-Agent-Workflow ohne Harness rund 54 Euro pro Monat an LLM-Tokens, bei moderater Auslastung. Mit allen vier Harness-Komponenten sind es 18 Euro. Das sind 67 Prozent Einsparung.

Kombiniert mit Single-Call-Optimierungen wie Prompt-Caching, Batching und Modell-Routing erreichen wir Gesamteinsparungen zwischen 80 und 90 Prozent gegenüber einer ungetunten Referenzarchitektur, bei gleichzeitig höherer Antwortqualität.

Höhere Qualität, weil sich das Modell auf die eigentliche Aufgabe konzentriert und keine irrelevanten Kontextfetzen sortieren muss. Ein fokussierter Agent ist ein präziser Agent.

Die Lehre aus 179 Halluzinationen

Wir haben Harness Engineering gelernt, weil wir es lernen mussten.

Bei einem unserer ersten Versuche, mehrere KI-Agenten parallel an technischer Dokumentation arbeiten zu lassen, dokumentierten wir innerhalb weniger Wochen 179 Halluzinationen, von erfundenen API-Endpoints bis zu ausgedachten Konfigurationsoptionen. Der Agent war nicht „dümmer“ als andere. Er hatte die falsche Umgebung: zu viel Kontext, zu wenig Constraints, kein Lerngedächtnis.

Die Lösung war ein umgebauter Harness, der jeden spezifischen Fehlertyp mechanisch verhindert. Heute schreibt derselbe Agent mit demselben Modell kreative Inhalte mit messbar niedrigerer Halluzinationsrate. Er weiß nicht mehr als vorher. Sein Käfig ist besser gebaut.

Was das für österreichische Unternehmen bedeutet

Wer in Österreich oder der DACH-Region einen produktiven KI-Agenten plant, sollte drei Dinge im Hinterkopf behalten.

Erstens: Der Harness ist das Differenzierungsmerkmal. Mistral Large 3, Claude Opus 4.7 und GPT-5.5 sind in der Anwendung nahezu austauschbar. Wer auf das richtige Modell wartet, wartet falsch. Wer den richtigen Harness baut, gewinnt.

Zweitens: Harness Engineering senkt Kosten und ist zugleich der wirksamste Schutz vor Halluzinationen. Für regulierte Branchen wie Versicherung, Finanzen oder Medizin ist das Voraussetzung.

Drittens: Ein gut gebauter Harness bindet Dich an keinen Anbieter. Die vier Komponenten Context-Firewall, Constraint Guard, Error Learning und Rollenmodell sind architektonische Prinzipien. Sie funktionieren mit jedem ausreichend fähigen Modell und jedem Provider. Wer EU-souverän bleiben will, kann Mistral oder Claude wählen, ohne den Harness umbauen zu müssen.

Fazit

Die Modell-Ära geht zu Ende, die Harness-Ära beginnt. Wer 2026 in produktive KI investiert, investiert in die Infrastruktur, die ein Modell zuverlässig macht.

Bei getVIA setzen wir Harness Engineering seit über einem Jahr produktiv ein. Multi-Channel-Kundenkommunikation über Telefon, WhatsApp und E-Mail, mit fünf koordinierten Spezialagenten, einem Constraint Guard mit über 30 Regeln, einem Error Learning System mit 186 dokumentierten Lessons und einer strikten Trennung zwischen MASTER und SCOPE.

Das Ergebnis: messbare Antwortqualität, kalkulierbare Kosten und eine Plattform, die sich an keinen einzelnen LLM-Anbieter klammert.

Die Modelle werden weiter besser. Die Differenzierung passiert ab jetzt eine Ebene tiefer: im Harness.

Weiterlesen

Hybrid Search gegen KI-Halluzinationen: warum einfache Vektorsuche nicht reicht
LLM Halluzinationen: 13 Forschungsansätze im Vergleich

Quellen

• Hashimoto, M. (2026). Harness Engineering. mitchellh.com
• OpenAI (2026). Harness engineering: leveraging Codex. openai.com
• LangChain (2026). The Anatomy of an Agent Harness. blog.langchain.com
• Fowler, M. (2026). Harness Engineering. martinfowler.com

Zitiervorschlag: Graser, W. (2026). Von Prompt Engineering zu Harness Engineering: Multi-Agent-Orchestrierung in europäischen SaaS-Plattformen. getVIA Technical Report TR-2026-03.

Harness Engineering live erleben: Wir betreiben unsere Multi-Agent-Architektur produktiv. Wenn Du wissen willst, wie das für Deinen Use Case aussieht, buche eine 30-Minuten-Demo.

Werner Graser, Inhaber von ylem e.U. und Entwickler von getVIA, macht Unternehmenswissen für KI-gestützte Kundenkommunikation nutzbar. Mehr über Werner Graser und KI-Wissensmanagement bei getVIA.