Warum Agenten so verlässlich arbeiten, und wie ich mir das im Browser nachbaue

Warum Agenten so verlässlich arbeiten, und wie ich mir das im Browser nachbaue

In meinen Workshops kommt diese Frage immer wieder: „Warum funktioniert mein Prompt bei einer Aufgabe manchmal hervorragend, und bei der nächsten Aufgabe bekomme ich Unsinn, obwohl ich genau denselben Prompt benutzt habe?”

Im einen Fall hat die KI zum Beispiel hervorragend einen Teil der Beschreibung für eine Patentanmeldung formuliert; im anderen Fall kam nur generischer KI-Slop heraus.

Die Antwort hat selten etwas mit dem Prompt zu tun. Sie hat fast immer etwas mit dem Kontext zu tun, in dem der Prompt gelandet ist.

Was ein Agent automatisch richtig macht

Ob es um die Analyse zahlreicher Patentdokumente geht, um eine Bescheidserwiderung oder um die Erstellung eines Recherchereports für eine umfassende FTO. Wer in den letzten Monaten mit agentischer KI wie Claude Code, OpenCode oder Cursor gearbeitet hat, weiß: diese Werkzeuge können überraschend effektiv sein. Eine Aufgabe wird gestellt, das Werkzeug arbeitet die nötigen Schritte ab, im Hintergrund werden mehrere Sub-Agenten aufgerufen, und das Ergebnis ist oft deutlich besser als das eines manuellen Browser-Chats. Beim Chat schwankt die Trefferquote bei derselben Aufgabe deutlich stärker.

Diese Verlässlichkeit kommt nicht primär aus dem Modell. Es ist meist dasselbe Claude oder GPT, das auch im Browser läuft. Also dasselbe Sprachmodell, das auch ChatGPT und Copilot nutzen.

Sie kommt aus der Architektur der Werkzeuge: ein Skill, ein Kontext, eine Aufgabe. Wenn ich zum Beispiel einen Custom-Command wie /analyze-office-action in Claude Code aufrufe, öffnet das Werkzeug eine frische Session und ruft im Hintergrund mehrere spezialisierte Sub-Agenten auf, jeder mit seinem eigenen, isolierten Kontext:

• einer liest die PDF-Dokumente aus,
• einer analysiert die Offenbarung der Anmeldung,
• einer prüft die zitierten Prior-Art-Stellen einer Entgegenhaltung gegen den Anspruchssatz.

Nur die verdichteten Ergebnisse dieser Sub-Aufgaben fließen am Ende im Hauptchat zusammen, in dem die eigentliche Bescheidserwiderung formuliert wird. Der Hauptchat bleibt schlank und fokussiert, weil er weder die Volltexte der einzelnen Dokumente, die Roh-PDFs noch die Zwischen-Notizen tragen muss. Auch die Aufgabe von gestern hinterlässt keine Spuren.

Beispiel für eine typische Ausgabe von Claude Code

Das ist die Disziplin, die agentische Werkzeuge stark macht: jede Aufgabe bekommt ihren eigenen abgegrenzten Kontext. Im manuellen Prompting laufen mehrere Aufgaben ineinander, wenn man nicht aufpasst.

Warum Context Engineering wichtig ist

Sprachmodelle haben kein Kurzzeitgedächtnis im klassischen Sinn. Sie verarbeiten bei jeder Antwort den vollständigen Kontext: die aktuelle Frage, den bisherigen Chatverlauf, alle angehängten Dokumente.

Das Problem: Was einmal im Kontext steht, wirkt weiter, auch wenn es für die neue Aufgabe irrelevant ist. Ein typisches Szenario: Gestern Nachmittag wurde im Chat an einer Anmeldung zu einer Erfindung gearbeitet (zum Beispiel einem Kamerasensor mit verbesserter Belichtungsregelung). Heute morgen wird derselbe Chat für ein Mandantenschreiben zu einer ganz anderen Erfindung wiederverwendet (zum Beispiel einem LiDAR-Sensor). Das Modell zieht Begriffe und Argumente aus der Kamerasensor-Anmeldung in den neuen Brief, und niemand merkt es, bis ein konkretes Detail nicht passt (zum Beispiel werden dem LiDAR plötzlich Eigenschaften zugeschrieben, die eigentlich nur für den Kamerasensor gelten).

Ein Fehlerszenario ist besonders heimtückisch: Zitate aus dem Chatverlauf, die wie Zitate aus der Patentschrift aussehen. Das Modell greift einen Satz auf, der vor zehn Minuten formuliert wurde, und gibt ihn als Stelle aus dem Beschreibungstext zurück. Der Anwalt sieht ein plausibles Zitat mit Anführungszeichen und übernimmt es.

Drei typische Fehler im Alltag

Was Agenten automatisch richtig machen, lässt sich im Browser-Chat manuell nachbauen. Drei Fehler, die ich immer wieder sehe:

Fehler 1: Alte Sessions wiederverwenden. Ein besonders gravierender Fehler: Ein Anwalt öffnet morgens den Chat, in dem er gestern an einer Bescheidserwiderung gearbeitet hat, und tippt: „Jetzt schauen wir mal die nächste Anmeldung an.” Das Modell hat den Bescheid von gestern noch im Kontext. Die Auslegung des einen Anspruchssatzes färbt auf den nächsten ab, ohne dass es jemandem auffällt.

Fehler 2: Zu viele Dokumente in einen Kontext werfen. Drei Anmeldungen, fünf Bescheide, die gesamte Aktenkorrespondenz. Mehr Material ist nicht die Lösung. Bei langen Kontexten verliert das Modell Stellen aus der Mitte des Dokuments, ein Phänomen, das die Forschung als „lost in the middle” beschreibt. Für die Praxis heißt das: was in einer angehängten Entgegenhaltung in Absatz [0047] steht, kommt schlechter durch als der Inhalt von Anspruch 1 oder dem Abstract. Bei langen Akten ist das ein echtes Risiko. Liu et al. (2024) haben systematisch gezeigt, dass selbst Modelle mit Kontextfenstern von 100.000 Tokens und mehr Inhalte aus der Mitte langer Eingaben deutlich schlechter wiedergeben als Inhalte am Anfang oder Ende. Der Effekt ist u-förmig. Die Ursache wird in den Position-Encoding-Verfahren der Transformer-Architektur vermutet, insbesondere in Rotary Position Embedding (RoPE), das Tokens nahe an den Sequenzrändern stärker gewichtet als Tokens in der Mitte.

Der gesamte verfügbare Kontext ist selten für jede Aufgabe relevant und überfordert das Modell in einem einzigen Chat oft

Praktische Faustregel: Bei langen Eingaben (eine Patentschrift mit nur einer Entgegenhaltung reicht oft, die übrige angehängte Prior Art ist oft schon zu viel) wird der Effekt spürbar. Neuere Modelle mit gezieltem Long-Context-Training (GPT-4o, Claude 3.5/Opus 4, Gemini 2.5) schwächen den Effekt deutlich ab, eliminieren ihn aber nicht: eine Chroma-Studie von 2025 fand bei 18 getesteten Frontier-Modellen weiterhin Genauigkeitsrückgänge von 20 bis 50 Prozent zwischen 10.000 und 100.000 Tokens Eingabelänge. Gegenmaßnahme bleibt dieselbe wie hier beschrieben: weniger ins Kontextfenster werfen, oder die Aufgabe auf mehrere fokussierte Sessions aufteilen.

Fehler 3: Im laufenden Chat nachbessern, wenn das Ergebnis schon einmal danebenlag. Wenn das erste Ergebnis nicht stimmt, neigen die meisten dazu, im selben Chat nachzuhaken. Damit zementiert man die fehlerhafte Annahme. Ein Beispiel: Das Modell behauptet, ein Merkmal sei in Absatz [0023] der Beschreibung offenbart, obwohl die Stelle nicht existiert. Der Anwalt korrigiert: „Diese Stelle gibt es nicht.” Das Modell produziert eine „korrigierte” Version, die nun [0024] zitiert, dort aber dieselbe erfundene Aussage trägt. Solange die ursprüngliche Halluzination im Kontext steht, taucht sie in jeder weiteren Antwort wieder auf, in leicht abgewandelter Form. Sauberer ist: neuen Chat aufmachen, mit der präzisierten Frage und den richtigen Dokumenten.

Die Regel in einem Satz

Neue Aufgabe, neuer Chat, nur die Inhalte, die für diese Aufgabe wirklich relevant sind, im Kontext.

Die wirklich relevanten Inhalte sind selten das ganze Dokument (und schon gar nicht eine Sammlung von Dokumenten), sondern nur die einschlägigen Auszüge. Ja, Context Engineering kann zeitaufwändig sein.

Ein Beispiel-Workflow; die roten Pfeile stehen für die Ausgabe des vorigen Chats, die zugleich als Kontext für den nächsten dient

Das ist die Disziplin, die ein gut konfigurierter Agent automatisch durchsetzt. Im Browser hängt sie von einem selbst ab. Konkret: mindestens ein Chat pro Mandat, mehr als ein Chat pro Bescheid, mehr als ein Chat pro Schutzbereichsanalyse, und vor jedem Anhang die Frage, ob das Dokument für diese Aufgabe wirklich gebraucht wird oder nur dazu geladen wird, weil es gerade greifbar ist.

Wer sich an diese eine Disziplin gewöhnt, merkt nach wenigen Tagen einen Qualitätssprung. Die Antworten werden präziser, die Nachbearbeitung kürzer. Aufwand entsteht keiner, nur die Umstellung der eigenen Gewohnheit.

Zur Serie

Dieser Beitrag ist die erste von vier kommenden Ausgaben zu den vier Säulen, die in unseren Workshops als Grundgerüst für jede Aufgabe wiederkehren. Die nächsten drei folgen in den kommenden Wochen:

• Säule 2: Belegpflicht. Wie ich das Modell zwinge, jede Aussage mit Zitat und Fundstelle zu belegen.
• Säule 3: Absatz-für-Absatz-Durchsuchung. Warum Querlesen die häufigste Schwäche ist.
• Säule 4: Self-Reflexion und Advocatus Diaboli. Warum das Modell, das den Entwurf gemacht hat, der schlechteste Prüfer dafür ist.

Wer das interessant fand und Folge-Ausgaben mitlesen möchte, ein Tipp: warum nicht meinen Newsletter abonnieren? Hier ist der Link: https://boesherzgoebel.de/de/newsletter/

Quellen

1. Context Engineering (Wissen)
2. Liu et al., „Lost in the Middle: How Language Models Use Long Contexts” (TACL 2024)

Viel Spaß beim Erkunden!

Sebastian Goebel, Gründungspartner, Bösherz Goebel