Context Engineering: Compaction, Übergaben, Resets und Thinking Effort

Überblick

Context Engineering ist das aktive Managen dessen, was der Agent gerade hält. Vier Hebel erledigen die meiste Arbeit. Compaction fasst ein langes Gespräch zusammen, um das Fenster freizumachen, aber die automatische Version lässt still Dinge fallen, die dir wichtig waren, also steuerst du sie. Eine Übergabe gibt eine saubere Zusammenfassung an eine frische Session weiter. Ein Reset wirft einen verwirrten Kontext weg und beginnt mit einem knappen Prompt neu. Und der Thinking Effort tauscht Kosten gegen Tiefe bei wirklich harten Problemen. Meistere diese vier, und lange Aufgaben bleiben scharf, statt in Verwirrung abzudriften.

Was du lernst

Du lernst, warum Auto-Compaction eine Falle ist und wie du zu deinen eigenen Bedingungen komprimierst, wie du dein Ziel neu einspielst, damit der Agent nach einer Zusammenfassung nicht abdriftet, wie du ein Übergabe-Dokument schreibst, das eine frische Session ohne Fadenverlust fortsetzen lässt, wie du erkennst, wann ein Reset eine weitere Runde Flicken schlägt, und wie du den Thinking Effort setzt, damit du für tiefes Reasoning nur zahlst, wenn die Aufgabe es verdient.

Voraussetzungen

Die Lektion zu Tokens, Kontext und Performance-Cliff aus Kurs 1 und echte Erfahrung mit mehrschrittigen Aufgaben, lange genug, dass du eine Session unscharf werden gespürt hast. Diese Techniken zählen erst, wenn Sessions lang werden, also ist die Sub-Agent-Lektion davor eine natürliche Hinführung - Sub-Agents managen Kontext über Agents hinweg, diese Lektion managt ihn innerhalb eines.

Das Problem

Du steckst tief in einer langen Aufgabe. Das Kontextfenster füllt sich, und irgendwann komprimiert das Harness automatisch - es fasst das bisherige Gespräch zusammen, um Platz zu machen. Plötzlich fühlt sich der Agent anders an. Er hat eine Entscheidung vergessen, die du früh getroffen hast, oder er optimiert jetzt auf das falsche Ziel, oder er widerspricht selbstbewusst etwas, dem er vor einer Stunde zugestimmt hat. Auto-Compaction hat ihren Job mechanisch erledigt: sie hat Platz geschaffen. Aber sie hat nach ihren eigenen Prioritäten zusammengefasst, nicht deinen, und still das Constraint fallen gelassen, das dir am wichtigsten war. Du hast nicht gewählt, was bleibt, also hast du den Faden verloren, ohne es zu merken.

Warum Auto-Compaction schadet, und sie steuern

Auto-Compaction ist nicht bösartig, sie ist nur verlustbehaftet und ungetimt. Sie feuert, wenn das Fenster fast voll ist, was meist der schlechteste Moment ist, mitten im Gedanken, und sie komprimiert alles nach einer generischen Heuristik herunter, die dein echtes Ziel nicht kennt. Das Ergebnis ist ein subtiler Qualitätsverlust, den du oft erst bemerkst, nachdem der Agent abgedriftet ist. Die Lösung ist, die Kontrolle über den Moment und den Inhalt zu übernehmen. Komprimiere bewusst, an einem sauberen Bruchpunkt zwischen Teilaufgaben statt mitten im Schritt. Und spiel direkt nach jeder Compaction dein Ziel neu ein: formuliere das Ziel, die zentralen Constraints und den aktuellen Stand in ein paar Zeilen neu. Dieser eine Absatz verankert den Agent neu und macht das meiste rückgängig, was die Compaction verwischt hat.

• Komprimiere an einem sauberen Bruchpunkt, den du wählst, nicht wenn das Fenster es mitten in der Aufgabe erzwingt.
• Spiel nach der Compaction das Ziel neu ein: formuliere das Ziel, die nicht verhandelbaren Constraints und wo du jetzt stehst neu.
• Achte nach einer Zusammenfassung auf Abdriften - wenn sich die Antworten des Agents falsch anfühlen, ist ein verlorenes Constraint die übliche Ursache.
• Eine CLAUDE.md hilft auch hier: Regeln in der Datei überleben, weil sie neu geladen werden, anders als Punkte, die im Chat vergraben sind.

Übergabe-Dokumente

Manchmal ist der sauberste Zug nicht zu komprimieren, sondern an eine frische Session mit sauberem Fenster zu übergeben. Das Werkzeug dafür ist ein Übergabe-Dokument: eine kurze Markdown-Datei, die du den Agent schreiben lässt und die alles festhält, was die nächste Session braucht. Gut gemacht liest ein neuer Agent die Übergabe und ist sofort so informiert wie der alte, aber mit einem leeren, scharfen Kontext. Das ist der mit Abstand verlässlichste Weg, Arbeit zu fahren, die für ein Fenster viel zu lang ist, ohne den Qualitätsverfall, und es ist zugleich ein Protokoll, das du einem Teammitglied geben kannst.

# Handover: Checkout flow refactor

## Goal
Move checkout from the old form to Stripe embedded checkout. Must keep the
existing success page and not change the cart.

## Done so far
- Added the Stripe SDK and the new checkout component.
- Wired the create-session endpoint (see src/api/checkout.ts).

## Current state / next step
- The embedded form renders but the redirect after payment 404s.
- Next: fix the return_url in checkout.ts to point at /order/success.

## Constraints (do not forget)
- TypeScript only, run the quality gate before pushing.
- Never log the Stripe secret key.

Bitte den Agent, das zu schreiben, bevor du eine lange Session beendest, und füg es dann in einen frischen Chat ein, um fortzufahren. Die neue Session startet mit einem sauberen Fenster und einem präzisen Brief, was fast immer schärfer ist, als eine aufgeblähte Session eine weitere Runde zu schieben.

Wann zurücksetzen

Ein Reset ist, mit einem frischen, fokussierten Prompt neu zu beginnen und den aktuellen Kontext aufzugeben. Es klingt, als würfe man Arbeit weg, aber es ist oft der schnellste Weg nach vorn. Wenn ein Agent auf demselben gescheiterten Fix in einer Schleife hängt, sich selbst widerspricht oder einen so aufgeblähten Kontext trägt, dass jede Antwort mittelmässig ist, hilft mehr Flicken selten - du streitest mit einem verwirrten Fenster. Setz stattdessen zurück. Nimm, was du gelernt hast, schreib einen knappen Prompt oder eine Übergabe und beginn sauber. Das Signal ist einfach: wenn du dasselbe zweimal erklärt hast und es immer noch nicht ankommt, ist der Kontext das Problem, nicht die Anweisung. Ein Reset räumt ihn auf.

Thinking Effort

Thinking Effort ist, wie viel bewusstes Reasoning das Modell vor dem Antworten betreibt. Mehr Effort heisst, es arbeitet das Problem sorgfältiger durch, was mehr Tokens und Zeit kostet, aber die Qualität bei wirklich harten Aufgaben hebt - kniffliges Debugging, Architekturentscheidungen, subtile Logik. Weniger Effort ist richtig für Routinearbeit, bei der tiefes Reasoning verschwendetes Geld ist. Die praktische Regel spiegelt die Modellauswahl aus Kurs 1: dreh den Effort für die harten 20 Prozent hoch, die ihn wirklich brauchen, und halt ihn niedrig für die leichten 80 Prozent. Du kannst eine Voreinstellung setzen und sie je Aufgabe anheben. Für maximales Reasoning bei einem Rename oder einem Formatierungsdurchlauf zu zahlen ist derselbe Fehler, wie eine Chirurgin ein Pflaster aufkleben zu lassen.

• Hoher Effort: hartes Debugging, Architektur, subtile Logik - die Fälle, in denen sorgfältiges Reasoning die Antwort verändert.
• Niedriger Effort: Routine-Bearbeitungen, Formatieren, einfache Refactors - Tiefe ist hier verschwendetes Geld.
• Passe den Effort an die Schwierigkeit an, genauso wie du die Modellstufe an die Schwierigkeit anpasst.
• Effort und ein starkes Modell addieren sich: spar beides für die wirklich harten Probleme.

Typische Fehler

Die wiederkehrenden: Auto-Compaction feuern lassen und nie das Ziel neu einspielen, sodass der Agent still abdriftet; eine verwirrte, aufgeblähte Session Runde um Runde schieben, wenn ein Reset schneller gewesen wäre; nie eine Übergabe schreiben, sodass jede lange Aufgabe verfällt, statt sauber fortzufahren; und maximalen Thinking Effort bei trivialer Arbeit verbrennen, während du dich wunderst, warum die Rechnung hoch ist. Der Meta-Fehler ist, Kontext als etwas zu behandeln, das dir einfach passiert, statt als etwas, das du aktiv engineerst.

Business-ROI

Context Engineering ist das, was grosse, mehrstündige agentische Arbeit wirklich verlässlich macht statt eines langsamen Abgleitens in Verwirrung. Zu deinen Bedingungen zu komprimieren, sauber zu übergeben und im richtigen Moment zurückzusetzen halten die Output-Qualität über Aufgaben hinweg hoch, die weit grösser sind als ein Fenster - was weniger Nacharbeit und weniger subtile Bugs durch einen abdriftenden Agent bedeutet. Den Thinking Effort an die Schwierigkeit anzupassen steuert die Kosten direkt. Für eine Gründerin, die echte Workflows fährt, sind diese Gewohnheiten der Unterschied zwischen agentischer Arbeit, die skaliert, und agentischer Arbeit, die still verfällt, je länger sie läuft.

Checkliste

Du bist bereit weiterzugehen, wenn jedes davon stimmt. Die letzte Lektion stellt das Pro-Setup zusammen, das all das im Alltag glatt macht.

• Du kannst erklären, warum Auto-Compaction schadet und was das Neu-Einspielen des Ziels bewirkt.
• Du kannst den Agent ein Übergabe-Dokument schreiben lassen und in einer frischen Session fortfahren.
• Du kennst die Signale, die Reset statt Flicken bedeuten.
• Du passt den Thinking Effort an die Aufgabenschwierigkeit an, statt ihn immer zu maximieren.

Ressourcen

Halt die Claude-Code-Dokumentation zum Kontext-Management und den Befehlen compact und clear als Lesezeichen für das aktuelle Verhalten und die Flags. Halt ein Übergabe-Template in deiner Ressourcen-Bibliothek, damit eines zu schreiben eine Zwei-Minuten-Gewohnheit ist. Deine CLAUDE.md ist deine Versicherung gegen Compaction-Verlust, denn Regeln in der Datei werden neu geladen, während Punkte im Chat vergraben es nicht werden.

Deine Aufgabe

Bei deiner nächsten langen Aufgabe tu zwei Dinge bewusst. Wenn das Fenster voll wird, komprimiere selbst an einem sauberen Bruchpunkt und spiel dann dein Ziel in einem kurzen Absatz neu ein. Lass später den Agent ein Übergabe-Dokument schreiben, öffne eine frische Session, füg es ein und fahr fort. Beachte, wie viel schärfer sich die frische Session anfühlt. Du hast gerade deinen Kontext engineert, statt ihn dich engineern zu lassen.

Nächste Lektion

Du kannst Regeln, Skills, Hooks, MCP, Multi-Agent-Arbeit und Kontext managen. Die letzte Lektion dieses Kurses stellt das Pro-Setup zusammen, das alles verbindet: eine eigene Status Line, die Handvoll CLI-Flags, die du täglich nutzt, und Sessions von deinem Handy oder der Cloud aus laufen lassen, damit Bauen nicht an einen Schreibtisch gebunden ist.