Das Harness verändert nicht nur, was ein Agent kann

Vereinfacht gedacht übernimmt das Harness einen Teil der Laufzeitlogik zwischen Agent, Modell, Kontext und Tools. Je nach Harness stehen unterschiedliche Möglichkeiten für Reasoning, Planung, Tool-Nutzung und Orchestrierung zur Verfügung. Und damit verändert sich nicht nur die Frage „Was kann mein Agent?“, sondern auch: „Wie viel Aufwand verursache ich damit eigentlich?“ Gerade bei komplexeren agentischen Szenarien können Modellnutzung, Knowledge, Tools, MCP, Workflows und weitere Verarbeitungsschritte Consumption verursachen. Das klingt zunächst nach einem Lizenz- oder Kostenproblem. Für mich ist es aber vor allem ein Use-Case-Design-Problem.

Mehr Capability ist nicht automatisch die bessere Architektur. Wenn eine Aufgabe zuverlässig mit einem einfacheren Agent Design funktioniert, brauche ich möglicherweise weder maximale Reasoning-Tiefe noch eine besonders komplexe Orchestrierung. Und genau hier verändert sich meiner Meinung nach gerade die Arbeit mit Agents: Wir müssen nicht mehr nur entscheiden, ob wir einen Use Case automatisieren können. Wir müssen bewusster entscheiden, wie viel Agentic Work dieser Use Case tatsächlich rechtfertigt. Das sehe ich übrigens nicht nur in Copilot Studio — auch Cowork macht mit unterschiedlichen Effort Levels deutlicher sichtbar, dass komplexeres Reasoning und mehr Autonomie einen Preis haben. Das Thema landet deshalb ziemlich sicher noch ausführlicher in meinem Field Lab: Ich möchte unterschiedliche Agent Designs bewusst gegeneinander testen. Wie verändert sich das Ergebnis, wenn wir denselben Use Case Lean, Expected oder High aufbauen? Das dürfte spannend werden.