Context Engineering: per què el teu agent es torna més ximple al torn 40

Anthropic va traçar la línia el setembre de 2025, i les dues frases van juntes. Prompt engineering és «mètodes per escriure i organitzar instruccions d’LLM per obtenir resultats òptims». Context engineering és «el conjunt d’estratègies per seleccionar i mantenir el conjunt òptim de tokens (informació) durant la inferència d’un LLM, incloent-hi tota la resta d’informació que hi pot acabar fora dels prompts».¹

La diferència operativa és quan, i per qui. Un prompt l’escriu una vegada una persona i es revisa. Un context es munta a cada crida, amb codi que ningú no està mirant, a partir de material que ningú no ha escrit a mà: quaranta torns d’historial, sis resultats d’eines, quatre passatges recuperats, un perfil d’usuari, dotze esquemes JSON. El capítol 15 va mesurar què aporten unes instruccions millors. Aquest capítol tracta de l’altre noranta per cent dels tokens, que arriben sols.

El mateix document posa nom al recurs que tots gasten: els models «tenen un “pressupost d’attention” del qual tiren quan processen grans volums de context. Cada token nou introduït esgota aquest pressupost en una certa quantitat». I posa nom al símptoma: «a mesura que augmenta el nombre de tokens dins la context window, la capacitat del model per recordar informació d’aquest context amb precisió disminueix» —context rot.¹

Aquesta última frase és una afirmació sobre comportament, cosa que vol dir que es pot comprovar, i la taula de dalt d’aquesta pàgina és la comprovació.

Quaranta línies contra l’endpoint local del capítol 22: un petit servidor Python que manté Qwen2.5-0.5B-Instruct a la CPU i parla amb la forma de chat-completions, de manera que el bucle continua sent TypeScript i els tensors queden a l’altra banda del port.

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++;
  }
}

El comptador other és el que converteix un resultat decebedor en un d’útil: quan el model s’equivoca, està perdut o està convençut?

La resposta és: convençut. Entre les vuit posicions que no són la primera, 136 de les 205 respostes errònies eren l’extensió d’un altre tiquet: un número real de quatre xifres, amb el format correcte, llegit de la línia equivocada. A la posició 1 només una de les cinc errades ho era; a la posició 7, vint-i-una de vint-i-sis.

Aquesta distinció és el que importa en producció. Un model que diu no ho puc trobar és un error que detectes; un model que retorna el número d’una fila veïna és un error que envies, perquè a la pantalla tots dos semblen idèntics. És la fallada contra la qual el capítol 19 va construir citacions verificables, arribant des de dins del prompt en lloc de venir de l’índex.

La posició és un eix. La longitud és l’altre, i és més fàcil de provar: deixa la resposta al mig i fes créixer la llista.

Un registre i 97 tokens: 90 %. Tres registres i 159 tokens: 55 %. Vuit registres i 315 tokens: 15 %, i a partir d’aquí pla i baix fins a 140 registres i 4.477 tokens. Tot l’ensorrament passa entre la primera i la vuitena línia d’una llista.

L’última columna és tot allò que no és ni l’extensió correcta ni la d’un altre registre, que amb un sol registre a la pàgina és l’únic lloc on pot anar a parar una resposta errònia. Val la pena reportar les dues errades amb un registre en lloc d’arrodonir-les fora, perquè cap de les dues va ser una negativa: una va respondre 5806 a un registre on l’única línia diu 5805. Amb 97 tokens i un sol candidat, aquest model encara copia malament un dígit dues vegades de vint, i aquest és el sòl contra el qual es mesura tota la resta.

D’aquí se’n deriven dues coses. Una context window més gran compra el dret d’enviar més, no la certesa que serà llegit: aquest model té una finestra de 32.768 tokens i un rang de treball, en aquesta tasca, d’uns quants centenars de tokens. I no hi ha cap llindar, cap precipici, cap estat de «context ple»: la degradació ja està en marxa al tercer registre i és completa al vuitè, a l’u per cent de la finestra. Sigui el que sigui un límit de context, no és això el que ho governa.

Normalment s’ofereixen dos mecanismes. El primer és l’aritmètica del capítol 9, que Anthropic formula en els mateixos termes que aquest curs: els models «es basen en l’arquitectura transformer, que permet que cada token atengui tots els altres tokens de tot el context. Això dona lloc a n² relacions per parelles per a n tokens».¹ L’attention sobre una seqüència més llarga no és la mateixa operació aplicada a més material; és un pressupost fix de massa de probabilitat repartit entre més competidors. El segon és l’entrenament: els models veuen moltes més seqüències curtes que llargues, de manera que els patrons posicionals de llarg abast són la part menys practicada de la xarxa. Això és un argument, no una mesura, i aquest capítol no ho pot resoldre.

El que sí queda establert és la forma, i ho està des de 2023. Liu et al. van provar la resposta a preguntes sobre múltiples documents i la recuperació clau-valor en famílies i mides de models, i van trobar que «el rendiment sovint és més alt quan la informació rellevant apareix al principi o al final del context d’entrada, i es degrada significativament quan els models han d’accedir a informació rellevant al mig de contextos llargs, fins i tot en models explícitament de context llarg».² El capítol 15 va prendre la seva regla de posició d’aquest article; el capítol 19 en va prendre el motiu pel qual vint chunks recuperats poden puntuar pitjor que quatre. La forma pràctica del fet és l’única frase d’aquí sobre la qual hauries d’actuar: això es mesura en cinc minuts en el teu propi model amb les teves pròpies dades, i cap corba publicada substitueix la teva.

Pregunta a un equip què omple el context del seu agent i obtindràs una estimació, perquè cap API no retorna la resposta: la resposta et dona prompt_tokens, un sol número per a tot plegat.

Pots recuperar-ne el desglossament amb quatre recomptes i tres restes: el prompt renderitzat complet, el mateix sense definicions d’eines, només el missatge de sistema amb i sense elles, i tot plegat amb els resultats d’eines eliminats:

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 aplica la plantilla de xat pròpia del model abans de tokenitzar, cosa que importa més del que sembla: el teu text no és el que es compta. Els marcadors de rol, el preàmbul de tool-calling i el renderitzat de l’esquema són tots tokens que pagues i que no has escrit mai. El capítol 7 va construir un tokenizer i el capítol 16 va comptar amb js-tiktoken; aquí el recompte ve del mateix model que llegirà el prompt, que és l’únic recompte exactament correcte.

Ara fes passar un agent real per això: quaranta torns d’una investigació d’incident, dotze eines, un entorn d’operacions fals que retorna bolcats de logs i sèries de mètriques realistes.

Llegeix la primera fila en contrast amb l’última.

Al torn 1 el prompt té 2.547 tokens i el 71 % són definicions d’eines. El system prompt és el 3 %. El que ha escrit l’usuari és el 6 %. L’agent encara no ha fet res i ja carrega 1.817 tokens d’esquema JSON.

Al torn 40 el prompt té 10.632 tokens i les proporcions s’han invertit: definicions 17 %, conversa 29 %, resultats d’eines 53 %. La sortida d’eines va superar les definicions al torn 5; la conversa no les va superar fins al torn 25, així que durant el primer seixanta per cent de la sessió el catàleg d’eines era més gran que tot el que s’havia dit.

Després, el total. Al llarg de 57 crides al model, l’execució va facturar 370.291 input tokens per a un context final de 10.632: l’últim prompt pagat unes trenta-cinc vegades, que és la quadràtica del capítol 16 amb el multiplicador d’un agent a sobre. D’aquests 370.291, 103.569, o el 28 % de tot el facturat, eren les dotze definicions d’eines, reenviades byte per byte idèntiques a cada crida.

El catàleg d’eines és el cost fix més gran d’un agent i és invisible, perquè no el veus mai: passes un array d’objectes i el proveïdor el renderitza al prompt per tu. Mesurat amb les mateixes dotze eines:

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 eina, el cost marginal va de 80 tokens per a get_current_time, que pren una cadena, a 263 per a search_tickets, que pren quatre paràmetres amb un enum i una frase de guia cadascun. Aquest és el tipus de canvi darrere del consell central del capítol 18, que la descripció és l’API: una bona descripció costa aproximadament cent tokens en cada sol·licitud durant la resta de la vida de l’agent. Tres conseqüències.

Una eina que no fas servir també factura. L’agent va cridar set de les dotze. Les altres cinc van costar 697 tokens en cadascuna de les 57 sol·licituds: 39.729 en total, més d’una desena part de tot el que es va facturar a l’execució, per capacitats que no va tocar mai. Una de les cinc conté el detall més punyent de la traça: el model va provar tres vegades de cridar read_log, que no existeix. L’eina que volia era search_logs, la segona definició més cara del catàleg amb 237 tokens. Va pagar aquesta definició 57 vegades, no la va fer servir mai i no en va trobar mai el nom.

Retallar prosa és l’optimització més barata disponible, i és un intercanvi. Reduir les descripcions a una frase i eliminar la documentació dels paràmetres va estalviar 526 tokens per crida, un 29 per cent, sense tocar ni una línia de lògica, i va fer que el model cridés pitjor les eines, que és el que va mesurar el capítol 18. La qüestió és que ara tots dos costats d’aquest intercanvi són a la mateixa unitat.

A certa escala, enviar definicions deixa de tenir sentit. Anthropic hi va posar un número el novembre de 2025: un conjunt gran de servidors connectats implica processar «centenars de milers de tokens» de definicions abans de llegir la sol·licitud, i substituir-ho per execució de codi —l’agent descobrint i carregant només les definicions que necessita— «redueix l’ús de tokens de 150.000 tokens a 2.000 tokens, un estalvi de temps i cost del 98,7 %».³ La mateixa idea que la resta d’aquest capítol, aplicada a esquemes en lloc d’historial: mantén l’índex, resol l’entrada sota demanda.

En aquella transcripció de quaranta torns s’hi van plantar dues coses. Al torn 2, abans de cap feina real, l’usuari estableix una regla permanent: qualsevol tiquet que obris s’ha de registrar sota el meu número d’empleat, 4417. Al torn 19, al mig de l’incident, un fet: el shard afectat és pay-shard-7, confirmat per l’equip de pagaments. Al torn 40 l’usuari demana a l’agent que obri el tiquet d’incident, cosa que necessita totes dues. Cada sonda es pregunta amb sis formulacions diferents i es puntua sobre sis: la descodificació greedy és determinista, així que una crida dona un sí o no irrepetible, i sis donen una taxa.

Després, la transcripció es reprodueix sota set polítiques de context. Reproduïda, no tornada a executar, deliberadament: els missatges, les crides d’eines i els resultats d’eines són byte per byte idèntics en totes set, així que l’única variable és què ha triat conservar cada política. El capítol 16 va mostrar per què una finestra lliscant és una mala jugada econòmica, perquè destrueix el prefix cachejable. Aquí tens què fa al comportament:

Les files de compaction inclouen el que va costar compactar: 18.581 input tokens per a set resums i 3.392 més per al prenedor de notes. La fila de control hi és perquè un zero es pugui llegir com un zero: amb només els dos missatges dins un prompt de 1.981 tokens, aquest model respon perfectament totes dues sondes, així que cap fila és que la tasca sigui massa difícil.

L’historial complet recorda, i és el més car de la taula: 370.291 input tokens per a una sessió el contingut durable de la qual són dues frases.

Això respon una pregunta que l’inici deixava oberta. Per què una transcripció de 10.632 tokens conserva un fet que un registre de 853 tokens perd? Perquè la longitud és la variable equivocada. El registre conté vint-i-cinc extensions de quatre xifres en vint-i-cinc frases idèntiques: vint-i-quatre esquers gairebé perfectes per a la que vols. La transcripció conté exactament un número d’empleat i un nom de shard. Context rot és interferència abans que volum, per això 136 de les 205 respostes errònies de dalt eren el valor d’un veí. La pregunta útil sobre una finestra no és com de llarga és; és quantes coses que hi ha dins s’assemblen a la resposta.

La finestra lliscant és un 57 % més barata i ha perdut l’incident. El número d’empleat sobreviu només perquè l’agent l’havia repetit als torns recents. El shard, dit una sola vegada al torn 19, no és als últims dotze missatges, i el model no ho diu. Preguntat sis vegades va respondre «the affected payment shard is shard 4417», agafant el número d’empleat, l’únic altre identificador que quedava a la seva finestra, i dues vegades «pool», extret de la cadena pool_exhausted en una línia de log.

La compaction és barata i va perdre el mateix fet. Set resums, escrits pel model sota una instrucció explícita de conservar identificadors, números, instruccions permanents i preguntes obertes, i pay-shard-7 no és en cap dels que importaven; les sis suposicions van ser shard 1, pay_shard_1 i pool. La compaction no falla fent soroll. Produeix una sessió fluida, plausible i molt més curta que ha deixat caure una línia en silenci.

Tres files van puntuar 0/6 en el fet del torn 19: la finestra lliscant, la compaction i la compaction amb notes. Divuit respostes errònies entre totes, i cap d’elles no va ser «no ho sé».

Després ve la fila que hauria de fer vergonya. Conservar literalment els quaranta missatges propis de l’usuari, més els últims quatre torns sencers i res més, costa 168.550 tokens —un 54 % menys que l’historial complet— i respon totes dues sondes tan bé com l’historial complet o millor. Cap resumidor, cap prenedor de notes, cap segon model: un filtre sobre role === "user". Les paraules de l’usuari són els tokens d’alt valor més barats dins la finestra d’un agent, i la majoria de dissenys les descarten amb tota la resta.

Les dues últimes files són la taula inicial una altra vegada, dins l’agent. El mateix bloc fixat, mogut del missatge de sistema al final del prompt: 5/6 passa a 6/6. En sis assajos això no és una diferència significativa i no es presenta com a tal; es presenta com un recordatori que on és un paràmetre que estàs configurant tant si ho saps com si no.

Les quatre estratègies de sota són d’Anthropic, en el seu ordre, tot i que només les tres últimes són la seva llista de llarg horitzó.¹ Totes quatre són variacions d’una instrucció: no carreguis allò que pots anar a buscar, i no carreguis en brut allò que pots carregar comprimit.

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()}`);

El sub-agent no surt a la taula de dalt perquè no s’executa durant quaranta torns: s’executa una vegada, dins una finestra que algú ha delimitat per a ell. Amb el system prompt, els torns 17 a 19 i res més —2.737 tokens— va respondre la sonda del shard 6/6, millor que qualsevol política de la taula, i la sonda de l’empleat 0/6, perquè aquell número no és dins els tres torns que se li van lliurar.

Això són els sub-agents en dos números: una finestra neta no és intel·ligència, és abast, i l’abast el fixa per endavant codi que ja ha de saber quins torns importen. Hi ha una cosa més en aquestes respostes que val la pena conservar. Aquesta va ser l’única política que va respondre «None available» en lloc d’inventar alguna cosa. Un model amb un context petit i coherent sap què li falta; un model amb un context gran i sorollós no.

Gairebé totes les converses confuses sobre la memòria dels agents són tres mecanismes portant una sola paraula. Tenen vides útils, propietaris i modes de fallada diferents, i un sistema que els manté al mateix lloc té un problema que encara no ha detectat.

El marc acadèmic és el de CoALA, que organitza els language agents al voltant de «components modulars de memòria» i separa la memòria de treball dels magatzems episòdics, semàntics i procedimentals.⁴ MemGPT pren la mateixa idea literalment, manllevant la memòria virtual dels sistemes operatius: un nivell ràpid dins la finestra, un nivell lent fora, i el mateix model movent dades entre ells amb function calls.⁵ Tots dos obliguen a formular la pregunta que un producte ha de respondre igualment: no quant puc conservar, sinó a quin magatzem pertany això, i quan caduca.

La prova pràctica és una pregunta per fet: què hauria de continuar sent cert demà? Un resultat d’eina del torn 12, res. Un resum de la sessió, fins que acabi la sessió. Que el número d’empleat de l’usuari és 4417, fins que canviï de feina. Tres respostes, tres magatzems.

Ara pots mesurar què hi ha dins una finestra, decidir què s’hi queda, i distingir entre un agent que ha oblidat alguna cosa i un que la portava a sobre però no l’ha mirat.

L’última de les quatre estratègies és la que no encaixa aquí. Un sub-agent no és una política de context, és un segon agent, i en el moment que n’hi ha dos has de decidir què passa entre ells i qui mana. El capítol 25 és això: els cinc patrons d’orquestració i d’on ve realment cada nom, les dues topologies que es confonen —demanar a un sub-agent i rebre’n una resposta, enfront de passar-li la conversa i no recuperar-la— i el resultat mesurat que, en la tasca que posa preu, l’arranjament més simple guanya, seguit de la prova per saber quan deixa de guanyar.

També hereta exactament el que aquest capítol acaba de mesurar. Un sub-agent retorna un resum. Un resum és una compaction que no has escrit, produïda per un model la finestra del qual no pots veure, i el pare no té cap manera de distingir-ne un de bo d’un d’equivocat però segur de si mateix: la mateixa distinció que separava el 84 % del 19 % al principi d’aquesta pàgina, i que va convertir divuit fets perduts en divuit inventats. Així que: quan el sub-agent s’equivoca, què pot mirar exactament el pare?

Tots els números d’aquí s’han produït en aquesta màquina i cap no s’ha estimat. El model és Qwen2.5-0.5B-Instruct en float32 a la CPU amb descodificació greedy, servit sobre loopback per un petit endpoint Python que parla amb la forma de chat-completions i exposa una ruta de recompte de tokens —la costura del capítol 14 una altra vegada, tensors al costat Python i el bucle al costat TypeScript—, així que cada recompte és el tokenizer propi d’aquell model aplicat a la seva pròpia plantilla de xat. La taula de posició són 288 crides, nou posicions per trenta-dos assajos amb un tiquet diferent a cada assaig; la taula de longitud són 140 crides; l’execució de l’agent són 57 crides al model durant 43 minuts de rellotge; la taula de polítiques és aquella única transcripció reproduïda sota set polítiques. Els intervals són de Wilson, del capítol 4. No s’ha cridat cap API de pagament, i per això tampoc no hi ha cap preu al capítol: els recomptes de tokens són exactes i les tarifes per les quals els multiplicaries són les del capítol 16.