Die 5 Stufen von KI-Agenten: Vom Prompt zur Produktion

Es gibt fünf Begriffe, die aktuell in aller Munde sind, wenn es um Agents geht: Context Engineering, Loop Engineering, Jev Engineering, Harness Engineering und Eval Engineering.

Sie klingen wie fünf konkurrierende Ansätze. Das sind sie aber nicht. Es sind fünf Schichten eines einzigen Systems – und jede beantwortet genau eine Frage.

Am einfachsten versteht man das, wenn du dir vorstellst, du hättest gerade einen neuen Mitarbeiter eingestellt:

• Context – was auf seinem Schreibtisch liegt, wenn du ihn etwas fragst
• Loop – ob er deine Checkliste abarbeitet oder den nächsten Schritt selbst herausfindet
• Jev – der Empfang, der die Post sortiert, damit er nur sieht, was wirklich wichtig ist
• Harness – sein Büro. Die Werkzeuge, die Schlüssel und wer seine Arbeit kontrolliert
• Evals – derselbe Test jeden Monat, damit du weißt, ob er wirklich besser geworden ist

Ein KI-Agent ist genau dieser Mitarbeiter. Das Modell ist die Person, und diese fünf Schichten sind alles, was drumherum passiert. Wenn diese fünf Schichten stimmen, kann ein kleines Team Aufgaben übernehmen, für die man früher neue Leute hätte einstellen müssen. Die Routinearbeit wandert an einen Agenten, der im Produktivbetrieb zuverlässig funktioniert, und deine Leute behalten die Entscheidungen. So sieht Skalierung ohne zusätzliche Köpfe in der Praxis aus.

Für jede Schicht zeige ich dir, was sie ist, wie sie funktioniert, wo du sie einsetzt und wie du sie aufbaust.

Und für jede Schicht habe ich auch eine Abkürzung vorbereitet. Einen einfacheren Weg zum selben Ergebnis, ohne alles von Grund auf neu bauen zu müssen – perfekt für Einsteiger. Meine Freunde bei Viktor haben mir geholfen, diese Abkürzungen zusammenzustellen.

Viktor ist ein KI-Mitarbeiter, der direkt in deinem Slack oder Microsoft Teams lebt. Er sitzt in denselben Kanälen wie alle anderen und arbeitet wie ein echter Teamkollege – einer, den du einfach hinzufügst, ohne eine neue Stelle ausschreiben zu müssen.

Die Zusammenarbeit mit ihm fühlt sich an wie mit einem echten Menschen:

• Du erwähnst ihn in einem Kanal oder Thread und beschreibst die Aufgabe.
• Er überlegt sich die Schritte, erledigt die Arbeit über deine Tools hinweg und postet das Ergebnis direkt zurück in denselben Thread.

Das Setup ist simpel. Füge Viktor einfach zu deinem Workspace hinzu, und er taucht als Teilnehmer auf – genau wie jedes andere Teammitglied. Wenn du ihn direkt beim Lesen ausprobieren willst, nutze den Code YARCHI100.

Abb. 1. Die fünf Schichten eines Agents

1. Context Engineering

Definition

Vor jeder Frage legst du dem Mitarbeiter Unterlagen auf den Schreibtisch. Leg die richtigen drei Seiten hin, und er antwortet in Sekunden. Leg dreihundert hin, und die Antwort ist irgendwo in der Mitte des Stapels begraben. Er übersieht sie.

Das Modell ist der Mitarbeiter. Der Schreibtisch ist das Kontextfenster: alles, was das Modell sieht, bevor es antwortet. Deine Anweisungen, der bisherige Chatverlauf, Dokumente aus einer Datenbank, die Ausgaben aller Tools, die es ausgeführt hat.

Context Engineering bedeutet zu entscheiden, was auf den Schreibtisch kommt – und wohin genau.

Wie es funktioniert

Mehr Kontext heißt nicht automatisch bessere Antworten. Ab einem bestimmten Punkt heißt es sogar schlechtere.

Stanford hat das direkt getestet. Gib einem Modell 20 bis 30 Dokumente, und seine Genauigkeit bei denen in der Mitte fällt auf etwa 50 bis 57 Prozent. Ganz ohne Dokumente erreichte dasselbe Modell 56 Prozent. Die Antwort stand im Fenster, und trotzdem schnitt das Modell schlechter ab als mit gar nichts.

Zwei Dinge sind dafür verantwortlich:

• Modelle achten am meisten auf den Anfang und das Ende des Fensters, am wenigsten auf die Mitte.
• Jedes Token kostet Geld und Zeit – egal, ob es hilft oder nicht.

Der einzige Mechanismus, den du kennen musst, ist Prompt Caching. Der Anbieter speichert den Anfang deines Prompts und verwendet ihn beim nächsten Aufruf wieder. Ein gecachtes Token kostet etwa zehnmal weniger als ein frisches.

Der Haken: Der Cache funktioniert nur, wenn dieser Anfang Byte für Byte identisch bleibt. Änderst du ein Zeichen weiter oben, wird alles danach zum vollen Preis abgerechnet. Die goldene Regel lautet also: Stabiles immer zuerst, Veränderliches immer zuletzt.

Wie man es aufbaut

Jedes Stück Kontext landet an einem von vier Orten:

1. System-Prompt. Nur das, was bei jedem Aufruf gilt: Rolle, Einschränkungen, Ausgabeformat. Halte ihn Byte für Byte identisch. Keine Zeitstempel am Anfang, keine JSON-Keys in zufälliger Reihenfolge.
2. Tools. Füge sie mitten im Gespräch weder hinzu noch entferne sie. Das zerstört den Cache und führt dazu, dass das Modell Tools aufruft, die es gar nicht mehr gibt. Willst du ein Tool in einem bestimmten Schritt einschränken, blockiere den Aufruf, aber behalte die Definition.
3. Festplatte. Alles Große oder Langlebige kommt in eine Datei, und nur der Pfad bleibt im Fenster. Dasselbe gilt für Webseiten: Behalte die URL, wirf den Inhalt weg. Oder: Wirf den Inhalt weg, behalte den Key, der ihn wiederholt.
4. Ende (Tail). Wiederhole alle paar Schritte das aktuelle Ziel nahe dem Ende des Kontexts. Die Mitte kannst du nicht reparieren, also halte das Wichtige dort heraus.

Auch Tools haben ein Limit. Anthropic hat gemessen, dass 58 Tool-Definitionen rund 55.000 Tokens fressen, bevor der Nutzer überhaupt ein Wort getippt hat. Als man das Modell nach Tools suchen ließ, statt alle zu laden, sprang Opus 4 im Benchmark von 49 auf 74 Prozent.

Unter etwa 20 Tools: lass sie geladen. Darüber: wechsle zur Suche.

Noch ein Trick für große Aufgaben: Schick einen Sub-Agenten. Er liest die 50 Dateien in seinem eigenen Fenster und liefert eine einseitige Zusammenfassung zurück. Dein Hauptkontext sieht nie mehr als diese Zusammenfassung.

Abb. 2. Was in einen einzigen Modellaufruf fließt

Abkürzung

Viktor nimmt dir das meiste davon ab, weil sein Kontext auf Unternehmensebene lebt.

• Gedächtnis. Er behält ein dauerhaftes Gedächtnis deines Unternehmens – teamübergreifend. Was er letzte Woche von deinem Mitgründer gelernt hat, musst du heute nicht in deine Anfrage kopieren.
• Verbundene Quellen. Sobald Notion, Google Drive oder HubSpot angebunden sind, hörst du auf, Dateien in den Chat zu pasten. Du nennst das Dokument oder den Datensatz, und er liest direkt aus der Quelle. Die Festplatten-Regel – fertig umgesetzt.
• Skills. Du nimmst deinen Bildschirm einmal bei einer Aufgabe auf. Er macht daraus eine schriftliche Anleitung, du korrigierst und gibst sie frei. Ab da ist diese Instruktion fixiert und geprüft – wie ein guter System-Prompt.

Was auf deiner Seite bleibt:

• Schreib einmalig ein kurzes Firmen-Briefing: Was ihr verkauft, wer kauft, welche Zahlen zählen, was er niemals tun darf.
• Eine Aufgabe pro Thread, inklusive der Definition von „fertig“ in der ersten Nachricht.
• Hat er etwas falsch gelernt, lösch sein Gedächtnis in den Einstellungen, statt ihn in jedem Thread neu zu korrigieren.

2. Loop Engineering

Definition

Du kannst dem Mitarbeiter eine Checkliste geben: Datei öffnen, Zeile 12 ändern, speichern. Oder du gibst ihm ein Ziel: Bring den Test zum Durchlaufen.

Mit einem Ziel probiert er etwas aus, schaut, was passiert, und entscheidet, was als Nächstes dran ist. Die Checkliste ist ein Workflow. Das Ziel ist ein Loop.

Wie es funktioniert

Ein Loop besteht aus vier Schritten in Dauerschleife: denken, handeln, beobachten, entscheiden. Einen Bug zu beheben sieht dann so aus:

1. Tests ausführen. Drei schlagen fehl.
2. Den ersten Fehler lesen. Es fehlt ein Import.
3. Import hinzufügen, erneut ausführen.
4. Ein Test schlägt immer noch fehl. Diesen Fehler lesen, beheben, erneut ausführen.
5. Alles läuft durch. Stopp.

Niemand hat diese Schritte vorher aufgeschrieben. Das Modell hat jeden einzelnen gewählt, nachdem es das letzte Ergebnis gesehen hat.

Das ist der ganze Unterschied. Hundert Schritte, die du geschrieben hast, sind immer noch ein Workflow. Drei Schritte, die das Modell gewählt hat, sind ein Loop.

Nutze einen Loop nur, wenn du die Schritte nicht im Voraus schreiben kannst. Wenn du sie schreiben kannst, tu es. Ein Workflow ist günstiger, läuft parallel, und wenn Schritt vier fehlschlägt, startest du nur Schritt vier neu – nicht alles.

Loops sind außerdem teuer. Ein Agent verbraucht grob viermal so viele Tokens wie ein einzelner Aufruf. Multi-Agenten-Setups liegen bei etwa dem Fünfzehnfachen.

Wie man es aufbaut

Ein Loop braucht vier Teile. Nimm einen weg, und er funktioniert nicht mehr:

1. Ein Ziel mit klarem „Fertig“-Kriterium. Nicht „Bug fixen“. Sondern: „Der fehlschlagende Test in auth_test.py läuft durch und nichts anderes ist kaputtgegangen.“
2. Ein Prüfer. Etwas außerhalb des Modells, das „bestanden“ oder „durchgefallen“ sagt: eine Test-Suite, ein Compiler, ein Linter. Die Forschung zur Selbstkorrektur ist hier eindeutig. Sie funktioniert mit echtem externen Feedback und scheitert, wenn das Modell nur sich selbst bewertet. Kein Prüfer bedeutet kein Loop, sondern nur offene Kosten.
3. Eine Stopp-Regel. Der Prüfer sagt „bestanden“, du erreichst das Zug-Limit, oder die letzten zwei Versuche lieferten dieselbe Ausgabe.
4. Ein Budget. Sowohl für Züge als auch für Dollar.

Im Code passt das Ganze in wenige Zeilen:

1for turn in range(MAX_TURNS):
2    action = model.next_step(goal, history)
3    result = run(action)
4    history.append(result)
5
6    if checker(result):       break   # fertig
7    if repeated(history, 2):  break   # festgefahren
8    if spent() > BUDGET:      break   # zu teuer
9else:
10    fallback_workflow(goal)

Das beste Setup für den Produktivbetrieb, das ich bisher veröffentlicht gesehen habe, ist ein Hybrid. Atlan lässt zuerst einen deterministischen Filter laufen, sodass nur etwa 14 Prozent der eingehenden Alerts überhaupt beim Agenten landen.

Der Loop bekommt dann maximal drei Zyklen. Liegt die Konfidenz nach drei Runden immer noch unter 50 Prozent, übernimmt ein fester Python-Workflow.

Erst filtern, dann kurz loopen, dann Fallback.

Abb. 3. Wie du zwischen Workflow und Loop entscheidest

Abkürzung

Jede Aufgabe, die du Viktor in einem Thread gibst, ist ein Loop. Du formulierst das Ziel, er wählt die Schritte, arbeitet sich durch deine Tools und kommt mit dem Ergebnis in den Thread zurück.

Die vier Teile sehen dabei so aus:

• Ziel. Er hakt bei unvollständigen Briefings nach und fragt lieber, statt zu raten. Trotzdem: Definiere das „Fertig“. „Umsatzbericht für letzte Woche, Summen stimmen mit Stripe überein, gepostet in #finance bis Montag 9 Uhr“ schlägt „mach mal den Bericht“ um Längen.
• Prüfer. Er markiert Zahlen, die komisch aussehen, bevor er etwas postet. Mach es robuster, indem du die Vergleichsquelle benennst: die Stripe-Summe, die Zeilenanzahl, die Test-Suite.
• Stopp-Regel. Bei sensiblen Aktionen pausiert er für einen Menschen, und das Ergebnis kommt immer bei dir an.
• Budget. Credits. Der Reasoning-Tier bestimmt den Preis jedes Schritts, und bei wiederkehrenden Jobs zählt die Frequenz. Ein stündlicher Bericht kostet weit mehr als ein wöchentlicher.

Der Atlan-Hybrid funktioniert auch ohne Code. Arbeit, die sich wiederholt, wird zum geplanten Task: Er schlägt ihn vor, und er bleibt pausiert, bis du ihn freigibst. Das ist dein Workflow.

Alles Offene landet in einem Thread – das ist dein Loop. Du bist der Fallback.

3. Jev Engineering

Definition

Der Experte im Büro öffnet nicht jeden Umschlag. Jemand am Empfang sortiert die Post: Rechnungen auf einen Stapel, Spam in den Müll, Verträge zum Anwalt.

Dein Agent macht zwei Arten von Arbeit: etwas schreiben und etwas entscheiden. Aktuell erledigt ein großes Modell beides – du bezahlst also den Anwalt fürs Postsortieren.

Jev ist der Empfang. Er schreibt nie. Er wählt nur aus.

Wie es funktioniert

Du gibst Jev vorab eine Frage und die möglichen Antworten. Er liefert eines von drei Dingen zurück, plus einen Konfidenzwert:

• Ja oder Nein
• eine Option aus einer Menge
• eine Zahl auf einer Skala

Weil er nur auswählt, ist er schnell und günstig. Die versprochenen Zahlen: 70 bis 500 Millisekunden gegenüber 3 bis 329 Sekunden, und 0,042 $ pro Million Input-Tokens bei kostenfreiem Output.

Jetzt der ehrliche Teil. Jev ist zwei Wochen alt, und unabhängige Tests trudeln gerade erst ein.

• Bei der E-Mail-Klassifizierung erreichte eine einfache logistische Regression 98,9 Prozent, Jev kam auf 98,6.
• Bei der Phishing-Erkennung schaffte Jev 62,6 Prozent, während Claude Haiku 4.5 auf 81,3 kam.
• Die Angabe „null Halluzinationen“ kommt mit einer Fußnote der Autoren selbst: Sie ist nicht empirisch belegt, sondern bedeutet nur, dass die Ausgabe immer dem Schema entspricht.

Auch der Konfidenzwert ist out of the box keine echte Wahrscheinlichkeit. Behandle ihn als Ranking und lege Schwellenwerte anhand deiner eigenen gelabelten Daten fest.

Wie man es aufbaut

Sinnvoll ist ein Gate vor dem teuren Modell:

1. Alles kommt rein.
2. Jev beantwortet eine enge Frage zu jedem Element.
3. Sicher und routinemäßig: wird günstig erledigt. Gelabelt, weitergeleitet oder verworfen.
4. Unsicher oder ungewöhnlich: geht ans Hauptmodell.

1d = jev.choose(item, options=["spam", "order_status", "refund", "other"])
2
3if d.confidence >= 0.7 and d.option != "other":
4    handle_cheap(d.option, item)
5else:
6    main_model(item)   # fail closed: Unsicheres geht den teuren Weg

Bevor du all das machst, probier das Dümmste, was funktionieren könnte. Label ein paar hundert echte Beispiele, trainiere einen simplen Klassifikator und wechsle erst hoch, wenn das nicht reicht.

Das sind dreißig Minuten Arbeit – und die Baseline, die jede Vendor-Behauptung erst mal schlagen muss.

Abb. 4. Die drei Arten von Fragen, die Jev beantwortet

Abkürzung

Jev gehört nicht zu Viktors veröffentlichtem Stack, aber die Idee greift an zwei Stellen, die du kontrollierst:

• Der Reasoning-Tier. Er läuft auf dreien: Smart auf Claude Opus, Balanced auf Claude Sonnet für etwa die halben Kosten, Ultra auf Claude Fable für etwa das Doppelte. Anfragen sortieren oder eine einzelne Zahl ziehen braucht nicht die höchste Stufe.
• Das Gate vor ihm. Wenn er einen Strom bearbeiten soll – etwa Support-Mails oder Alerts –, übergib ihm nicht den ganzen Strom. Schalte einen Klassifikator oder einen Jev-Aufruf davor, sodass nur die Fälle zu Aufgaben werden, die wirklich Urteilsvermögen brauchen.

Das ist eine der beiden Schichten, bei der dein eigenes Engineering selbst mit Viktor noch zählt.

4. Harness Engineering

Definition

Derselbe Mitarbeiter, zwei Büros. Im ersten hat er die richtigen Werkzeuge, ein Handbuch an der Wand, einen Kollegen, der seine Arbeit prüft, und keinen Schlüssel zum Tresor. Im zweiten hat er einen Laptop und dein Admin-Passwort.

Gleiche Fähigkeiten, völlig unterschiedliche Ergebnisse. Der Mitarbeiter ist das Modell. Das Büro ist der Harness.

Agent = Modell + Harness.

Wie es funktioniert

Der Harness ist alles, was nicht das Modell ist: Tools, Berechtigungen, die Sandbox, Dateien, die das Projekt erklären, Prüfungen der Ausgabe.

Er wurde 2026 zur eigenen Disziplin, weil die Leute anfingen zu messen – und das Modell weniger erklärte als gedacht:

• Anthropic änderte nur die Container-Ressourcen und verbesserte einen Benchmark-Score um 6 Punkte.
• LangChain fror das Modell ein und steigerte denselben Benchmark um 13,7 Punkte, nur durch Änderungen am Harness.
• Dann optimierten sie den Harness um ein offenes Modell, das zehnmal günstiger war, bis es 0,86 gegen die 0,87 von Opus 4.8 erreichte.

Du kaufst kein Modell mehr. Du kaufst ein Modell und einen Harness zusammen.

Du brauchst beides in dem Moment, in dem der Agent etwas Reales berührt: ein Repo, einen Posteingang, eine Zahlung, eine Produktionsdatenbank.

Wie man es aufbaut

Baue von außen nach innen:

1. Eindämmung (Containment). Was der Agent physisch nicht erreichen kann. Ein Container, ein separater Branch, ein Read-only-Datenbanknutzer, kein Netzwerk außer einer Allowlist. Mach das vor dem ersten Prompt.
2. Leitplanken (Guides). Was ihn steuert, bevor er handelt. Eine Datei im Repo wie AGENTS.md, Tool-Beschreibungen, die klar genug sind, damit das Modell das richtige wählt, ein paar Beispiele für gute Ausgaben.
3. Sensoren. Was ihn prüft, nachdem er gehandelt hat. Linter, Type-Checker, Test-Suite: schnell und deterministisch, also lass sie über alles laufen. Langsamere Prüfungen, etwa ein zweites Modell, das einen Diff reviewt, nur für das, was wirklich zählt.
4. Berechtigungen. Wenn Agents um Freigabe bitten, stimmen Menschen in 93 Prozent der Fälle zu. Der Genehmigungs-Prompt schützt fast nichts. Echter Schutz sind Aktionen, die schlicht nicht verfügbar sind. Heb dir Genehmigungen für die wenigen Dinge auf, die wirklich irreversibel sind.

Eine Guide-Datei muss nicht lang sein. Vier Zeilen verändern das Verhalten bereits:

1# AGENTS.md
2- Monorepo: /api (FastAPI), /web (Next.js), /jobs (cron)
3- Tests mit `make test` ausführen. Sie müssen vor jedem Commit durchlaufen
4- /migrations niemals manuell bearbeiten, stattdessen `make migration` nutzen
5- DB-Zugriff ist read-only. Vor jeder Schema-Änderung nachfragen

Hooks sind die erzwungene Version derselben Idee. In Claude Code ist ein Hook ein kleines Skript, das vor einem Tool-Aufruf läuft und ihn blockieren kann. „Niemals auf main pushen“ funktioniert als Hook, nicht als Zeile im Prompt.

Eine Warnung: Jedes Teil deines Harness ist eine Wette darauf, dass das Modell etwas nicht kann – und diese Wetten verfallen. Anthropic hat eine komplette Scaffolding-Komponente gelöscht, nachdem ein Modell-Update sie überflüssig machte.

Lies deinen Harness alle paar Monate neu und lösch, woraus das Modell herausgewachsen ist.

Abb. 5. Die vier Ringe eines Harness

Abkürzung

Wenn Agent = Modell + Harness gilt, ist das meiste, was du mit Viktor bekommst, Harness. Das Modell darunter ist Claude. Alles rundherum kommt fertig mit:

• Tools. Über 3.200 Integrationen: GitHub, Linear, HubSpot, Stripe, Notion, Google Drive und mehr. Für ein Tool ohne fertige Verbindung kann er selbst eine bauen.
• Leitplanken. Skills. Statt AGENTS.md selbst zu schreiben, nimmst du deinen Bildschirm auf, er entwirft die Anleitung, du bearbeitest sie.
• Sensoren. Er markiert Daten, die nicht zusammenpassen, und hinterfragt Briefings mit fehlenden Teilen. Und jeder Schritt landet in einem Slack-Thread, den dein Team lesen kann.
• Berechtigungen. Kunden-E-Mails und finanzielle Änderungen pausieren für eine Freigabe. Neue geplante Automatisierungen bleiben pausiert, bis jemand sie einschaltet.

Der Teil, den kein Produkt für dich bauen kann, ist die Eindämmung – denn sie besteht aus den Credentials, die du übergibst. Denk an die 93 Prozent und verbinde ihn mit dem geringstmöglichen Zugriff, den der Job erfordert:

• ein Read-only-Datenbanknutzer
• ein eingeschränkter Stripe-Key
• ein geteiltes Support-Postfach, nicht dein persönliches
• ein GitHub-Token, das auf bestimmte Repos beschränkt ist

Was er nicht erreichen kann, kann er auch nicht kaputtmachen.

Abb. 6. Viktors Harness

5. Evals Engineering

Definition

Woher weißt du, ob ein neuer Mitarbeiter besser geworden ist? Du gibst ihm denselben Test wie letzten Monat und vergleichst.

Ohne denselben Test ist jede Änderung, die du vornimmst, reine Spekulation. Evals sind dieser Test für deinen Agenten: ein Satz von Aufgaben, bei denen du die richtige Antwort schon kennst, ausgeführt jedes Mal, wenn du etwas änderst.

Wie es funktioniert

Es gibt zwei Arten von Prüfungen:

• End-to-end. War die finale Antwort richtig? Das zeigt dir, dass sich der Score verändert hat, aber nicht warum.
• Behavioral. Ist eine bestimmte Sache passiert? Hat er vor der Antwort gesucht? Hat er eine Rückfrage gestellt, als die Anfrage unklar war? Hat er geprüft, bevor er „fertig“ gesagt hat?

Behavioral Checks laufen auf dem Trace – dem Log von allem, was der Agent getan hat –, nicht nur auf der finalen Antwort. Googles Regel besagt, dass diese Suite in unter fünf Sekunden durchlaufen muss, damit sie bei jeder Änderung laufen kann.

Wenn ein Modell die Bewertung übernimmt, ist das ein Judge – und der Judge muss ebenfalls geprüft werden. Airbnb stellte fest, dass etwa drei Viertel ihrer modellgenerierten Referenzantworten bei wiederholten Läufen desselben Inputs anders ausfielen. Ihr Eval maß sein eigenes Rauschen.

Wie man es aufbaut

1. Starte mit echten Fehlern. Geh reale Durchläufe durch, finde, was schiefging, und mach aus jedem Fall einen Testcase. Airbnbs Golden Sets umfassen 50 bis 100 Beispiele, und Fehler sind Pflicht.
2. Schreib einen Behavioral Check pro Case. Ein Fall, eine Sache zum Prüfen.
3. Prüfe deinen Judge. Bewerte eine Stichprobe von Hand und schau, wie oft du und das Modell übereinstimmen, bevor du ihm vertraust.
4. Sample aus der Produktion. Airbnb zieht täglich 5 Prozent des Live-Traffics. Dein Eval-Set verrottet, sobald sich die echte Nutzung davon entfernt.

Ein einzelner Case kann so klein sein:

1input: "Rückerstattung Bestellung #1042, Kunde sagt, sie kam kaputt an"
2expect:
3  - schlägt die Bestellung nach, bevor er antwortet
4  - fragt nach Freigabe, bevor die Rückerstattung ausgelöst wird
5check:
6  - trace enthält get_order vor send_reply
7  - trace enthält approval_request vor refund

Starre nicht auf die Gesamtquote. Sie kann steigen, während ein bestimmtes Verhalten leise kaputtgeht. Beobachte die einzelnen Checks.

Abb. 7. Woher gute Eval-Cases kommen

Abkürzung

Kein Produkt kann dir diese Schicht abnehmen, denn nur du weißt, wie die richtige Antwort für dein Business aussieht. Die Methode lässt sich aber direkt übertragen:

• Wähle nach zwei Wochen 20 seiner Threads aus, bei denen du die korrekte Antwort kennst. Nimm jeden mit, bei dem du ihn korrigieren musstest.
• Schreib einen einfachen Check pro Case. Hat er für jede Zahl eine Quelle verlinkt? Hat er nachgefragt, als das Briefing unklar war? Hat er pausiert, bevor etwas das Unternehmen verließ?
• Lass das Set nach jeder Änderung neu laufen: ein neuer Skill, ein angepasstes Briefing, ein anderer Tier. Der Wechsel von Smart zu Balanced spart etwa die Hälfte der Credits – teste das also, bevor du dauerhaft wechselst.
• Bewerte einmal pro Woche fünf zufällige Threads von Hand.

Alles zusammenfügen

Fünf Schichten, fünf Fragen. Context ist, was er sieht. Loop ist, wer entscheidet. Jev übernimmt die günstigen Entscheidungen. Harness ist, was er erreichen kann und wer ihn prüft. Evals sind, woher du es weißt.

Bei Viktor kommen drei davon größtenteils eingebaut: Context, Loop und Harness. Jev, Evals und die Credentials, die du übergibst, bleiben dein Engineering.

Wenn du heute startest, hier der günstigste sinnvolle Schritt für jede Schicht:

• Context: Verschiebe deine stabilen Anweisungen in den System-Prompt und hör auf, sie zu ändern.
• Loop: Setz ein Zug-Limit und ein Dollar-Limit, bevor du ihn laufen lässt.
• Jev: Label 200 Beispiele von dem, was dein Agent am häufigsten entscheidet.
• Harness: Lass deinen Agenten als Nutzer laufen, der nichts löschen kann.
• Evals: Schreib deine letzten fünf Fehler als Testcases auf.

Mit Viktor sieht derselbe Tag so aus:

• Context: Schreib das Firmen-Briefing und nimm deinen ersten Skill auf.
• Loop: Pack in jede Aufgabe eine Definition von „fertig“ und wähle den Tier bewusst.
• Jev: Filtere jeden Strom, bevor er zu Aufgaben für ihn wird.
• Harness: Verbinde ihn mit Read-only-Credentials und begrenztem Scope.
• Evals: Speicher 20 echte Threads als dein erstes Test-Set.

Das ist ein Tag Arbeit – und deckt alle fünf ab.

Mein Fazit: Das Modell ist nicht länger der schwierige Teil. Die fünf Schichten darum herum sind es. Bring sie in Ordnung, und du gewinnst Kapazität, ohne neue Köpfe einzustellen. Die meisten Teams sollten die ersten drei aus dem Regal nehmen und ihre eigene Zeit in die zwei investieren, die über Qualität entscheiden: die günstigen Entscheidungen und die Evals.

Danke an Viktor für das Sponsoring dieses Artikels.

Kostenlos testen unter @viktor_com. 100 $ in Credits, keine Karte nötig. Den vollständigen Link findest du in meiner ersten Antwort.

Nutze den Code YARCHI100 bei der Anmeldung.

Bezahlte Partnerschaft