28. April 2026

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

Warum nicht das Modell entscheidet, ob ein KI-Agent liefert, sondern die Infrastruktur drumherum.

Werner Graser · CTO & Co-Founder, getVIA GmbH · April 2026

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.

Das Problem liegt nicht im Modell. Es liegt in der Umgebung, in der das Modell läuft. Diese Umgebung — die Orchestrierungsinfrastruktur drumherum — heißt Harness. Und sie ist der entscheidende 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-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 — aber kein tragfähiges Fundament für produktive Systeme.

Stufe 2 — Context Engineering (2024-2025)

Mit Retrieval-Augmented Generation (RAG), Wissensdatenbanken und längeren Kontextfenstern verschob sich der Fokus. Nicht mehr der Prompt allein zählte, sondern der gesamte Kontext: Systemnachricht, Vorgeschichte, abgerufene Dokumente, Tool-Definitionen, User-Profil.

Context Engineering brachte massive Qualitätssprünge. Aber es löste das eigentliche Problem nicht: Wenn ein Agent einen Fehler macht, 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 geht einen Schritt weiter. Sie 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 und seit 2026 in der KI-Forschung aktiv, 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. Nicht hoffen, dass der Agent vorsichtiger wird. Sondern 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. Es geht nicht um einzelne Tricks, sondern um vier zusammenwirkende Komponenten.

Komponente 1 — Context-Firewall: MASTER + 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: Constraint Guard

Constraints in einem Prompt sind ein Wunsch. „Bitte verwende keine Icons aus Material Design Icons" wird vom Modell mal befolgt, mal nicht. Ein Constraint Guard hingegen ist Code: Ein Pre-Commit-Hook, der jede Änderung gegen eine Regel-Liste prüft, bevor sie überhaupt 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 wird in einer durchsuchbaren Wissensbasis abgelegt und 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 er die Erinnerung daran von einem System bekommt, nicht von sich selbst.

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 (das ist der Mensch — der Nutzer). Der Architekt plant und koordiniert (das ist der hochwertige Steuerungsagent). Die Baumeister sind die Spezialisten für Backend, Frontend, Infrastruktur, Wissensbasen — günstigere Modelle, die gegen klar abgesteckte Aufgaben arbeiten.

Diese Trennung erlaubt das wirtschaftliche 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 klingt aufwendig. Es ist es auch. Aber 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 das Modell sich auf das Wesentliche konzentriert: nicht auf das Sortieren irrelevanter Kontextfetzen, sondern auf die eigentliche Aufgabe. Ein fokussierter Agent ist ein präziser Agent.

Die Lehre aus 179 Halluzinationen

Harness Engineering klingt theoretisch. Wir haben es 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 an sich nicht „dümmer" als andere. Er hatte nur die falsche Umgebung: zu viel Kontext, zu wenig Constraints, kein Lerngedächtnis.

Die Lösung war nicht, einen besseren Prompt zu schreiben. Die Lösung war, den Harness so umzubauen, dass jeder spezifische Fehlertyp mechanisch verhindert wurde. Heute schreibt derselbe Agent — mit demselben Modell — kreative Inhalte mit messbar niedrigerer Halluzinationsrate. Nicht weil er mehr „weiß", sondern weil sein Käfig besser gebaut ist.

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: Das Modell ist nicht 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 reduziert nicht nur Kosten — es ist auch der wirksamste Schutz vor Halluzinationen. Für regulierte Branchen wie Versicherung, Finanzen oder Medizin ist das keine Komfortfunktion. Es ist Voraussetzung.

Drittens: Ein gut gebauter Harness ist kein Black-Box-Vendor-Lock-in. Die vier Komponenten — Context-Firewall, Constraint Guard, Error Learning, 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

Wir leben am Ende der Modell-Ära und am Anfang der Harness-Ära. Wer 2026 in produktive KI investiert, investiert nicht in das nächste Foundation Model — sondern 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 nicht an einem einzelnen LLM-Anbieter klammert.

Die Modelle werden weiter besser. Aber die Differenzierung passiert ab jetzt eine Ebene tiefer — im Harness.

Weiterlesen

Warum einfache Vektorsuche nicht reicht — und wie Hybrid Search KI-Halluzinationen verhindert
LLM Halluzinationen: 13 Forschungsansätze im Vergleich

Quellen

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