„Wir bauen da gerade einen Agenten mit einem Harness, und das Scaffold ziehen wir über MCP rein.“
Woher der ganze Wortschwall kommt
Wenn ein Satz wie dieser im Meeting fällt und die halbe Runde nickt, während du innerlich aussteigst: willkommen im Club. Diese Begriffe stammen fast alle aus der Entwickler- und KI-Welt, und sie sind in den letzten zwei, drei Jahren regelrecht explodiert. Jede Woche kommt ein neues Wort dazu, oft aus englischsprachigen Blogposts, Framework-Dokumentationen oder Konferenz-Talks – und meistens ohne saubere Definition.
Das ist kein Zufall und auch kein Versagen auf deiner Seite. Die Begriffe sind entstanden, während die Technik gebaut wurde. Es gab keine Kommission, die sie sauber sortiert hat. Deshalb bedeuten dieselben Wörter je nach Sprecher etwas anderes, und deshalb ist es für Product Owner, Scrum Master oder Management völlig normal, hier den Faden zu verlieren.
Die gute Nachricht: Du musst nicht jedes Detail programmieren können. Du brauchst eine Landkarte. Und genau die kommt jetzt – vom simplen Prompt bis zum abgesicherten Agenten, der eine echte Aufgabe erledigt.
Die eine Frage, die alles ordnet
Bevor wir Begriffe stapeln, hier der Kompass, der durch alles führt: Wer steuert eigentlich den Ablauf – der Mensch oder das Modell?
Je weiter unten in unserer Landkarte, desto mehr bestimmt der Mensch, was als Nächstes passiert. Je weiter oben, desto mehr entscheidet das Modell selbst. Autonomie steigt, Vorhersagbarkeit sinkt. Diese eine Frage genügt, um fast jeden Begriff einzuordnen.
Die Autonomie-Leiter: Prompt, Chain, Workflow, Agent
Die ersten vier Begriffe bilden eine Leiter – von „Mensch steuert“ bis „Modell steuert“.
Prompt ist der gesamte Text, den das Modell sieht, bevor es antwortet; ein Zettel für einen brillanten, aber kontextlosen Kollegen. Das Modell kann keine Gedanken lesen, es kann nur Lücken füllen. Ein guter Prompt liefert deshalb Rolle, Kontext, Grenzen und das gewünschte Ausgabeformat mit. Ein Schritt, ein Aufruf, der Mensch steuert.
Chain heißt: Man verkettet mehrere Prompts fest hintereinander. Das Ergebnis von Schritt A wird zum Eingang von Schritt B – ein Fließband, das du selbst aufbaust. Das Modell ist dabei eine einzelne Station, nicht der Vorarbeiter. Immer noch steuert der Mensch.
Workflow ist dasselbe Prinzip, nur reifer: ein festgelegter Ablauf. Stell dir ein Rezept vor; Zwiebeln schneiden, anbraten, ablöschen, köcheln. Die Reihenfolge steht fest, ein Mensch hat sie geschrieben. Der Pfad ist vorhersagbar.
Agent ist der entscheidende Sprung. Statt des Rezepts hast du jetzt einen Koch, dem du sagst: „Mach was Leckeres aus dem, was im Kühlschrank ist.“ Das Modell entscheidet selbst, Schritt für Schritt, was als Nächstes passiert. Technisch läuft das als kleine Schleife, die man ReAct nennt (aus „Reason + Act“):
Denken: Was brauche ich als Nächstes?
Handeln: Ein Werkzeug benutzen.
Beobachten: Das Ergebnis ansehen und in die nächste Runde gehen.
Das läuft, bis das Modell selbst sagt: „Ich bin fertig.“ Wichtig: Das Kochwissen ist bei Rezept und Koch dasselbe. Der einzige Unterschied ist, wer den Ablauf bestimmt.
Eine Faustregel, die dir viel Geld und Nerven spart:
Höher ist nicht besser, höher ist teurer.
Ein Agent macht mehr Aufrufe, kostet mehr, ist langsamer und schwerer zu testen. Nimm immer die einfachste Lösung, die funktioniert – einen Agenten erst dann, wenn du den Pfad nicht vorher hinschreiben kannst. (Das ist keine Erfindung dieses Artikels: Anthropic formuliert in seinem Leitfaden „Building Effective Agents“ genau dieselbe Regel – die einfachste Lösung wählen und Komplexität nur erhöhen, wenn es nötig ist.)
Was ein Agent zum Handeln braucht: Tools, MCP, Skills
Ein Sprachmodell allein ist ein kluger Berater am Telefon – in einem leeren Büro. Frag ihn nach dem Wetter in Berlin, und er kann nur raten. Ihm fehlt aktuelles Wissen, verlässliche Berechnung und jede Wirkung in der echten Welt.
Tools sind die Brücke vom Reden zum Handeln. Ein Tool ist eine ganz normale Funktion – Wetter abfragen, eine Datei schreiben, rechnen –, die man dem Modell vorab beschreibt. Der Clou: Das Modell drückt keinen Knopf. Es schreibt einen Wunschzettel („Ich hätte gern das Wetter-Tool für Berlin“), und der umgebende Code führt ihn aus. Das Modell schlägt vor, der Code führt aus.
MCP ist so etwas wie ein USB-C-Anschluss für KI-Anwendungen. Wichtig: Nicht das einzelne Werkzeug hat den Stecker – die Anwendung hat den Anschluss, und Werkzeuge, Datenquellen und sogar fertige Prompt-Vorlagen docken einheitlich daran an. Früher brauchte man für jede Verbindung ein eigenes Kabel; MCP ist ein offener Standard, der das vereinheitlicht. Es beantwortet die Frage: Wie kommen zugekaufte Werkzeuge und Datenanbindungen sauber ins System?
Skills sind Ordner mit einer Anleitung (einer Datei namens SKILL.md) und oft mitgeliefertem Code, Vorlagen und Beispielen. Ein Skill gibt dem Modell also kein einzelnes Werkzeug – das tun Tools und MCP –, sondern bündelt ein komplettes Vorgehen: die Anleitung plus die nötigen Bausteine, um eine Aufgabe verlässlich abzuarbeiten. (Ein Mayflower-eigenes Beispiel ist der Skill zum Bearbeiten von Word-Dokumenten: neben der Anleitung liegen dort mehrere hundert Zeilen Python, die Kommentare und Änderungsverfolgung wirklich verarbeiten – kein bloßer Merkzettel.) Der Trick dabei heißt „Progressive Disclosure“: Zu Beginn kennt der Agent nur Name und Kurzbeschreibung jedes Skills – an der Beschreibung erkennt er, ob der Skill passt – und liest die Details erst, wenn er sie wirklich braucht. Das hält den Kopf des Modells frei.
Kurz: Tools und MCP schaffen einzelne Zugänge; ein Skill bündelt Vorgehen und oft mitgelieferten Code zu einer kompletten, verlässlich abarbeitbaren Arbeitsweise.
Die drei am häufigsten verwechselten Begriffe: Scaffold, Harness, Framework
Diese drei hörst du überall, meist durcheinander. Sauber getrennt sind sie ganz einfach:
Scaffold = was das Modell weiß. Der Briefing-Zettel: System-Prompt, Werkzeug-Beschreibungen, gewünschtes Antwortformat.
Harness = was das System tut. Der Assistent vor der Tür, der Unterlagen reinreicht, Anweisungen ausführt, mitschreibt und erkennt, wann das Ziel erreicht ist. Er ist die Schleife drumherum.
Framework = womit du beides baust. Die fertig ausgestattete Küche – Herd und Töpfe sind schon da, du schreibst nur noch das Rezept. Gängige Namen: LangChain, LangGraph, deepagents.
Ein hübsches Beispiel dafür, wie durcheinander diese Wörter im Alltag benutzt werden: Das Werkzeug deepagents, das wir hier als Framework einsortieren, bezeichnet sich in seiner eigenen Dokumentation als Harness. Wer googelt, trifft also prompt auf denselben Begriff für etwas anderes – genau die Verwechslung, die dieser Abschnitt auflösen will.
Der wichtigste Satz aus diesem Block, gerade für Nicht-Techniker: Vieles, was wie „Modellqualität“ aussieht, ist in Wahrheit Scaffold– und Harness-Qualität. Eine vage Werkzeug-Beschreibung macht das beste Modell unbrauchbar. Wenn ein Agent falsch abbiegt, liegt es fast nie am Modell – sondern am Briefing oder an der Schleife drumherum. Das ist eine ermutigende Nachricht: Man kann sehr viel verbessern, ohne das Modell selbst anzufassen.
Deep Agents: wenn die Aufgabe länger dauert
Ein einfacher Agent ist großartig für kurze Aufgaben – bei langen verheddert er sich. Das Problem heißt „Long-Horizon“: viele Schritte über eine lange Strecke. Der Arbeitsspeicher des Modells (das „Kontextfenster“) läuft voll, die Antwortqualität sackt ab („Context Rot“), und der Agent verliert sein Ziel aus den Augen.
Ein Deep Agent ist kein neues Vokabel-Wort, sondern derselbe Agent, dem man drei Profi-Gewohnheiten antrainiert hat: Er schreibt sich erst eine To-do-Liste und hakt sie ab (roter Faden), er macht Notizen auf Papier statt alles im Kopf zu behalten (der Speicher bleibt frei), und er delegiert Teilaufgaben an Hilfs-Agenten mit eigenem, abgeschottetem Kontext. Kurzformel: Deep Agent = einfacher Agent + Planen + Gedächtnis-auf-Papier + Hilfs-Agenten. Und auch hier gilt: Vieles, was wie Modellqualität aussieht, ist eigentlich Kontextqualität. (Wie das Delegieren an Hilfs-Agenten in der Praxis aussieht, zeigt der Beitrag Claude Code Must-Haves – Juni 2026.)
Der Betriebs-Teil: sehen, kontrollieren, messen
Die letzten drei Begriffe machen aus einer Spielerei ein verlässliches System.
Tracing ist die Aufzeichnung jedes einzelnen Schritts – jeder Modellaufruf, jeder Werkzeug-Aufruf. Ohne diese Aufzeichnung siehst du nicht, warum der Agent in Schritt 7 falsch abgebogen ist. Tracing ist kein nettes Extra am Ende, sondern der Querschnitt durch alles, den man von Tag 1 einbaut. (Ein verbreitetes Werkzeug dafür heißt Langfuse.)
Human-in-the-Loop (HITL) ist die Kontroll-Naht, an der ein Mensch bewusst eingreifen kann. Erinnere dich: Das Modell bittet nur um eine Aktion, der Harness führt aus. Genau dazwischen setzt man einen kontrollierten Stopp: Bevor eine kritische Aktion passiert – eine E-Mail rausgeht, etwas gelöscht oder live geschaltet wird – bestätigt ein Mensch. Die Faustregel: erst Guardrails, dann Autonomie. Erst die Leine, dann lockern.
Probabilistisches Engineering & Backtesting klingt sperrig, meint aber etwas Vertrautes. („Probabilistisches Engineering“ ist dabei eher meine Sammel-Bezeichnung für die Denkweise als ein feststehender Fachbegriff.) Klassische Software ist ein Taschenrechner: 2 + 2 ist immer 4. Ein Sprachmodell ist ein Würfel: dieselbe Frage bekommt jedes Mal eine leicht andere Antwort. Das ist kein Fehler, sondern die Natur der Maschine. Deshalb testet man nicht „funktioniert ja/nein“, sondern misst „in wie viel Prozent der Fälle macht es das Richtige“. Erfolg ist eine Verteilung (etwa 80 %, plus/minus ein paar Prozent), kein grünes Häkchen – warum grüne Tests bei KI-Code gerade nicht mehr genügen, vertieft der Beitrag Das Defekt-Profil von KI-Code. Und Backtesting – aus dem Finanzwesen entlehnt, im KI-Umfeld oft Regressionstest oder Eval-Set genannt – bedeutet: Jede neue Version lässt man gegen echte Fälle aus der Vergangenheit laufen und fragt: „Ist meine Änderung wirklich besser – oder glaube ich das nur?“
Wie man in der Praxis damit arbeitet
Du musst das nicht selbst bauen, aber du kannst die richtigen Fragen stellen und die richtigen Prinzipien einfordern:
- Klein anfangen. Erst ein Prompt. Reicht nicht? Chain oder Workflow. Reicht immer noch nicht? Erst dann ein Agent. Autonomie ist teuer – man kauft sie nur, wenn man sie braucht.
- Am Briefing feilen, nicht am Modell. Der größte Hebel steckt in klaren Werkzeug- und Aufgaben-Beschreibungen. Schon eine bessere Beschreibung korrigiert das Verhalten oft komplett.
- Tracing von Tag 1. Wenn niemand nachvollziehen kann, was der Agent getan hat, fliegt ihr blind.
- Menschen an die kritischen Nähte setzen. Alles, was in der echten Welt Schaden anrichten kann, braucht eine Bestätigung.
- Messen statt glauben. Vor jedem „das ist jetzt besser“ ein Backtest gegen echte Fälle.
Praxis-Beispiel: eine dreistufige Agentenstrecke
So sieht das konkret aus. Für die Aufbereitung von Anforderungen nutze ich eine Strecke aus drei spezialisierten Agenten – jeder mit einer klar abgegrenzten Aufgabe:
- Rechercheagent – sammelt Material und Fakten, schlägt aber ausdrücklich keine Lösungen vor.
- Fachlicher Planungsagent – erstellt Story Mapping (das Sortieren der Anforderungen entlang der Nutzerreise) und Personas (steckbriefartige Nutzerprofile), ohne technische Details.
- Technischer Planungsagent – entwirft die technische Struktur als Grundlage fürs Entwickler-Gespräch, ohne schon Code zu schreiben.
Das Herzstück ist die Phasentrennung als Quality Gate: Jeder Agent hat ein hartes Verbot, der nächsten Phase vorzugreifen. Recherche darf nicht lösen, Fachplanung darf nicht technisch werden, Technikplanung darf nicht coden. Genau diese Grenzen verhindern, dass sich früh ein Fehler einschleicht und über alle Stufen weiterwuchert. Wie sich solche Übergaben und Quality Gates mit mehreren orchestrierten Modi real durchspielen lassen, zeigt der Beitrag Wenn 15 Modi zur orchestrierten Symphonie werden.
Dazu kommen zwei kleine Helfer fürs Gedächtnis über Sitzungen hinweg: ein Befehl zum sauberen Abschließen einer Sitzung (Schreiben) und einer zum Wiedereinsteigen (Lesen) – dasselbe Trennprinzip wie in der Agentenstrecke, nur auf der Ebene der Zusammenarbeit.
Was du mitnehmen solltest
Der rote Faden durch alle 13 Begriffe ist erstaunlich einfach: Ein Agent ist ein Modell plus Harness – ein brillantes Gehirn, das Hände, Gedächtnis und eine Uhr bekommt. Tools sind seine Hände, Deep-Agent-Gewohnheiten sein Notizblock, Tracing und HITL die Kontrollinstrumente, Backtesting das Maßband.
Und der Kernsatz, den auch die technikfernsten Kolleginnen und Kollegen verstehen sollten: Ein Agent ist ein Würfel. Deine Aufgabe ist es nicht, ihn perfekt zu machen – sondern ihn beobachtbar, kontrollierbar und messbar zu machen. Dafür brauchst du keinen Code. Du brauchst diese Landkarte.
Schreibe einen Kommentar