Context Engineering: Därför blir din agent dummare vid tur 40

Anthropic drog gränsen i september 2025, och de två meningarna hör ihop. Prompt engineering är ”metoder för att skriva och organisera LLM-instruktioner för optimala resultat”. Context engineering är ”uppsättningen strategier för att kurera och underhålla den optimala uppsättningen tokens (information) under LLM-inference, inklusive all annan information som kan hamna där utanför prompts”.¹

Den operativa skillnaden är när, och av vem. En prompt skrivs en gång, av en person, och granskas. Ett context sätts ihop vid varje anrop, av kod ingen tittar på, ur material ingen skrev för hand: fyrtio turer historik, sex tool-resultat, fyra hämtade passager, en användarprofil, tolv JSON-scheman. Kapitel 15 mätte vad bättre instruktioner köper. Det här kapitlet handlar om de andra nittio procenten av tokens, som kommer av sig själva.

Samma dokument namnger resursen som alla förbrukar: modeller ”har en ’attention budget’ som de drar på när de tolkar stora mängder context. Varje ny token som introduceras tömmer denna budget med en viss mängd”. Och det namnger symptomet: ”när antalet tokens i context window ökar minskar modellens förmåga att korrekt återkalla information från detta context” — context rot.¹

Den sista meningen är ett påstående om beteende, vilket betyder att den kan kontrolleras, och tabellen högst upp på den här sidan är kontrollen.

Fyrtio rader mot den lokala endpointen från kapitel 22 — en liten Python-server som håller Qwen2.5-0.5B-Instruct på CPU:n och talar chat-completions-formatet, så loopen stannar i TypeScript och tensors stannar på andra sidan 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++;
  }
}

Räknaren other är det som gör ett nedslående resultat användbart: när modellen har fel, är den vilse eller säker?

Svaret är säker. Över de åtta icke-första positionerna var 136 av de 205 felaktiga svaren en annan ärenderads anknytning — ett verkligt fyrsiffrigt nummer, korrekt formaterat, läst från fel rad. På plats 1 var bara en av de fem missarna det; på plats 7 var tjugoen av tjugosex det.

Den distinktionen är det som spelar roll i produktion. En modell som säger jag hittar det inte är en bugg du märker; en modell som returnerar numret från en grannrad är en bugg du skeppar, eftersom de två ser identiska ut på skärmen. Det är felet som kapitel 19 byggde verifierbara citat mot, men som nu kommer inifrån prompt i stället för från indexet.

Position är en axel. Längd är den andra, och lättare att testa: håll svaret i mitten och låt listan växa.

En post och 97 tokens: 90 %. Tre poster och 159 tokens: 55 %. Åtta poster och 315 tokens: 15 %, och därifrån platt och lågt hela vägen till 140 poster och 4 477 tokens. Hela kollapsen sker mellan den första och den åttonde raden i en lista.

Sista kolumnen är allt som varken är rätt anknytning eller en annan posts, vilket med en enda post på sidan är den enda plats där ett felaktigt svar kan landa. De två missarna vid en post är värda att rapportera i stället för att avrunda bort, eftersom ingen av dem var en vägran: ett svarade 5806 på ett register vars enda rad säger 5805. Vid 97 tokens med en enda kandidat kopierar den här modellen fortfarande en siffra fel två gånger av tjugo, och det är golvet allt annat mäts mot.

Två saker följer. Ett större context köper rätten att skicka mer, inte vissheten om att det blir läst: den här modellen har ett 32 768-token-fönster och ett arbetsområde, på den här uppgiften, på några hundra tokens. Och det finns ingen tröskel, inget stup, inget ”context full”-tillstånd — degradering pågår redan vid den tredje posten och är komplett vid den åttonde, vid en procent av fönstret. Vad en context limit än är, så är det inte den som styr detta.

Två mekanismer brukar anges. Den första är aritmetiken från kapitel 9, som Anthropic uttrycker i samma termer som den här kursen: modeller ”bygger på transformer-arkitekturen, som gör att varje token kan attend to varje annan token över hela context. Detta resulterar i n² parvisa relationer för n tokens”.¹ Attention över en längre sekvens är inte samma operation tillämpad på mer material; det är en fast budget av probability mass utspridd över fler konkurrenter. Den andra är träning: modeller ser långt fler korta sekvenser än långa, så långdistansmönster i position är den minst övade delen av nätverket. Det är ett argument, inte en mätning, och det här kapitlet kan inte avgöra det.

Det som är avgjort är formen, och har varit det sedan 2023. Liu et al. testade multi-document question answering och key-value retrieval över modellfamiljer och storlekar och fann att ”prestanda ofta är högst när relevant information finns i början eller slutet av input context, och försämras avsevärt när modeller måste komma åt relevant information i mitten av långa contexts, även för uttryckligen long-context-modeller”.² Kapitel 15 tog sin positionsregel från den artikeln; kapitel 19 tog därifrån skälet till att tjugo hämtade chunks kan ge sämre resultat än fyra. Den praktiska formen av faktumet är den enda meningen här du bör agera på: det tar fem minuter att mäta på din egen modell med dina egna data, och ingen publicerad kurva ersätter din.

Fråga ett team vad som fyller deras agents context och du får en uppskattning, eftersom inget API returnerar svaret: responsen ger dig prompt_tokens, ett nummer för alltihop.

Du kan återskapa uppdelningen med fyra räkningar och tre subtraktioner — hela renderade prompt, samma utan tool-definitioner, systemmeddelandet ensamt med och utan dem, och allt med tool-resultaten borttagna:

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 applicerar modellens egen chat template före tokenisering, vilket spelar större roll än det låter: din text är inte det som räknas. Rollmarkörer, tool calling-preamble och schemarendering är alla tokens du betalar för och aldrig skrev. Kapitel 7 byggde en tokenizer och kapitel 16 räknade med js-tiktoken; här kommer räkningen från samma modell som ska läsa prompt, vilket är den enda räkning som är exakt rätt.

Kör nu en verklig agent genom det: fyrtio turer av incidentutredning, tolv tools, en falsk driftmiljö som returnerar realistiska loggdumpar och tidsserier för mätvärden.

Läs första raden mot den sista.

Vid tur 1 är prompt 2 547 tokens och 71 % av den är tool-definitioner. System-prompt är 3 %. Det användaren skrev är 6 %. Agent har inte gjort något än och bär redan på 1 817 tokens JSON-schema.

Vid tur 40 är prompt 10 632 tokens och andelarna har vänt: definitioner 17 %, konversation 29 %, tool-resultat 53 %. Tool-output passerade definitionerna vid tur 5; konversationen passerade dem först vid tur 25, så under de första sextio procenten av sessionen var tool-katalogen större än allt som hade sagts.

Sedan totalen. Över 57 modell-anrop debiterade körningen 370 291 input tokens för ett slutligt context på 10 632 — den sista prompt betalades ungefär trettiofem gånger om, vilket är kapitel 16:s kvadratiska effekt med en agents multiplikator ovanpå. Av dessa 370 291 var 103 569, eller 28 % av allt debiterat, de tolv tool-definitionerna, omskickade byte-identiska vid varje anrop.

Tool-katalogen är den största fasta kostnaden i en agent och den är osynlig, eftersom du aldrig ser den: du skickar en array med objekt och providern renderar den till prompt åt dig. Mätt, på samma tolv tools:

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 tool går marginalkostnaden från 80 tokens för get_current_time, som tar en sträng, till 263 för search_tickets, som tar fyra parametrar med en enum och en mening vägledning var. Det är växelkursen bakom kapitel 18:s centrala råd att beskrivningen är API:t: en bra beskrivning kostar ungefär hundra tokens vid varje request under resten av agentens liv. Tre konsekvenser.

En tool du inte använder debiteras ändå. Agent anropade sju av de tolv. De andra fem kostade 697 tokens på var och en av de 57 requestsen — 39 729 totalt, mer än en tiondel av allt körningen debiterades, för förmågor den aldrig rörde. En av de fem bär den skarpaste detaljen i tracen: modellen försökte tre gånger anropa read_log, som inte finns. Den tool den ville ha var search_logs, den näst dyraste definitionen i katalogen med 237 tokens. Den betalade för den definitionen 57 gånger, använde den aldrig, och hittade aldrig dess namn.

Att trimma prosa är den billigaste optimeringen som finns, och det är en tradeoff. Att skära ned beskrivningar till en mening och ta bort parameterdokumentation sparade 526 tokens per anrop, 29 procent, utan att röra en rad logik — och fick modellen att anropa tools sämre, vilket är vad kapitel 18 mätte. Poängen är att båda sidor av den tradeoffen nu är i samma enhet.

Vid en viss skala slutar det vara vettigt att skicka definitioner alls. Anthropic satte en siffra på det i november 2025: en stor uppsättning anslutna servrar innebär att bearbeta ”hundratusentals tokens” av definitioner innan requesten läses, och att ersätta det med code execution — att agent upptäcker och laddar bara de definitioner den behöver — ”minskar token-användningen från 150 000 tokens till 2 000 tokens, en tids- och kostnadsbesparing på 98,7 %”.³ Samma idé som resten av det här kapitlet, tillämpad på scheman i stället för historik: behåll indexet, slå upp posten vid behov.

Två saker planterades i den där fyrtioturs-transkriptionen. Vid tur 2, före något verkligt arbete, anger användaren en stående regel: alla ärenden du öppnar måste registreras under mitt anställningsnummer, 4417. Vid tur 19, mitt i incidenten, ett faktum: den påverkade sharden är pay-shard-7, bekräftad av betalningsteamet. Vid tur 40 ber användaren agent att öppna incidentärendet, vilket kräver båda. Varje probe ställs i sex olika formuleringar och poängsätts av sex — greedy decoding är deterministisk, så ett anrop ger ett orepeterbart ja eller nej och sex ger en frekvens.

Transkriptionen spelas sedan upp igen under sju context policies. Uppspelad i stället för omkörd, avsiktligt: meddelandena, tool-anropen och tool-resultaten är byte-identiska i alla sju, så den enda variabeln är vad varje policy valde att behålla. Kapitel 16 visade varför ett sliding window är ett dåligt ekonomiskt drag, eftersom det förstör det cachebara prefixet. Här är vad det gör med beteendet:

Compaction-raderna inkluderar vad compaction kostade: 18 581 input tokens för sju sammanfattningar och 3 392 till för note-taker. Kontrollraden finns där för att en nolla ska kunna läsas som en nolla — med de två meddelandena ensamma i en prompt på 1 981 tokens svarar den här modellen perfekt på båda probes, så ingen rad handlar om att uppgiften är för svår.

Full historik minns, och är det dyraste på bordet: 370 291 input tokens för en session vars hållbara innehåll är två meningar.

Det besvarar en fråga som inledningen lämnade öppen. Varför innehåller en transkription på 10 632 tokens ett faktum som ett register på 853 tokens tappar bort? Därför att längd är fel variabel. Registret innehåller tjugofem fyrsiffriga anknytningar i tjugofem identiska meningar — tjugofyra nästan perfekta lockbeten för den du vill ha. Transkriptionen innehåller exakt ett anställningsnummer och ett shard-namn. Context rot är interferens innan det är volym, vilket är varför 136 av de 205 felaktiga svaren där uppe var en grannes värde. Den nyttiga frågan om ett fönster är inte hur långt det är; det är hur många saker i det som ser ut som svaret.

Sliding window är 57 % billigare och har tappat bort incidenten. Anställningsnumret överlever bara för att agent hade upprepat det i de senaste turerna. Sharden, angiven en gång vid tur 19, finns inte i de sista tolv meddelandena — och modellen säger inte det. Frågad sex gånger svarade den ”den påverkade payment-sharden är shard 4417”, och sträckte sig efter anställningsnumret, den enda andra identifieraren kvar i fönstret, och två gånger ”pool”, lyft ur strängen pool_exhausted i en loggrad.

Compaction är billigt och tappade samma faktum. Sju sammanfattningar, skrivna av modellen under en explicit instruktion att behålla identifierare, nummer, stående instruktioner och öppna frågor, och pay-shard-7 finns inte i någon av dem som spelade roll; de sex gissningarna var shard 1, pay_shard_1 och pool. Compaction misslyckas inte högljutt. Den producerar en flytande, plausibel, mycket kortare session som tyst har tappat en rad.

Tre rader fick 0/6 på tur-19-faktumet — sliding window, compaction och compaction med anteckningar. Arton felaktiga svar mellan dem, och inte ett enda var ”jag vet inte.”

Sedan raden som borde vara pinsam. Att behålla användarens egna fyrtio meddelanden ordagrant, plus de sista fyra turerna i full form och inget annat, kostar 168 550 tokens — 54 % mindre än full historik — och svarar på båda probes lika bra som full historik eller bättre. Ingen summariser, ingen note-taker, ingen andra modell: ett filter på role === "user". Användarens ord är de billigaste högvärdes-tokens i en agents fönster, och de flesta designer kastar bort dem tillsammans med allt annat.

De sista två raderna är öppningstabellen igen, inne i agent. Samma pinnade block, flyttat från systemmeddelandet till slutet av prompt: 5/6 blir 6/6. På sex försök är det inte en signifikant skillnad och presenteras inte som en — det presenteras som en påminnelse om att var är en parameter du ställer in oavsett om du vet det eller inte.

De fyra strategierna nedan är Anthropics, i dess ordning, även om bara de sista tre är dess long-horizon-lista.¹ Alla fyra är variationer på en instruktion: bär inte det du kan hämta, och bär inte rått det du kan bära komprimerat.

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 finns inte i tabellen ovan eftersom den inte kör i fyrtio turer: den kör en gång, i ett fönster någon avgränsade för den. Med system-prompt, tur 17 till 19 och inget annat — 2 737 tokens — svarade den på shard-proben 6/6, bättre än varje policy i tabellen, och på anställnings-proben 0/6, eftersom det numret inte finns i de tre turer den fick.

Det är sub-agents i två siffror: ett rent fönster är inte intelligens, det är scope, och scoping görs i förväg av kod som redan måste veta vilka turer som spelar roll. En sak till i de svaren är värd att behålla. Det här var den enda policyn som svarade ”Inget tillgängligt” i stället för att hitta på något. En modell med ett litet, koherent context vet vad den saknar; en modell med ett stort, brusigt gör det inte.

Nästan varje förvirrad konversation om agent memory är tre mekanismer som bär ett ord. De har olika livslängd, ägare och fellägen, och ett system som håller dem på samma plats har ett problem det ännu inte har märkt.

Den akademiska inramningen är CoALA:s, som organiserar språk-agents runt ”modulära minneskomponenter” och separerar arbetsminne från episodiska, semantiska och procedurala lager.⁴ MemGPT tar samma idé bokstavligt, genom att låna virtuellt minne från operativsystem: en snabb nivå inne i fönstret, en långsam nivå utanför det, och modellen själv flyttar data mellan dem med function calls.⁵ Båda tvingar fram frågan som en produkt ändå måste besvara — inte hur mycket kan jag behålla, utan vilket lager hör detta hemma i, och när löper det ut.

Det praktiska testet är en fråga per faktum: vad ska fortfarande vara sant i morgon? Ett tool-resultat från tur 12, ingenting. En sammanfattning av sessionen, tills sessionen tar slut. Att användarens anställningsnummer är 4417, tills de byter jobb. Tre svar, tre lager.

Du kan nu mäta vad som finns i ett fönster, bestämma vad som stannar i det, och se skillnad på en agent som glömde något och en som bar på det men inte tittade.

Den sista av de fyra strategierna är den som inte passar här. En sub-agent är inte en context policy, den är en andra agent, och i samma ögonblick det finns två måste du bestämma vad som passerar mellan dem och vem som bestämmer. Kapitel 25 är det: de fem orchestration patterns och var vart och ett av deras namn faktiskt kommer ifrån, de två topologierna som blandas ihop — att fråga en sub-agent och få ett svar tillbaka, mot att lämna över konversationen till den och inte få tillbaka den — och den uppmätta slutsatsen att på den uppgift den prissätter vinner det enklare upplägget, följt av testet för när det slutar vinna.

Det ärver också exakt det som det här kapitlet just mätte. En sub-agent returnerar en sammanfattning. En sammanfattning är en compaction du inte skrev, producerad av en modell vars fönster du inte kan se, och föräldern har inget sätt att skilja en bra från en säkert felaktig — samma distinktion som skilde 84 % från 19 % högst upp på denna sida, och som gjorde arton saknade fakta till arton påhittade. Så: när sub-agent har fel, exakt vad får föräldern titta på?

Varje siffra här producerades på den här maskinen och ingen uppskattades. Modellen är Qwen2.5-0.5B-Instruct i float32 på CPU:n med greedy decoding, serverad över loopback av en liten Python-endpoint som talar chat-completions-formatet och exponerar en token-count-route — kapitel 14:s seam igen, tensors på Python-sidan och loopen på TypeScript-sidan — så varje räkning är den modellens egen tokenizer tillämpad på dess egen chat template. Positionstabellen är 288 anrop, nio positioner gånger trettiotvå försök med ett annat ärende i varje försök; längdtabellen är 140 anrop; agent-körningen är 57 modell-anrop över 43 minuter väggklocka; policytabellen är den enda transkriptionen uppspelad under sju policies. Intervallen är Wilsons, från kapitel 4. Inget betalt API anropades, vilket också är varför det inte finns ett enda pris i kapitlet: token-räkningarna är exakta och priserna du skulle multiplicera dem med är kapitel 16:s.