JIT-Kontext: Warum die besten Agenten spät und sparsam laden

Während des Großteils der Ära der KI-Agenten glich die Kontextstrategie einem Umzugswagen: Man lud alles, was der Agent möglicherweise benötigen könnte – das Handbuch mit den Konventionen, den vollständigen Tool-Katalog, das Referenzmaterial – vorab in das Fenster und hoffte, dass das Modell die relevanten Teile findet. Ein wachsendes Muster im Kontext-Engineering kehrt dies nun um. JIT-Kontext – JIT steht für „Just-in-Time“, genau wie bei den Just-in-Time-Compilern in Ihrem Browser – ist das Muster, das Anthropic in seinem Leitfaden zum Kontext-Engineering in den Mittelpunkt der Disziplin stellt: Es hält das Fenster nahezu frei von Payloads und stattdessen gefüllt mit Zeigern: Der Agent weiß, was existiert – Skills anhand ihrer Metadaten, Daten anhand ihrer Referenzen, Tools anhand eines schlanken Index – und die umfangreichen Inhalte werden erst in dem Moment geladen, in dem sie benötigt werden, und anschließend wieder freigegeben. Für viele langlebige Agenten entwickelt sich der JIT-Kontext zum sichereren Standard, während das Vorabladen aller Daten zur bewussten Ausnahme wird. Dieser Beitrag beschreibt das Engineering dieser Umkehrung – was spät geladen werden sollte, was zwingend vorab geladen bleiben muss und warum JIT-Kontext letztlich eine Laufzeiteigenschaft und keine Prompting-Gewohnheit ist.

Lucia, eine Plattform-Ingenieurin, erbte einen Agenten, dessen Systemkontext wie ein Dachboden zugemüllt war. Jemand hatte das vollständige technische Handbuch vorab geladen, „damit er die Konventionen einhält“. Jemand anderes hatte alle vierzig Tool-Beschreibungen eingefügt, „damit er seine Optionen kennt“, und dann dreitausend Zeilen API-Referenz, „damit er nicht mehr raten muss, wie die Schemata aussehen“. Jede Ergänzung hatte ihren Grund; das Ergebnis war ein Agent, der jeden Durchlauf mit einem bereits fast vollständig belegten Fenster begann, für dieses unnötige Gewicht bei jedem seiner dreißig Schleifenschritte erneut bezahlte und – der Punkt, der schließlich für Aufmerksamkeit sorgte – schlechter abschnitt als ein abgespeckter Prototyp bei denselben Aufgaben. Die Lösung, die funktionierte, wirkte in ihrer Einfachheit fast beleidigend: Entfernen Sie fast alles, lassen Sie nur einzeilige Beschreibungen dessen zurück, was existiert und wo es zu finden ist, und lassen Sie den Agenten den Handbuchabschnitt, das Schema oder das Verfahren genau in dem Moment abrufen, in dem ein Schritt es tatsächlich erfordert. Gleiches Wissen, andere Zeitform. Der Dachboden wurde zu einer Bibliothek mit Katalog.

Dieses Refactoring hat jetzt einen Namen – JIT-Kontext – und es konvergiert aus drei Richtungen: Anthropic’s Leitfaden zum Kontext-Engineering (September 2025) machte das Abrufen zur Laufzeit gegenüber dem Vorabladen zu einem Kernprinzip; das Skills-Ökosystem etablierte „Progressive Disclosure“ als Lademodell für verpacktes Wissen; und Entwickler von Frameworks machten das Auslagern und die Isolierung zum Standardverhalten zur Laufzeit. Dieser Beitrag verbindet diese Fäden Schicht für Schicht und endet bei der Frage, die Kontext-Beiträge in dieser Serie immer erreichen: Wer sollte diese Arbeit erledigen – Ihre Prompt-Autoren oder die Laufzeitumgebung unter ihnen?

1. Vom Umzugswagen zum Katalog: Die Umkehrung

Der Instinkt, alles vorab zu laden, ist in einer Chat-Welt rational. Ein Austausch in einem einzigen Schritt hat nur eine Chance auf Kontext, also lädt man alles vorne rein; im schlimmsten Fall ignoriert das Modell den Überschuss. Agenten haben beide Annahmen gebrochen. Eine Schleife sendet ihr Fenster bei jedem Schritt erneut, sodass Überschüsse wiederholt und nicht nur einmal berechnet werden. Und der Überschuss wird nicht ignoriert – Forschung zu langem Kontext und die Erfahrung von Praktikern bestätigen, dass Modelle an Leistung verlieren, wenn Fenster mit Text geringer Relevanz gefüllt sind; ein Fehlerzustand, den die Community als „Kontext-Fäulnis“ bezeichnet. Der Ansatz des Bedienungsanleitung-Lesens – alles lesen, bevor man auf Start klickt – führt dazu, dass ein Agent gleichzeitig langsamer, teurer und dümmer wird.

JIT-Kontext kehrt den Standard um. Die ständigen Inhalte des Fensters schrumpfen auf das wirklich Notwendige (Aufgabe, Kernanweisungen, aktuelle Schritte) plus einen Katalog – kompakte Beschreibungen dessen, was existiert und wie man darauf zugreift: ein Skill als Name und ein Satz, ein Datensatz als Pfad, ein früheres Ergebnis als Handle. Wenn ein Schritt die Payload benötigt, ruft der Agent (oder das Framework in seinem Namen) sie ab, verwendet sie und lässt sie danach wieder aus dem aktiven Fenster fallen. Die Formulierung von Anthropic sollte man verinnerlichen: Behalten Sie leichtgewichtige Identifikatoren bei, laden Sie Daten zur Laufzeit. Das Fenster hört auf, ein Lagerhaus zu sein, und wird zur Werkbank.

2. Die Abstammung: Progressive Disclosure, dreißig Jahre später

Das Muster ist nicht neu – es ist bewusst aus dem Interface-Design entlehnt. „Progressive Disclosure“ ist das UX-Prinzip aus den 1990er Jahren, das besagt, dass Benutzer, denen fünfzig Einstellungen gleichzeitig gezeigt werden, erstarren, während Benutzer, denen drei Einstellungen und ein „Erweitert“-Schalter gezeigt werden, erfolgreich sind; man enthüllt Komplexität erst im Moment der Absicht, nicht vorher. Die Community hat sich explizit zu dieser Übertragung bekannt: Ein Agent, dessen Fenster mit allem vollgestopft ist, was er möglicherweise brauchen könnte, verliert genau so an Effektivität wie ein Benutzer, der vor einem überladenen Bildschirm sitzt – und das Heilmittel ist dieselbe Staffelung der Informationen. Der Agent weiß, dass eine Fähigkeit existiert – das sind die Metadaten, immer sichtbar, kostengünstig. Das volle Gewicht der Fähigkeit – Anweisungen, Skripte, Referenzdateien – bleibt hinter dem Schalter verborgen, bis der Agent entscheidet, sie zu nutzen.

Der Name selbst trägt eine Herkunft in sich, die es wert ist, übernommen zu werden. Wenn Sie einen Informatik-Hintergrund haben, ist die engste Analogie dazu JIT-Kompilierung: Anstatt ein gesamtes Programm im Voraus zu kompilieren, übersetzt ein JIT-Compiler jeden Teil genau in dem Moment, in dem er ausgeführt wird – wenn die Laufzeitumgebung weiß, dass der Codepfad tatsächlich durchlaufen wird, und über aktuelle Informationen zur Verwendung verfügt. Der Vorteil ist zweifach: Man zahlt nicht für die Kompilierung von Code, der nie ausgeführt wird, und die Kompilierung ist fundierter, da sie mit dem Kontext der Laufzeitumgebung erfolgt. JIT-Kontext lässt sich fast exakt darauf übertragen. Preloading ist eine Vorab-Kompilierung: Man investiert Aufmerksamkeit und Token für alles, was eventuell benötigt werden könnte, und entscheidet dies, bevor die Aufgabe offenbart, was sie tatsächlich erfordert. JIT-Kontext verschiebt das Laden auf den Moment der Verwendung – die Referenz im Fenster ist das Symbol, das die Laufzeitumgebung auflösen kann, und die Aktivierung des Agenten ist der Aufrufpunkt, der die Auflösung auslöst. Die Lektion ist dieselbe, die Compiler-Entwickler vor Jahrzehnten gelernt haben: Alles im Voraus bereitzuhalten ist teurer als das Abrufen bei Bedarf. Und wenn das Abrufen richtig gemacht wird, ist es kostengünstig und zielgerichteter, weil es erst dann geschieht, wenn man endlich weiß, was die Aufgabe benötigt.

Was die Übertragung mehr als nur zu einer Metapher macht, ist die Tatsache, dass die Ladegrenze softwareseitig durchsetzbar ist. Eine Benutzeroberfläche kann Benutzer nur zur richtigen Offenlegung ermutigen; ein System kann sie implementieren – und mechanisch entscheiden, was wann in das Fenster gelangt, genau wie ein virtuelles Speichersystem entscheidet, was im Arbeitsspeicher resident ist. Diese Analogie (Kontextfenster als RAM, externe Speicher als Festplatte, das System als Paging-Mechanismus) ist die systemtechnische Sichtweise, um alles Folgende zu verstehen: JIT-Kontext ist Paging für Aufmerksamkeit.

‍

3. Warum es gewinnt: Aufmerksamkeit, Kosten, Aktualität

Drei sich verstärkende Effekte machen das Muster rentabel. Aufmerksamkeit: Jedes vorab geladene Token konkurriert mit der Aufgabe um den Fokus des Modells, und die Verschlechterung ist kein linearer Prozess – irrelevante Datenmengen beeinträchtigen die Leistung bei den wichtigen Dingen aktiv. Deshalb hat Lucias abgespeckter Prototyp den voll geladenen Produktionsagenten geschlagen. JIT ist die architektonische Verteidigung gegen Kontext-Verfall: Das Fenster enthält nur Signale, weil Rauschen gar nicht erst zugelassen wurde. Kosten: In einer Schleife wird das Fenster bei jedem Schritt erneut gesendet, sodass ein vorab geladenes Handbuch nicht einmal, sondern dreißigmal bezahlt wird; die Arithmetik unseres Token-Verbrauchs greift hier, und JIT setzt am größten Kostenfaktor an – dem ständigen Ballast, der überall mitgeschleppt wird. Aktualität: Eine vorab geladene Kopie ist eine Momentaufnahme, die mit fortschreitendem Ablauf veraltet, während eine Referenz zum Zeitpunkt der Verwendung auf den aktuellen Stand der Datei, des Tickets oder der Datenbank zugreift – für langlebige Agenten ist das späte Laden nicht nur günstiger, sondern auch korrekter.

Die ehrliche Bilanz: JIT erkauft sich diese Vorteile durch eine Abruflatenz bei den Ladeschritten (die im Vergleich zu einem Modellaufruf meist trivial, aber nicht null ist), einen neuen Fehlertyp (eine nicht auflösbare Referenz muss als echter Fehler und nicht als halluzinierte Nutzlast erscheinen) und eine Abhängigkeit von der Beschreibungsqualität – der Agent lädt basierend auf den Einzeilern aus dem Katalog, sodass ein schlechter Stub eine gute Nutzlast verbergen kann. Nichts davon entkräftet das Urteil; all diese Punkte gehören in das Design.

4. JIT-Fähigkeiten: Metadaten vorab, Prozedur bei Aktivierung

Bei Skills wird dieses Muster am deutlichsten, da das SKILL.md-Ökosystem genau darauf ausgelegt ist. Ein Skill liegt zunächst inaktiv als Verzeichnis vor; was der Agent standardmäßig sieht, sind die Metadaten – ein Name und eine prägnante Beschreibung. Die eigentlichen Inhalte (Schritt-für-Schritt-Anleitungen, Referenzdateien, Skripte) werden erst dann geladen, wenn der Agent den Skill aktiviert, weil die Aufgabe dazu passt. Das ist Progressive Disclosure als Lademodell, und es verändert das Potenzial einer Skill-Bibliothek: Ein Unternehmen kann Dutzende tiefgreifende Verfahren vorhalten, ohne dass ein Agent für mehr als den Katalog bezahlen muss, da die Tiefe erst bei Nutzung Kosten verursacht. Die Anwender lernen schnell: Die Beschreibung ist das tragende Element – sie ist die alleinige Grundlage für die Entscheidung des Agenten, den Skill zu laden. Daher ist ein langweiliger, präziser Stub besser als ein cleverer.

Auf TrueFoundry ist dies das Standardverhalten der Skills Registry: versionierte SKILL.md-Artefakte, veröffentlicht mit RBAC, referenziert per Name und bei Bedarf eingebunden in den Lauf. Die Registry ergänzt das, was der lokalen Version fehlt – die Herkunft der JIT-geladenen Payloads: Mit Versionierung, RBAC und Audit-Historie können Teams die Frage „Welche Verfahrensversion wurde für diesen Lauf verwendet?“ zu einem prüfbaren Fakt machen, statt zu raten. Das ist genau deshalb wichtig, weil der Inhalt nicht statisch in einem überprüfbaren Prompt liegt. JIT-Laden ohne Versionierung ist dynamisches Verhalten ohne Audit-Trail; die Registry schließt diese Lücke.

5. JIT-Daten: Ausgelagerte Ergebnisse und Code-Modus

Die zweite Ebene sind Tool-Ergebnisse – bei langen Läufen oft der größte Teil des Kontextfensters. Die naive Schleife fügt eine 38.000-Token-API-Antwort in den Kontext ein, weil Ergebnisse dort nun einmal landen. JIT kehrt dies um durch Auslagerung großer Ergebnisse: Das Payload landet im Speicher, das Fenster erhält einen kompakten Verweis (was es ist, wie groß, wo es liegt), und der Inhalt wird nur abgerufen, wenn ein späterer Schritt ihn tatsächlich lesen muss. Dasselbe Prinzip findet sich in modernen Agentensystemen: Umfangreiche Ausgaben werden extern gehalten, während das Modell mit prägnanten Vorschauen oder Referenzen statt mit Rohdaten arbeitet, und alte Tool-Ausgaben werden direkt durch Pointer ersetzt.

Der Code-Modus ist die stärkere Form: Viele Schritte vom Typ „Daten lesen“ benötigen die Daten überhaupt nicht im Fenster – sie benötigen lediglich eine Berechnung darauf. Zehntausend Log-Zeilen filtern, zwei Exporte zusammenführen, Fehler nach Typ zählen: Der Agent schreibt Code, der auf dem ausgelagerten Payload in einer Sandbox ausgeführt wird und das Ergebnis zurückgibt – drei Zeilen im Kontext statt zehntausend. Das Fenster enthält die Schlussfolgerungen; die Sandbox enthält die Datenmenge. Beide Verhaltensweisen sind Standard der Context-Engineering-Suite des Harness, wo sie auch hingehören: Kein Modell lässt sich per Prompt dazu bringen, kein Payload zu empfangen – nur die Laufzeitumgebung, die das Modell speist, kann entscheiden, was hineingelangt.

Auf der untersten Ebene ist die Mechanik unspektakulär, aber einmal sehenswert. Der Harness fängt das Tool-Ergebnis ab, bevor es zur Nachricht wird; überschreitet es den Inline-Schwellenwert, wandert das Payload in den laufspezifischen Speicher und das Modell erhält den Verweis – typisiert, dimensioniert, adressierbar. So bleibt die von der API geforderte Konversationsstruktur intakt, während der Token-Bedarf um drei Größenordnungen sinkt:

Was das Modell tatsächlich sieht: Auslagerung und Code-Modus auf Nachrichtenebene (illustrativ)

// Step 9, naive loop: the raw payload becomes the message — 38,120 tokens,
// re-sent on every subsequent step of the run.

// Step 9, JIT loop: the harness offloads and substitutes a handle — 41 tokens.
{ "role": "tool", "content": {
    "offloaded": true,
    "ref": "tfy://runs/8c2e/steps/9/result",
    "content_type": "application/json",
    "tokens": 38120,
    "preview": "orders[] — 4,212 records, fields: id, status, region, total"
} }

// Later step, code mode: the agent computes over the payload in the sandbox
// — the answer enters the window; the 4,212 records never do.
df = read_ref("tfy://runs/8c2e/steps/9/result")
failed = df[df.status == "failed"].groupby("region").total.sum()
print(failed.to_dict())   # → {"emea": 41230.50, "apac": 9120.00}

Zwei Implementierungsdetails unterscheiden eine robuste Version hiervon von einer fragilen. Die Vorschauzeile leistet echte Arbeit – sie ist der Katalogeintrag, der dem Modell erlaubt zu entscheiden, ob ein späterer Abruf gerechtfertigt ist; daher sollte sie Schema und Struktur enthalten, nicht nur eine Byte-Anzahl. Und in einer robusten Implementierung sollten Verweise laufspezifisch und zugriffsgeschützt sein wie jede andere Ressource: Eine Referenz, die das Modell ausgeben kann, ist eine Referenz, die ein injizierter Prompt abfragen kann. Daher erfolgt die Auflösung über dieselbe Gateway-Autorisierung wie ein Tool-Aufruf.

6. JIT-Aufmerksamkeit: Sub-Agenten und kuratierte Tool-Oberflächen

Das Muster lässt sich von Inhalten auf Arbeitübertragen. Eine kontextintensive Teilaufgabe – etwa die Untersuchung eines Log-Archivs oder das Durchsuchen von Dateien – kann per JIT an einen Sub-Agentendelegiert werden: Ein neues, isoliertes Fenster übernimmt die Exploration, und nur das destillierte Ergebnis kehrt zurück. Das Fenster des übergeordneten Prozesses enthält die Untersuchung zu keinem Zeitpunkt, genau wie ein JIT-Fenster niemals das ungelesene Handbuch enthält – die Delegationsebene unseres Spektrums aus Tools, Fähigkeiten und Sub-Agenten fungiert hier als Kontextinstrument. Dieselbe Logik gilt für Tool-Oberflächen: Vierzig vorinstallierte Beschreibungen beanspruchen permanent Aufmerksamkeit. Die JIT-Haltung setzt daher auf ein kuratiertes, aufgabenrelevantes Set (gesteuert über die Preload-Tools des Harness), während der „Long Tail“ bei Bedarf abrufbar bleibt – so werden minimale Aufmerksamkeit und das Prinzip der geringsten Rechte zur selben Konfiguration.

Und wenn die Historie eines langen Laufs selbst zum Ballast wird, ist Kompaktierung das Gegenstück zur oben genannten Prävention: Fassen Sie das Transkript zusammen, bewahren Sie Entscheidungen und offene Fäden auf, verwerfen Sie die verbrauchten Details. Ein verwalteter Prozess atmet – Referenzen sammeln sich an, Payloads werden verarbeitet, Zusammenfassungen ersetzen die Historie –, anstatt monoton bis zur Belastungsgrenze vollzulaufen.

JIT-Kontext als Konfiguration, nicht als Prompting-Heldentum (illustrativ)

agent:
  name: support-investigator
  model: claude-sonnet-4-6
  instructions: ./core.md@v6          # the stable prefix — small, cached, preloaded
  skills:                              # catalog resident; SKILL.md mounts on activation
    - refund-policy@v7
    - incident-runbook@v3
  mcp_servers:
    - support-db: [lookup_ticket]      # curated surface resident; long tail on demand
  subagents:
    - { name: log-analyzer, mcp_servers: [logs-readonly] }   # JIT a whole subtask
  harness:
    tool_results: { max_inline_tokens: 4000 }   # larger results offloaded, handle in window
    code_mode: enabled                 # compute over payloads instead of reading them
    compaction: { trigger_fill: 0.6 }  # history summarized before it rots

Die oben genannten Feldnamen dienen der Veranschaulichung und stellen kein verbindliches Schema dar. Beachten Sie insbesondere, dass Sub-Agenten primär ein Kontextisolierungs- Mechanismus sind – sie halten eine schwere Teilaufgabe aus dem Fenster des übergeordneten Prozesses fern –, keine Berechtigungsgrenze. Wenn Sie eine strikte Trennung von Berechtigungen benötigen, setzen Sie diese durch separate Agenten oder begrenzte MCP-Zugriffsrechte mit eigenen Anmeldedaten durch, nicht durch das Verschachteln eines Sub-Agenten.

7. Was man nicht per JIT einbinden sollte: das stabile Präfix

Eine ehrliche Betrachtung muss auch die andere Grenze ziehen, denn „alles per JIT“ ist ein eigenes Fehlermuster. Das Anfangssegment des Fensters – Kernanweisungen, die wesentlichen Tool-Beschreibungen, die feste Identität des Agenten – sollte vorinstalliert und Byte-stabilsein, und zwar aus ökonomischen wie kognitiven Gründen: Das Prompt-Caching der Anbieter macht ein stabiles Präfix bei jedem nachfolgenden Aufruf drastisch günstiger. Ein Präfix, das sich verschiebt, weil es „dynamisch optimiert“ wurde, bricht den Cache und führt zu einer erneuten vollständigen Abrechnung des Segments. JIT-en Sie das variable Suffix; frieren Sie das Präfix ein – und setzen Sie den Cache-Breakpoint bewusst an die Grenze, da Anbieter das markierte Präfix cachen und das Suffix frisch abrechnen. Ein JIT-Mount, der dort landet, oben der Breakpoint macht das gesamte zwischengespeicherte Segment stillschweigend ungültig. Die beiden Muster stehen nicht im Widerspruch zueinander – es handelt sich um dieselbe Disziplin, die auf Inhalte mit unterschiedlichen Änderungsraten angewendet wird. Der Praxistest ist einfach: Wenn etwas in den meisten Schritten benötigt wird und sich selten ändert, laden Sie es vor und halten Sie es stabil; wenn es nur in wenigen Schritten benötigt wird oder sich während des Ablaufs ändert, katalogisieren Sie es und laden Sie es erst bei Bedarf.

Der Test führt zu einer Standardeinstellung je nach Inhaltsart:

‍