
Agent Harness als Kategorie: Warum der Harness das neue Produkt ist
TL;DR: „Ein Agent Harness ist die Laufzeitschicht über dem Modell: Skill-Loading, Subagent-Orchestrierung, Sandbox-Isolation, Memory, Channel-Routing, Artefakt-Übergabe. 2026 hat sich Harness als eigene Produktkategorie etabliert — und entscheidet stärker über Outcomes als die Modellwahl."
— Till FreitagDas Modell ist nicht mehr das Produkt
Zwei Jahre lang war die spannende Frage: Welches Modell? MMLU-Score, Kontextfenster, Reasoning-Loop. Diese Diskussion ist 2026 weitgehend abgeschlossen. Die Top-Modelle sind in 80% der Aufgaben austauschbar geworden — und die Performance-Lücke zwischen erstem und drittem Platz ist kleiner als die Lücke zwischen gleichem Modell in gutem Harness und gleichem Modell in schlechtem Harness.
Das verschiebt das Produkt eine Schicht nach oben.
Was ist ein Agent Harness?
Ein Harness ist die Laufzeit- und Orchestrierungsschicht, die aus einem Modell einen brauchbaren Agenten macht. Sechs Bestandteile tauchen in jedem ernsthaften Harness auf:
- Skill-Loading — progressives Laden von Werkzeugen, Prompt-Fragmenten und Domänenwissen je nach Task. Anthropic hat das mit Agent Skills als Standard etabliert.
- Subagent-Orchestrierung — der Haupt-Agent delegiert an spezialisierte Subagents, die parallel oder seriell laufen.
- Sandbox-Isolation — Code-Execution, Browser, File-I/O finden in isolierten Containern statt, nicht im Haupt-Kontext.
- Memory — persistenter Zustand über Turns hinweg: Vektorstore, Episodic Memory, Working Memory.
- Channel-Routing — der Agent kommuniziert über mehrere Kanäle gleichzeitig (Chat, Status, Artefakt-Stream, Tool-Calls).
- Artefakt-Übergabe — am Ende kommt etwas Fertiges raus: ein PR, ein Deck, ein Report, eine Site, ein Video. Nicht nur Text.
Wenn eines dieser Sechs fehlt, ist es kein Harness — es ist ein Chatbot mit Tools.
Warum Harness als eigene Kategorie
Drei Gründe haben Harness 2026 zur eigenen Produktkategorie gemacht:
1. Modell-Commoditisierung. Wenn GPT, Claude, Gemini und GLM auf 90% der Tasks gleichauf liegen, kannst du dich nicht mehr über das Modell differenzieren. Du differenzierst dich über was du um das Modell herum baust.
2. Skills sind portierbar. Agent Skills haben sich als Industriestandard durchgesetzt — ein Skill, der für Claude Code geschrieben wurde, läuft mit minimalen Anpassungen in DeerFlow oder Antigravity. Damit wird der Harness zur austauschbaren Schicht, nicht der Skill.
3. Sandbox-Kosten sind nicht trivial. Wer Code im Browser eines Agenten ausführt, braucht echte Isolation. Das ist Infrastrukturarbeit, die einzelne Teams nicht selbst stemmen wollen.
Die Landschaft, Stand Juni 2026
Vier Cluster lassen sich klar trennen:
Cluster 1: Coding-Harnesses
Claude Code, Cursor Agents, Aider, OpenHands. Optimiert für Repository-Arbeit. Lange Kontextfenster, starke Diff-Generierung, Git-Integration. Subagents sind hier meist Task-Splitter (Plan → Implement → Test → Review). Sandbox ist der Dev-Container.
→ Mehr dazu: Die Agentic Coding Tools Landschaft
Cluster 2: Super-Agent-Harnesses
DeerFlow 2.0, Manus, AutoGen Studio. Generalisten. Eingabe ist ein Prompt, Ausgabe ist ein Artefakt (Report, Slides, Site, Video). Sub-Agents sind hier echte Spezialisten — Researcher, Writer, Reviewer, Designer. Memory ist persistent über Sessions hinweg.
→ Tiefendive: DeerFlow 2.0 — der Super-Agent-Harness
Cluster 3: Build-Harnesses
Lovable Subagents, Antigravity, Bolt, v0. Output ist deploybare Software. Harness verwaltet Projektstruktur, Branches, Preview-Deployments. Subagents übernehmen UI, Backend, Tests, Migrations parallel.
→ Vergleich: Antigravity in der Praxis
Cluster 4: Agent-Runtimes (Bring-your-own-Harness)
LangGraph, CrewAI, AutoGen, LlamaIndex Agents. Frameworks, mit denen du deinen eigenen Harness baust. Volle Kontrolle, dafür auch volle Verantwortung für Sandbox, Memory, Channel-Routing.
→ Einordnung: Agent-Runtimes im Vergleich
Was du als Builder daraus mitnimmst
Wähle nicht das Modell zuerst. Wähle den Harness, der zu deinem Output passt (Code? Artefakt? Software? Eigenbau?). Das Modell ist ein Steckplatz im Harness — austauschbar.
Investiere in Skills, nicht in Prompts. Skills sind portabel zwischen Harnesses, Prompts sind es nicht. Jede Stunde, die du in einen wiederverwendbaren Skill steckst, zahlt sich über mehrere Harness-Migrationen aus.
Behandle den Harness wie Infrastruktur. Du wirst ihn in 12 Monaten wechseln — entweder weil ein besserer kommt oder weil deine Anforderungen wachsen. Schreib deine Skills, Memory-Schemata und Artefakt-Formate so, dass der Wechsel teuer-aber-machbar bleibt.
Was als nächstes kommt
Drei Verschiebungen zeichnen sich für H2 2026 ab:
- Harness-Marktplätze. Wenn Skills portabel sind, werden Skill-Marktplätze die nächste Welle — ähnlich wie npm es für JavaScript war. Anthropic, ByteDance und ein paar Startups bauen daran.
- Lokale Harnesses. Mit GLM-5.2 und Kimi K2.7 auf Workstation-GPUs werden lokale Harnesses relevant — besonders für regulierte Branchen. Siehe Local AI killt SaaS-Wrapper.
- Harness-as-Service. Anthropic Skills + Sandbox + Memory als gemanagter Stack. Reduziert die Build-vs-Buy-Frage auf: Welcher Harness-Vendor?
Fazit
Harness ist 2026 das, was Frameworks 2014 für Web waren: die Schicht, die entscheidet, wie schnell du baust und wie weit du kommst. Wer die Kategorie ignoriert und weiter über Modelle diskutiert, optimiert eine Variable, die kaum noch Spread hat.
Das Modell wählt heute der Harness aus. Nicht umgekehrt.









