Context Engineering: Derfor bliver din agent dummere ved tur 40

Anthropic trak grænsen i september 2025, og de to sætninger hører til side om side. Prompt engineering er „metoder til at skrive og organisere LLM-instruktioner for optimale resultater”. Context engineering er „sættet af strategier til at kuratere og vedligeholde det optimale sæt tokens (information) under LLM-inference, inklusive al den anden information, der kan lande der uden for prompts”.¹

Den operative forskel er hvornår, og af hvem. En prompt forfattes én gang, af et menneske, og gennemgås. En context samles ved hvert kald, af kode som ingen kigger på, ud af materiale som ingen har skrevet i hånden: fyrre ture historik, seks værktøjsresultater, fire retrieved passager, en brugerprofil, tolv JSON-skemaer. Kapitel 15 målte, hvad bedre instruktioner giver. Dette kapitel handler om de andre halvfems procent af tokens, som ankommer af sig selv.

Det samme dokument navngiver den ressource, som de alle bruger: modeller „har et attention budget, som de trækker på, når de parser store mængder context. Hver ny token, der introduceres, opbruger en del af dette budget”. Og det navngiver symptomet: „når antallet af tokens i context window stiger, falder modellens evne til præcist at genkalde information fra den context” — context rot.¹

Den sidste sætning er en påstand om adfærd, hvilket betyder, at den kan tjekkes, og tabellen øverst på denne side er tjekket.

Fyrre linjer mod det lokale endpoint fra Kapitel 22 — en lille Python-server, der holder Qwen2.5-0.5B-Instruct på CPU’en og taler chat-completions-formen, så loopet bliver i TypeScript, og tensorerne bliver på den anden side af porten.

const DEPTHS = [0, 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, 0.875, 1];

for (const d of DEPTHS) {
  const slot = Math.round(d * (N - 1));
  let hits = 0, other = 0;
  for (let t = 0; t < TRIALS; t++) {
    const recs = buildRecords(N, 1000 + t);          // 25 unique tickets
    const gold = recs[Math.floor(rng(7 + t)() * N)]; // a different one each trial
    const rest = recs.filter((x) => x.ticket !== gold.ticket).slice(0, N - 1);
    const lines = [...rest.slice(0, slot).map((x) => x.line),   
                   gold.line,                                   
                   ...rest.slice(slot).map((x) => x.line)];     
    const r = await complete(prompt(lines, ask(gold.owner)), { maxTokens: 12 });
    const said = /\d{4}/.exec(r.text)?.[0];
    if (said === String(gold.ext)) hits++;
    else if (said && recs.some((x) => String(x.ext) === said)) other++;
  }
}

other-tælleren er det, der gør et skuffende resultat nyttigt: når modellen tager fejl, er den så lost, eller er den confident?

Svaret er confident. På tværs af de otte ikke-første positioner var 136 af de 205 forkerte svar en anden sags lokalnummer — et ægte firecifret tal, korrekt formateret, læst fra den forkerte linje. Ved position 1 var kun én af de fem fejl det; ved position 7 var enogtyve af seksogtyve det.

Den forskel er det, der betyder noget i produktion. En model, der siger jeg kan ikke finde det, er en bug, du opdager; en model, der returnerer naborækkens nummer, er en bug, du shipper, fordi de to ser identiske ud på skærmen. Det er den fejl, Kapitel 19 byggede verificerbare citater imod, nu ankommet indefra prompt i stedet for fra indekset.

Position er den ene akse. Længde er den anden, og nemmere at teste: behold svaret i midten og lad listen vokse.

Én post og 97 tokens: 90 %. Tre poster og 159 tokens: 55 %. Otte poster og 315 tokens: 15 %, og derfra fladt og lavt hele vejen ud til 140 poster og 4.477 tokens. Hele kollapset sker mellem den første og den ottende linje i en liste.

Den sidste kolonne er alt, der hverken er det rigtige lokalnummer eller en anden posts, hvilket med en enkelt post på siden er det eneste sted, et forkert svar kan lande. De to fejl ved én post er værd at rapportere i stedet for at runde væk, fordi ingen af dem var en afvisning: ét svar var 5806 til et register, hvis eneste linje siger 5805. Ved 97 tokens med en enkelt kandidat fejlkopierer denne model stadig et ciffer to gange ud af tyve, og det er gulvet, alt andet måles imod.

To ting følger. En større context køber retten til at sende mere, ikke sikkerheden for at blive læst: denne model har et 32.768-token context window og et arbejdsområde, på denne opgave, på nogle få hundrede tokens. Og der er ingen tærskel, ingen klippe, ingen „context fuld”-tilstand — nedbrydningen er i gang ved tredje post og fuldendt ved den ottende, ved én procent af vinduet. Hvad end en context limit er, er det ikke det, der styrer dette.

To mekanismer tilbydes normalt. Den første er aritmetikken fra Kapitel 9, som Anthropic formulerer på samme måde som dette kursus: modeller „er baseret på transformer-arkitekturen, som gør det muligt for hver token at attend to hver anden token på tværs af hele context. Det resulterer i n² parvise relationer for n tokens”.¹ Attention over en længere sekvens er ikke den samme operation anvendt på mere materiale; det er ét fast budget af sandsynlighedsmasse fordelt over flere konkurrenter. Den anden er træning: modeller ser langt flere korte sekvenser end lange, så langtrækkende positionsmønstre er den mindst øvede del af netværket. Det er et argument, ikke en måling, og dette kapitel kan ikke afgøre det.

Det, der er afgjort, er formen, og har været det siden 2023. Liu et al. testede multi-document question answering og key-value retrieval på tværs af modelfamilier og størrelser og fandt, at „performance ofte er højest, når relevant information forekommer i begyndelsen eller slutningen af input-context, og falder markant, når modeller skal tilgå relevant information i midten af lange contexts, selv for eksplicitte long-context models”.² Kapitel 15 tog sin positionsregel fra den artikel; Kapitel 19 tog derfra årsagen til, at tyve retrieved chunks kan score dårligere end fire. Den praktiske form af kendsgerningen er den eneste sætning her, du bør handle på: det tager fem minutter at måle på din egen model med dine egne data, og ingen publiceret kurve erstatter din.

Spørg et team, hvad der fylder deres agents context, og du får et estimat, fordi ingen API returnerer svaret: response giver dig prompt_tokens, ét tal for det hele.

Du kan genskabe opdelingen med fire tællinger og tre subtraktioner — hele den renderede prompt, den samme uden værktøjsdefinitioner, systembeskeden alene med og uden dem, og alt med værktøjsresultaterne fjernet:

async function buckets(messages: Msg[]) {
  const sys = messages.slice(0, 1);
  const withoutResults = messages.filter((m) => m.role !== "tool");
  const [total, sysWithTools, sysNoTools, noResults] = await Promise.all([
    countPrompt(messages, CATALOGUE),        // everything
    countPrompt(sys, CATALOGUE),             // system + scaffolding + schemas
    countPrompt(sys),                        // system + scaffolding
    countPrompt(withoutResults, CATALOGUE),  // everything but tool output
  ]);
  return {
    system: sysNoTools,
    tools: sysWithTools - sysNoTools,                                  
    toolResults: total - noResults,                                    
    conversation: total - sysWithTools - (total - noResults),          
    total,
  };
}

countPrompt anvender modellens egen chat-template før tokenisering, hvilket betyder mere, end det lyder som: din tekst er ikke det, der bliver talt. Rollemarkører, tool-calling-preamble og skemarenderingen er alle tokens, du betaler for og aldrig har skrevet. Kapitel 7 byggede en tokenizer, og Kapitel 16 talte med js-tiktoken; her kommer tællingen fra den samme model, der skal læse prompt, hvilket er den eneste tælling, der er præcis rigtig.

Kør nu en rigtig agent igennem den: fyrre ture i en hændelsesundersøgelse, tolv værktøjer, et falsk operationsmiljø, der returnerer realistiske log-dumps og metrikserier.

Læs den første række op mod den sidste.

Ved tur 1 er prompt 2.547 tokens, og 71 % af den er værktøjsdefinitioner. System prompt er 3 %. Det, brugeren skrev, er 6 %. Agent har endnu ikke gjort noget og bærer allerede 1.817 tokens JSON-skema.

Ved tur 40 er prompt 10.632 tokens, og andelene er vendt på hovedet: definitioner 17 %, samtale 29 %, værktøjsresultater 53 %. Værktøjsoutput overhalede definitionerne ved tur 5; samtalen overhalede dem først ved tur 25, så i de første tres procent af sessionen var værktøjskataloget større end alt, hvad der var blevet sagt.

Så totalen. På tværs af 57 modelkald fakturerede kørslen 370.291 input tokens for en endelig context på 10.632 — den sidste prompt betalt for omtrent femogtredive gange, hvilket er Kapitel 16’s kvadratiske vækst med en agents multiplikator oveni. Af de 370.291 var 103.569, eller 28 % af alt faktureret, de tolv værktøjsdefinitioner, gensendt byte-identisk ved hvert kald.

Værktøjskataloget er den største faste omkostning i en agent, og den er usynlig, fordi du aldrig ser den: du sender et array af objekter, og provider renderer det ind i prompt for dig. Målt på de samme tolv værktøjer:

system prompt + chat scaffolding, no tools:        85 tokens
all twelve definitions:                          1,817 tokens
  of which fixed tool-calling scaffolding:         126 tokens
three tools instead of twelve:                     605 tokens
same twelve, one-sentence descriptions,
  no parameter prose:                            1,291 tokens  (-29 %)

Per værktøj løber den marginale omkostning fra 80 tokens for get_current_time, som tager én string, til 263 for search_tickets, som tager fire parametre med en enum og en vejledende sætning hver. Det er vekselkursen bag Kapitel 18’s centrale råd om, at beskrivelsen er API’en: en god beskrivelse koster omkring hundrede tokens på hver request resten af agentens liv. Tre konsekvenser.

Et værktøj, du ikke bruger, faktureres stadig. Agent kaldte syv af de tolv. De andre fem kostede 697 tokens på hver af de 57 requests — 39.729 i alt, mere end en tiendedel af alt, kørslen blev faktureret for, for kapabiliteter den aldrig rørte. Én af de fem bærer den skarpeste detalje i tracet: modellen forsøgte tre gange at kalde read_log, som ikke findes. Værktøjet, den ville have, var search_logs, den næstdyreste definition i kataloget med 237 tokens. Den betalte for den definition 57 gange, brugte den aldrig og fandt aldrig dens navn.

At trimme prosa er den billigste optimering, der findes, og det er en trade. At skære beskrivelser ned til én sætning og droppe parameterdokumentation sparede 526 tokens per kald, 29 procent, uden at røre en linje logik — og fik modellen til at kalde værktøjerne dårligere, hvilket er det, Kapitel 18 målte. Pointen er, at begge sider af den trade nu er i samme enhed.

Ved en vis skala holder det op med at give mening overhovedet at sende definitioner. Anthropic satte tal på det i november 2025: et stort sæt forbundne servere betyder behandling af „hundredtusindvis af tokens” af definitioner, før request læses, og at erstatte det med kodeeksekvering — agent opdager og loader kun de definitioner, den har brug for — „reducerer token-forbruget fra 150.000 tokens til 2.000 tokens, en tids- og omkostningsbesparelse på 98,7 %”.³ Samme idé som resten af dette kapitel, anvendt på skemaer i stedet for historik: behold indekset, slå posten op on demand.

To ting blev plantet i det fyrreturs-transcript. Ved tur 2, før noget reelt arbejde, angiver brugeren en stående regel: enhver sag, du åbner, skal registreres under mit medarbejdernummer, 4417. Ved tur 19, midt i hændelsen, en oplysning: den berørte shard er pay-shard-7, bekræftet af betalingsteamet. Ved tur 40 beder brugeren agent om at åbne hændelsessagen, som kræver begge. Hver probe stilles i seks forskellige formuleringer og scores ud af seks — greedy decoding er deterministisk, så ét kald giver et uigentageligt ja eller nej, og seks giver en rate.

Transcript afspilles derefter under syv context policies. Afspillet igen snarere end kørt igen, bevidst: beskederne, værktøjskald og værktøjsresultater er byte-identiske i alle syv, så den eneste variabel er hvad hver policy valgte at beholde. Kapitel 16 viste, hvorfor et sliding window er et dårligt økonomisk træk, fordi det ødelægger det cachebare prefix. Her er, hvad det gør ved adfærd:

Compaction-rækkerne inkluderer det, compaction kostede: 18.581 input tokens for syv summaries og 3.392 mere for note-takeren. Kontrolrækken er der, så et nul kan læses som et nul — med de to beskeder alene i en 1.981-token prompt besvarer denne model begge probes perfekt, så ingen række handler om, at opgaven er for svær.

Fuld historik husker, og er det dyreste på bordet: 370.291 input tokens for en session, hvis varige indhold er to sætninger.

Det besvarer et spørgsmål, åbningen lod stå åbent. Hvorfor rummer et transcript på 10.632 tokens en oplysning, som et register på 853 tokens mister? Fordi længde er den forkerte variabel. Registeret rummer femogtyve firecifrede lokalnumre i femogtyve identiske sætninger — fireogtyve næsten perfekte lokkeduer for den ene, du vil have. Transcript rummer præcis ét medarbejdernummer og ét shard-navn. Context rot er interference, før det er volume, hvilket er grunden til, at 136 af de 205 forkerte svar deroppe var en naboværdi. Det nyttige spørgsmål om et vindue er ikke, hvor langt det er; det er, hvor mange ting i det der ligner svaret.

Sliding window er 57 % billigere og har mistet hændelsen. Medarbejdernummeret overlever kun, fordi agent havde gentaget det ind i de seneste ture. Shard, angivet én gang ved tur 19, er ikke i de sidste tolv beskeder — og modellen siger det ikke. Spurgt seks gange svarede den „den berørte payment shard er shard 4417”, idet den rakte ud efter medarbejdernummeret, den eneste anden identifikator tilbage i vinduet, og to gange „pool”, løftet ud af strengen pool_exhausted i en loglinje.

Compaction er billig og mistede den samme oplysning. Syv summaries, skrevet af modellen under en eksplicit instruktion om at beholde identifikatorer, tal, stående instruktioner og åbne spørgsmål, og pay-shard-7 er ikke i nogen af dem, der betød noget; de seks gæt var shard 1, pay_shard_1 og pool. Compaction fejler ikke højlydt. Den producerer en flydende, plausibel, meget kortere session, der stille har tabt én linje.

Tre rækker scorede 0/6 på tur-19-faktummet — sliding window, compaction og compaction med noter. Atten forkerte svar mellem dem, og ikke ét af dem var „det ved jeg ikke.”

Så rækken, der burde være pinlig. At beholde brugerens egne fyrre beskeder ordret, plus de sidste fire ture fuldt ud og intet andet, koster 168.550 tokens — 54 % mindre end fuld historik — og besvarer begge probes lige så godt som fuld historik eller bedre. Ingen summariser, ingen note-taker, ingen anden model: et filter på role === "user". Brugerens ord er de billigste højværdi-tokens i en agents vindue, og de fleste designs smider dem ud sammen med alt andet.

De sidste to rækker er åbningstabellen igen, inde i agent. Den samme pinned blok, flyttet fra systembeskeden til slutningen af prompt: 5/6 bliver 6/6. På seks forsøg er det ikke en signifikant forskel og tilbydes ikke som en — det tilbydes som en påmindelse om, at hvor er en parameter, du sætter, uanset om du ved det eller ej.

De fire strategier nedenfor er Anthropics, i deres rækkefølge, selvom kun de sidste tre er deres long-horizon-liste.¹ Alle fire er variationer over én instruktion: bær ikke det, du kan hente, og bær ikke råt det, du kan bære komprimeret.

const elide: Policy = (h) => [SYSTEM, ...h.flatMap((turn, ti) =>
  turn.map((m) => (ti < h.length - 4 && m.role === "tool"
    ? { role: "tool", name: m.name,
        content: `[${m.name} result from turn ${ti + 1}, ${m.content.length} chars, ` +
                 `elided; call ${m.name} again with the same arguments to re-read it]` }
    : m)))];

const r = await complete([
  { role: "system", content:
      "You keep a durable note file for a support session. Given one user message, " +
      "output one short note ONLY if it states a standing rule, an identifier or a fact " +
      "that must survive the rest of the session. Otherwise output exactly NONE." },
  { role: "user", content: `Turn ${i + 1}: ${user}` },
], { maxTokens: 40 });
if (!/^none\b/i.test(r.text.trim())) notes.push(`turn ${i + 1}: ${r.text.trim()}`);

Sub-agent er ikke i tabellen ovenfor, fordi den ikke kører i fyrre ture: den kører én gang, i et vindue som nogen har afgrænset for den. Givet system prompt, ture 17 til 19 og intet andet — 2.737 tokens — besvarede den shard-proben 6/6, bedre end enhver policy i tabellen, og medarbejder-proben 0/6, fordi det nummer ikke er i de tre ture, den fik.

Det er sub-agents i to tal: et rent vindue er ikke intelligens, det er scope, og scoping gøres på forhånd af kode, der allerede skal vide, hvilke ture der betyder noget. Én ting mere i de svar er værd at beholde. Dette var den eneste policy, der svarede „Ingen tilgængelig” i stedet for at opfinde noget. En model med en lille, sammenhængende context ved, hvad den mangler; en model med en stor, støjende gør ikke.

Næsten enhver forvirret samtale om agent memory er tre mekanismer, der bærer ét ord. De har forskellige levetider, ejere og failure modes, og et system, der holder dem samme sted, har et problem, det ikke har opdaget endnu.

Den akademiske framing er CoALA’s, som organiserer language agents omkring „modular memory components” og adskiller working memory fra episodiske, semantiske og procedurale stores.⁴ MemGPT tager samme idé bogstaveligt og låner virtual memory fra operativsystemer: et hurtigt tier inde i vinduet, et langsomt tier udenfor, og modellen selv flytter data mellem dem med function calls.⁵ Begge tvinger det spørgsmål frem, som et produkt alligevel skal besvare — ikke hvor meget kan jeg beholde, men hvilket store hører dette til i, og hvornår udløber det.

Den praktiske test er ét spørgsmål per faktum: hvad bør stadig være sandt i morgen? Et værktøjsresultat fra tur 12, intet. En summary af sessionen, indtil sessionen slutter. At brugerens medarbejdernummer er 4417, indtil de skifter job. Tre svar, tre stores.

Du kan nu måle, hvad der er i et vindue, beslutte hvad der bliver i det, og kende forskel på en agent, der glemte noget, og en der bar det og ikke kiggede.

Den sidste af de fire strategier er den, der ikke passer her. En sub-agent er ikke en context policy, det er en anden agent, og i samme øjeblik der er to, skal du beslutte, hvad der går mellem dem, og hvem der bestemmer. Kapitel 25 er det: de fem orchestration patterns og hvor hvert af deres navne faktisk kommer fra, de to topologier der blandes sammen — at spørge en sub-agent og få et svar tilbage, op imod at overdrage den samtalen og ikke få den tilbage — og det målte fund, at på den opgave det prissætter, vinder det enklere arrangement — efterfulgt af testen for, hvornår det holder op med at vinde.

Det arver også præcis det, dette kapitel lige målte. En sub-agent returnerer en summary. En summary er en compaction, du ikke skrev, produceret af en model, hvis vindue du ikke kan se, og parent har ingen måde at kende en god fra en confident forkert — den samme forskel, der adskilte 84 % fra 19 % øverst på denne side, og som gjorde atten manglende fakta til atten opfundne. Så: når sub-agent tager fejl, hvad får parent præcis lov til at kigge på?

Hvert tal her blev produceret på denne maskine, og intet blev estimeret. Modellen er Qwen2.5-0.5B-Instruct i float32 på CPU’en med greedy decoding, serveret over loopback af et lille Python-endpoint, der taler chat-completions-formen og eksponerer en token-count-route — Kapitel 14’s seam igen, tensorer på Python-siden og loopet på TypeScript-siden — så hver tælling er den models egen tokenizer anvendt på dens egen chat-template. Positionstabellen er 288 kald, ni positioner gange toogtredive forsøg med en anden sag i hvert forsøg; længdetabellen er 140 kald; agent-kørslen er 57 modelkald over 43 minutters vægtid; policy-tabellen er det ene transcript afspillet under syv policies. Intervaller er Wilsons, fra Kapitel 4. Ingen betalt API blev kaldt, hvilket også er grunden til, at der ikke er én pris i kapitlet: token counts er præcise, og de rates, du ville gange dem med, er Kapitel 16’s.