L'arnès, no el model: quatre mecanismes perquè un agent no perdi el fil en tasques llargues

Què és realment un agent i per què s'espatlla

Un agent, en la seva forma més simple, és un model de llenguatge que crida eines dins d'un bucle: pensa, executa una acció, mira el resultat i torna a començar. Aquest bucle funciona bé en encàrrecs curts. El problema apareix quan la tasca dura una hora i acumula dues-centes crides.

La guia de disseny d'AWS Samples per a agents autònoms de programació al núvol anomena les errades sense embuts: els agents superficials pateixen desbordament de context, es distreuen —perden l'objectiu— i no mantenen l'estat durant períodes llargs. I assenyala on és la solució: no en el model, sinó en l'arnès, que AWS descriu com la capa que gestiona tot allò que no és el model.

Dit d'una altra manera: canviar de model no soluciona aquestes errades. El que les esmena és la maquinària que decideix què entra a la memòria de treball del model, què es resumeix, què es desa a fora i què es torna a recordar a cada torn.

L'arnès: la capa de la qual gairebé ningú no parla

Quan algú diu que un agent «és molt bo», gairebé sempre està descrivint l'arnès més que no pas el model. L'arnès decideix quina informació arriba al model abans de la primera instrucció, què es descarta a mitja tasca, quan es resumeix la conversa i què sobreviu d'una sessió a la següent.

Quatre mecanismes componen aquesta maquinària: pressupost i descàrrega de context, compactació, estat de tasques amb recitació, i estratègia de memòria entre sessions. Tots quatre persegueixen el mateix objectiu amb eines diferents: que el model arribi al final de la tasca amb l'encàrrec original encara fresc.

Per què una finestra més gran no arregla el problema

La reacció intuïtiva és demanar una finestra de context més gran. Les proves diuen que ajuda menys del que s'espera. L'informe Context Rot de Chroma va avaluar divuit models, entre ells GPT-4.1, Claude 4, Gemini 2.5 i Qwen3, i va trobar que el rendiment esdevé cada cop menys fiable a mesura que creix l'entrada, fins i tot en tasques simples de recuperació de dades.

La guia d'enginyeria de context d'Anthropic explica el mecanisme: l'atenció crea n² relacions per parelles per a n tokens, de manera que cada token afegit consumeix part d'un «pressupost d'atenció» finit. El context no és un cubell que s'omple: és un recurs amb rendiments decreixents.

En un bucle d'agent la cosa empitjora. Manus informa que una tasca típica necessita una cinquantena de crides a eines i que la proporció entre tokens d'entrada i de sortida ronda 100:1. Cada observació arriba al context i s'hi queda. La instrucció original va quedant desplaçada cap al centre de la finestra, que és justament la zona on la recuperació es degrada. La pèrdua de l'objectiu no és només una errada del model: és el resultat esperable d'un context sense gestionar en una tasca prou llarga.

Les dues errades que cal evitar

Convé tenir clars els dos símptomes, perquè els quatre mecanismes s'entenen millor com a respostes a aquests dos problemes.

El desbordament de context és l'errada material: no hi cap res més. L'agent ha anat acumulant sortides d'eines, continguts de fitxers i raonaments fins a esgotar la finestra, i la tasca s'interromp.

La pèrdua de l'objectiu és l'errada silenciosa, i la més perillosa: l'agent continua funcionant, continua cridant eines i produint text, però ja no fa el que se li havia demanat. Ningú no veu cap error; simplement, el resultat no serveix.

Mecanisme 1: pressupostar el context i descarregar el que sobra

La primera feina d'un arnès és decidir què no entra mai a la finestra. Deep Agents porta de sèrie dues regles de descàrrega amb xifres concretes. Quan la resposta d'una eina supera els 20.000 tokens, s'escriu al sistema de fitxers i al context només s'hi deixa la ruta del fitxer més una vista prèvia de les deu primeres línies. I quan el context de la sessió depassa el 85% de la finestra del model, les crides antigues d'escriptura i edició —el contingut complet de les quals ja és al disc— es retallen fins a deixar-hi únicament un punter. Només quan la descàrrega es queda sense marge l'arnès recorre al resum.

Claude Code aplica el mateix criteri a allò que es carrega fins i tot abans de la primera instrucció. La memòria automàtica està limitada a les primeres 200 línies o 25 KB. Els esquemes d'eines MCP queden diferits per defecte: només se'n llisten els noms i els esquemes complets es carreguen sota demanda mitjançant cerca d'eines. I després d'una compactació, qualsevol fitxer rellegit que passi dels 5.000 tokens torna com a referència de ruta en comptes de com a contingut.

Subagents: pressupostar a escala d'arquitectura

El patró de subagent porta la mateixa idea un esglaó més amunt. La simulació de finestra de context de la documentació de Claude Code ho posa en xifres: un subagent d'investigació llegeix 6.100 tokens de fitxers i retorna a l'agent principal un resultat de 420 tokens. Tot el desordre de l'exploració es queda fora de la finestra del coordinador.

La guia d'Anthropic apunta que cada subagent pot consumir desenes de milers de tokens explorant, però retorna un resum destil·lat, sovint d'entre 1.000 i 2.000 tokens. El recorregut d'AWS amb AgentCore construeix exactament això: un coordinador llança tres subagents de navegació en paral·lel, cadascun dins de la seva pròpia MicroVM, i un subagent analista rep únicament les seves troballes estructurades. AWS calcula un temps d'execució esperat de quatre a sis minuts i assenyala que el processament seqüencial trigaria fins al triple.

Mecanisme 2: compactació, o com resumir sense perdre el que importa

Quan la descàrrega ja no basta, l'arnès resumeix. La compactació consisteix a agafar una conversa que s'acosta al límit de la finestra, resumir-la i reiniciar un context nou amb aquest resum. És també el moment en què més sovint es perd l'objectiu, perquè un resum amb pèrdues pot deixar fora justament la restricció que importava.

Les implementacions es diferencien en què prometen conservar. La instrucció de compactació de Claude Code preserva decisions d'arquitectura, errors sense resoldre i detalls d'implementació, i descarta sortides d'eines redundants. Just després torna a llegir fins a cinc dels fitxers modificats més recentment, recarrega les regles que corresponen a aquests fitxers i reinjecta els cossos de les skills invocades, amb un màxim de 5.000 tokens per skill i 25.000 en total. La documentació és explícita: les instruccions detallades del principi de la conversa es poden perdre, i per això les regles persistents han de viure al CLAUDE.md de l'arrel del projecte, que es reinjecta des del disc. L'usuari pot orientar la passada amb /compact focus on the auth bug fix o moure el punt d'activació amb /autocompact.

Deep Agents va convertir la conservació de l'objectiu en una característica estructural. El seu resum és un document amb camps dedicats a la intenció de la sessió, els artefactes creats i els passos següents; l'equip de LangChain hi va afegir aquests camps després que experiments de resum forçat mostressin que el canvi millorava el rendiment. A més, la transcripció original completa s'escriu al sistema de fitxers, de manera que una dada eliminada pel resum es pot recuperar més endavant amb read_file.

La compactació baixa a la capa d'API

El mecanisme ha deixat de ser cosa exclusiva de les aplicacions. La Responses API d'OpenAI ofereix compactació al servidor mitjançant context_management amb un compact_threshold, i a més un endpoint independent /responses/compact que retorna una finestra de context compactada amb un element de compactació xifrat i opac; OpenAI indica als desenvolupadors que passin aquesta finestra retornada sense modificar a la crida següent. OpenAI afirma que Codex es recolza en aquest mecanisme per sostenir tasques llargues de programació.

La Claude Developer Platform exposa una edició de gestió de context anomenada compact_20260112, amb instruccions personalitzades i una opció pause_after_compaction per inserir contingut abans que el model continuï. Un detall important: quan s'hi escriuen instruccions personalitzades, substitueixen del tot la instrucció per defecte. Una instrucció de compactació no és un ajust menor, és una peça d'enginyeria en si mateixa.

Mecanisme 3: estat de tasques i recitació de l'objectiu

La compactació protegeix l'objectiu en el moment del resum. L'estat de tasques el protegeix en tots els torns intermedis. Manus ho va descriure sense adorns: el seu agent crea un todo.md i el reescriu pas a pas, ratllant el que ja ha fet. Reescriure la llista recita els objectius al final del context, empeny el pla global cap al tram d'atenció recent del model i redueix la deriva del «perdut al mig». No cal canviar l'arquitectura: és llenguatge natural fet servir per esbiaixar l'atenció del model mateix.

L'evidència, això sí, no és unànime. Deep Agents incloïa per defecte una eina write_todos fins a la versió v0.7, del juliol del 2026, quan LangChain va passar TodoListMiddleware a mode opcional perquè les seves avaluacions en tres categories de tasca mostraven una recompensa lleugerament millor i un cost menor amb les tasques desactivades. LangChain continua recomanant activar-lo en tasques llargues de diversos passos, amb models menys capaços i en interfícies que mostren progrés.

Claude Code manté una llista de tasques i reinjecta des del disc, després de la compactació, el pla escrit en mode pla. La guia d'Anthropic anomena el patró general presa de notes estructurada: l'agent escriu un NOTES.md o un fitxer de tasques fora de la finestra i el torna a carregar. El seu exemple de Claude Plays Pokémon va mantenir recomptes al llarg de milers de passos de joc, va rellegir les seves pròpies notes després de cada reinici de context i va reprendre seqüències de diverses hores.

El fil comú és que l'objectiu existeix com a artefacte mutable, no només com un missatge de l'historial. Els missatges envelleixen i acaben resumits. Un fitxer que es reescriu cada pocs torns sempre és recent, sempre és curt i sobreviu a qualsevol reinici. Que compensi el seu cost per torn depèn del model i de la durada de la tasca, que és exactament el que van mesurar les avaluacions de Deep Agents.

Mecanisme 4: memòria entre sessions

L'última peça és què queda quan la tasca s'acaba. Claude Code reinjecta des del disc el CLAUDE.md de l'arrel del projecte i la memòria automàtica després de cada compactació. AgentCore Memory emmagatzema esdeveniments i executa en segon pla les estratègies d'extracció configurades, de manera que en l'execució següent un coordinador pot cridar una eina de recuperació en comptes de tornar a investigar des de zero. AWS adverteix que, si no es configura almenys una estratègia d'extracció, els esdeveniments en brut es desen però no se n'extreu res que després es pugui recuperar. L'eina de memòria basada en fitxers d'Anthropic fa la mateixa funció a la seva plataforma.

El límit és que el context persistent no és de franc. L'estudi de l'ETH Zurich que vam cobrir al febrer va trobar que els fitxers de context de repositori com AGENTS.md no milloren de manera general l'èxit en les tasques i sí que apugen el cost d'inferència: els fitxers generats per models van incrementar el cost un 20% i un 23% en els dos bancs de proves, i els escrits per desenvolupadors fins a un 19%. La memòria que es recarrega a cada sessió és un impost fix sobre el pressupost d'atenció.

La documentació de Claude Code dona el consell que encaixa amb aquesta dada: mantenir el CLAUDE.md per sota de les 200 línies i traslladar el material de referència a skills o a regles acotades per ruta, que només es carreguen quan calen.

Com comprovar que l'arnès aguanta de debò

La gestió de context només val si l'agent continua sent capaç d'acabar la tasca i de recuperar detalls que ja no té al davant. LangChain manté avaluacions adreçades a això: proves que disparen el resum a mitja tasca i comproven si l'agent continua cap al seu objectiu, i casos d'agulla en un paller en què una dada queda eliminada pel resum i s'ha de recuperar buscant-la al sistema de fitxers.

Per generar prou esdeveniments i poder comparar variants d'instrucció, l'equip dispara el resum al 10-20% de la finestra en comptes del 85% per defecte, i va fer servir un llindar del 25% amb Claude Sonnet 4.5 a terminal-bench-2 per estudiar-ne l'efecte.

L'errada que cal vigilar, segons LangChain, és la deriva de l'objectiu: un agent que demana aclariments just després d'un resum, o que declara la tasca acabada quan no ho està. AgentCore Evaluations inclou un avaluador de taxa d'èxit d'objectiu capaç de puntuar aquestes mateixes traces. La regla pràctica és contundent: si tens un arnès en producció i no has forçat mai una compactació en una prova, encara no saps què està llençant la teva instrucció de resum.