La forma habitual de hablar del contexto de un modelo es la de una lista: cosas que el agente «tiene», y que si se le dan, sabe. Esa imagen sostiene una práctica —añadir— y una expectativa: que añadir nunca empeora. Las dos son falsas, y el motivo se enuncia mejor con el vocabulario de Shannon que con el de las estructuras de datos.
El problema de fondo es este: en cada llamada al modelo hay que reconstruir, en otro punto, una decisión que se tomó —o que se tomará— aquí. Shannon lo escribió como el problema fundamental de la comunicación: «reproducing at one point either exactly or approximately a message selected at another point». Las dos palabras que importan son approximately —el canal tiene capacidad finita y la reproducción exacta casi nunca cabe— y selected: lo que hay que transmitir no es el material, sino la decisión que ese material sostiene.
De ahí salen tres consecuencias que una lista no tiene y un canal sí. La primera es que la capacidad es un máximo, no un caudal garantizado: el propio Shannon advierte, al definir la capacidad de un canal discreto, que «this does not mean that the teletype channel will always be transmitting information at this rate — this is the maximum possible rate and whether or not the actual rate reaches this maximum depends on the source of information which feeds the channel». Un contexto de 200.000 tokens no transporta 200.000 tokens de información: transporta lo que la fuente haya sabido codificar. La segunda es que la posición dentro del canal importa. La tercera es que el canal se paga entero en cada llamada, no una vez.
Trasladar «capacidad de canal» de un cable a un procesador de información no es una licencia: Miller lo hizo en 1956 con un observador humano, definiendo su capacidad como «the greatest amount of information that he can give us about the stimulus on the basis of an absolute judgment». El límite se mide en información recuperable, no en material presentado.
Qué debe conservar un resumen
La pregunta operativa no es «¿cabe?» sino «¿qué puedo tirar sin perder la decisión?». Esa pregunta tiene nombre desde 1922. Fisher, al enumerar los criterios de estimación, escribe: «That the statistic chosen should summarise the whole of the relevant information supplied by the sample. This may be called the Criterion of Sufficiency». Un estadístico suficiente es una compresión con pérdida que no pierde nada para la inferencia que se va a hacer. Todo lo demás —el orden de las observaciones, sus valores individuales— puede desaparecer.
El traslado al contexto de un agente solo es honesto si se admite lo que no traslada: en estadística la suficiencia se demuestra respecto a un parámetro y un modelo paramétrico, y aquí no hay ni lo uno ni lo otro. La formulación que sí encaja es la del cuello de botella de información —«finding a short code for X that preserves the maximum information about Y»—, que sus autores describen como una generalización de la teoría de tasa-distorsión en la que la medida de distorsión emerge de la estadística conjunta. El resumen correcto de un transcript depende de la pregunta que se le hará después; no existe un resumen bueno con independencia de esa pregunta.
ALLAN tiene un caso de laboratorio de esto, y lo tiene por escrito: el mismo
transcript se comprime de dos maneras distintas según qué decisión sostenga. Para
«¿está atascada esta operación?» el motor renderiza cuatro mensajes, 500 caracteres
cada uno y 2.000 en total (Platform Server/internal/agents/lease.go:129-145,
invocado así en swarm_loop_v3.go:1610). Para «¿ha estado progresando esta
ejecución?», doce mensajes, 900 por mensaje y 8.000 en total, con el motivo escrito:
«a lease asks "is this one operation stuck?", where only the last turn matters,
while a budget checkpoint asks "has this run been making progress?", which cannot be
answered from a single turn - and, when that turn is a page of CRM records, a
2000-char tail is one truncated JSON blob with no visible plan at all (the
2026-07-28 incident)» (lease.go:147-158).
Más interesante es cómo trunca. truncateMiddle (lease.go:205-222) corta por el
medio, no por la cola, porque «each message is truncated in the MIDDLE (a huge tool
result keeps both what it is and how it ended, e.g. a pagination cursor)»
(lease.go:163-167). Es una hipótesis de suficiencia explícita: para juzgar el
progreso bastan lo que identifica el resultado y lo que dice cómo continuar. Salió de
un incidente, no de una medición, pero está enunciada y por tanto es refutable.
El resto de las compresiones del motor son menos deliberadas. La ventana de
conversación son los últimos doce turnos recortados a 1.200 cada uno —los dos
valores están escritos a mano en la llamada,
renderConversation(a.Conversation, 12, 1200)
(Platform Server/internal/app/app.go:4702-4728)—, una regla que el propio
diagnóstico de la memoria v2 recoge como defecto heredado, junto a la anomalía de
unos resúmenes de sesión que «se pagan y se tiran»
(docs/arquitectura/agent-memory-v2-design.md:12-14).
Y conviene precisar qué son esos 1.200, porque el motor se contradice. El
comentario de renderConversation afirma que cada turno queda «excerpted to
excerptLimit runes» (app.go:4706-4712), pero excerptText recorta por índice
de byte: text[:limit] (app.go:4813-4824). De los tres truncadores del motor dos
cortan por runas —truncateText (swarm_loop_v3.go:2694-2705) y clipText
(app.go:4826-4835)— y el que corta por bytes es justo el que gobierna el historial
de conversación, el buzón y el roster (app.go:5070 y :5088). En prosa española
acentuada eso son unos 1.150 caracteres reales, no 1.200, y la posibilidad de partir
una secuencia UTF-8 y dejar un carácter de reemplazo en mitad del historial. El
mismo patrón rebana el aplanado del paquete (package_context.go:161-173). No es
una catástrofe: es una discrepancia entre lo que el código declara y lo que hace, en
la partida de contexto más voluminosa y más dependiente del idioma.
El bloque de memoria se rinde bajo un presupuesto de 800 tokens, con techos duros de
12 hechos y 4 episodios (Platform Server/internal/memory/retrieval.go:99-119), y
ningún llamante lo sobrescribe: MemoryContextSection construye la petición sin
fijar TokenBudget (internal/app/memory_v2.go:128-133), de modo que los 800 por
defecto son el presupuesto real de producción, igual para un saludo que para una
misión de veinte pasos.
La compresión más agresiva es la que menos garantías tiene. Cuando un trabajador del
enjambre termina, su contexto entero se destruye: al raíz solo le llega una cabecera
con estado y contadores más el último texto que el trabajador escribió
(swarm_loop_v3.go:2356-2368). El requisito de suficiencia existe, pero vive en el
prompt —«findings first with concrete evidence (file:line, tool output, sources)»
(swarm_loop_v3.go:2470-2477)— y nada comprueba que se haya cumplido. Es el
problema de Fisher trasladado a una arquitectura distribuida, con el agravante de
que aquí el estadístico lo elige el propio modelo.
La posición dentro del canal
Que un canal tenga capacidad no implica que la use de forma uniforme, y este no lo hace. Liu y sus coautores lo midieron sobre dos tareas de recuperación y lo escribieron sin ambigüedad: «performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts, even for explicitly long-context models».
ALLAN toma una decisión de posición y la argumenta. El sello de reloj —fecha, hora
y zona— se añade como último mensaje de cada petición, nunca dentro del prompt de
sistema, y el comentario del código da dos razones a la vez: «Appended last, the
entire prefix - system prompt, constitution, skills, memory, history - stays
byte-for-byte identical between calls, the cache keeps hitting, and the model reads
the hour as the most recent thing in its context»
(Platform Server/internal/models/clock.go:16-25). La primera razón es
verificable contra la documentación del proveedor: la caché se indexa por prefijo
—«Prompt caching references the entire prompt - tools, system, and messages
(in that order) up to and including the block designated with cache_control»— y
«Changes at each level invalidate that level and all subsequent levels», con
lecturas de caché a «0.1 times the base input tokens price». La segunda —«donde más
peso tiene»— es coherente con Liu et al., pero es más débil de lo que suena, y no
sólo porque en el árbol no haya experimento que la sostenga: la curva de Liu et al.
es en U y no monótona —«at the beginning or end»—, de modo que la atención por
sí sola no elige el final frente a la cabecera y habría privilegiado igual un sello
puesto en el primer mensaje. Lo que descarta esa alternativa es la caché de prefijo.
El argumento decisivo aquí es económico; el atencional es un refuerzo enunciado con
más seguridad de la que la fuente concede.
La inyección es un punto único: completeChat es «the single choke point every
text completion passes through - Generate, GenerateWithTools, blocking and
streaming alike» (Platform Server/internal/models/openai.go:641-646). Un solo
sitio es lo que convierte una preferencia de estilo en un invariante comprobable.
Dentro del bloque de memoria el orden sí está pensado —perfiles, hechos vigentes
fechados, episodios como punteros (retrieval.go:295-353)—, pero dónde cae el
bloque entero no lo decidió nadie. Viaja pegado al final del texto del paquete
(internal/app/swarm_v3.go:65-69), y rootUserPrompt coloca después el catálogo de
skills, la conversación previa, los presupuestos, los hitos activos y, al final, la
petición del usuario (swarm_loop_v3.go:2450-2468). Es decir: lo más caro de
producir y lo más específico del turno acaba en el medio, que es la zona que Liu
et al. señalan como peor.
La degradación con la longitud
La evidencia reciente va más allá de la posición: la longitud sola degrada. RULER midió diecisiete modelos de contexto largo y concluyó que «almost all models exhibit large performance drops as the context length increases», y que de los que declaran 32K o más, «only half of them can maintain satisfactory performance at the length of 32K». NoLiMa lo endureció eliminando el solapamiento léxico entre pregunta y aguja: «At 32K, for instance, 11 models drop below 50% of their strong short-length baselines. Even GPT-4o, one of the top-performing exceptions, experiences a reduction from an almost-perfect baseline of 99.3% to 69.7%». El informe de Chroma lo generaliza a tareas triviales: «models do not use their context uniformly; instead, their performance grows increasingly unreliable as input length grows».
El mismo informe contiene dos resultados que van más allá de la longitud y muestran que el tamaño no determina el valor. El primero: «As needle-question similarity decreases, model performance degrades more significantly with increasing input length» —longitud y afinidad interactúan, y el mismo número de tokens penaliza más o menos según cómo esté redactada la pregunta—. El segundo es contraintuitivo: «Models perform worse when the haystack preserves a logical flow of ideas. Shuffling the haystack and removing local coherence consistently improves performance». Mismos tokens, mismo contenido, otro orden, mejor resultado. Quien ordena y da coherencia a un contexto dando por hecho que eso ayuda actúa sobre una intuición que este experimento contradice.
La lectura para un motor agéntico no es «los contextos largos no funcionan», que sería falso, sino que la capacidad declarada y la útil divergen, que la divergencia crece, y que dos contextos idénticos en tamaño pueden separarse en utilidad por razones que ningún contador de tokens registra. Anthropic lo formula como presupuesto: «Every new token introduced depletes this budget by some amount».
Aquí ALLAN tiene una ausencia que conviene nombrar sin adornos: no hay
compactación. La lista de mensajes de una ejecución del enjambre crece por
append y nunca se poda: no existe en swarm_loop_v3.go ninguna truncación,
resumen ni desalojo del historial. El único límite es indirecto —MaxSteps,
MaxToolCalls y el presupuesto de la misión— y opera sobre el número de llamadas,
no sobre el tamaño de cada una. Que en la práctica no reviente se debe a que los
topes de pasos son pequeños, no a que el problema esté resuelto.
El catálogo de herramientas como presupuesto fijo
Hay una parte del contexto que no depende de la conversación y se paga íntegra en cada llamada: las definiciones de herramientas. La documentación de Anthropic pone número al orden de magnitud: «A typical multiserver setup (GitHub, Slack, Sentry, Grafana, and Splunk) can consume ~55k tokens in definitions before Claude does any work», y añade el efecto que no es de coste sino de acierto: «Claude's ability to pick the right tool degrades once you exceed 30–50 available tools». La entrada de ingeniería sobre ejecución de código es igual de explícita sobre el mecanismo —«Most MCP clients load all tool definitions upfront directly into context»— y cuantifica lo que se ahorra al no hacerlo en un flujo concreto: «This reduces the token usage from 150,000 tokens to 2,000 tokens—a time and cost saving of 98.7%».
El peaje empieza además antes de la primera definición: la tabla de precios cifra el
coste de tener herramientas, esquemas aparte, en «286 tokens» de prompt de sistema
con tool_choice en auto y «406 tokens» con any para Opus 5.
ALLAN paga ese presupuesto por llamada. El raíz reconstruye la lista completa en cada
paso del bucle (swarm_loop_v3.go:666) y el trabajador la construye una vez pero la
adjunta en cada petición (:1589 y :1599-1604), proyectada por ModelTools
(internal/agents/tool_runtime.go:147-183).
El tamaño de ese presupuesto no lo elige quien escribe el agente. En el árbol
aparecen cerca de cincuenta y cinco nombres con prefijo de motor —builtin.,
tenant., a2a., org. y allan.—, de los que solo seis tienen compuerta propia:
los tres de programación de eventos, tras autonomy.can_schedule_tasks, y los tres
del encargo, que existen solo mientras corre un contrato. El resto es suelo, porque
la regla de visibilidad (tool_runtime.go:539-577) establece que las nativas
«bypass the manifest's connector allow-list»: allowed_tools gobierna los
conectores, no el suelo. Ese suelo cae ya dentro de la franja donde el proveedor
sitúa la degradación de selección, y encima se suman los conectores MCP habilitados.
No hay en el motor ningún mecanismo de carga diferida ni de búsqueda sobre el
catálogo: el equivalente de defer_loading no existe.
El propio proveedor publica el umbral a partir del cual recomienda dejar de cargarlo todo por delante —«Use tool search when any of the following apply: You have 10 or more tools available. Your tool definitions consume more than 10k tokens.»—, y ALLAN lo supera por un factor de cinco antes de habilitar un solo conector. Publica también la respuesta a la objeción que un motor con esta disciplina de prefijo pondría primero: «Internally, the API excludes deferred tools from the system-prompt prefix. […] The prefix is untouched, so prompt caching is preserved». Diferir la carga y conservar el acierto de caché no son objetivos incompatibles.
Divulgación progresiva: lo que sí está construido
La respuesta correcta a un presupuesto fijo es no gastarlo: publicar el índice y cobrar el cuerpo solo cuando se pide. Nielsen lo formuló para interfaces en 2006 —«Initially, show users only a few of the most important options. Offer a larger set of specialized options upon request»— y es, palabra por palabra, la disciplina de skills del motor.
SkillCatalogEntry es «one skill's flat, frontmatter-only metadata: enough for the
model to judge relevance on its own, never the skill's full instructions»
(Platform Server/internal/agents/swarm_skills.go:11-26); el catálogo se rinde como
una línea por skill —id, descripción, disparadores— con la frase que cierra la
puerta, «skills you have not loaded are not available to you»
(swarm_skills.go:37-47), y el cuerpo llega como resultado de allan.skills/use,
validada contra el catálogo (swarm_skills.go:127-170). El coste del índice es
proporcional al número de skills; el del cuerpo, a las realmente usadas. Los hitos
de flow repiten el patrón: sus cuerpos «travel progressively (catalog + tool
results) and must not be duplicated here» (internal/agents/flow_context.go:32-38).
El corpus extendió la disciplina a las otras dos fuentes de conocimiento, y ahí el
código se queda corto. La memoria organizacional declara que «el "mapa" de ~150
tokens del v1 es un párrafo publicitario» y debe sustituirse por un catálogo «con el
mismo patrón que renderSkillCatalogSection»
(docs/memoria-organizacional/organizational-memory-design.md:131-135). El motor
sigue inyectando el mapa (internal/app/memory_v2.go:159-166): el catálogo no se
construyó.
La biblioteca personal fija presupuestos explícitos —«Catálogo de colecciones: ≤300
tokens, siempre» y «Cuerpo: ≤4.000 tokens por turno = 1 WU»
(docs/arquitectura/personal-sources-design.md:346-347)— tras descartar por escrito
el umbral «si cabe, entrégala entera», que a 200.000 tokens «cuesta 50 WU por
turno» (íd. :334-342). En el motor el catálogo personal existe, pero no se
inyecta siempre: se alcanza como resultado de una herramienta
(internal/app/personal_tools.go:195-215). El «siempre» del diseño no está.
El corolario incómodo: la unidad de trabajo mide tokens
La Work Unit se define como «4.000 tokens ponderados»
(docs/economia/work-units-design.md:118-122) y se calcula, en el motor, así:
WU_cog = [ κ_in·(w_in·T_in_nc + w_cache·T_in_c) + w_out·(T_visible + T_reasoning_rated) ] / N, con w_in = 1,0, w_cache = 0,1, w_out = 4,0,
N = 4.000 y κ por clase de ejecución
(internal/economics/rating.go:90-127 y :219-241). El medidor distingue cuatro
cosas —entrada frente a salida, cacheada frente a no cacheada, clase de ejecución y
razonamiento tarificado— y ninguna otra.
La afirmación fuerte —«el medidor está mal»— no se sostiene, y conviene decirlo
antes de defender la débil. La única distinción que hace entre dos contextos del
mismo tamaño, cacheado frente a no cacheado, no es arbitraria: espeja lo que el
proveedor cobra, «0.1 times the base input tokens price». Y el propio diseño declara
que mide consumo y no valor —«un modelo más eficiente consume menos WU para el mismo
resultado. Esa es la diferencia entre consumo y calidad» (work-units-design.md:47)
y «Los WC compran capacidad de intentar el trabajo, no un entregable aceptado» (íd.
:111)—. Un medidor de ocupación de canal que se anuncia como tal no es un error.
Lo que sí se sostiene es la versión precisa, y tiene aval clásico: Shannon excluyó el significado del problema que estaba resolviendo —«These semantic aspects of communication are irrelevant to the engineering problem»—. Contar tokens es contar transporte. Que dos contextos del mismo tamaño valgan distinto ya no es conjetura: barajar el pajar mejora el rendimiento sin cambiar un token, y quitar el solape léxico lo hunde sin cambiar la longitud. El medidor no puede ver ninguna de las dos cosas porque no está mirando ahí. La consecuencia no es contable sino de ingeniería: el único gradiente que el sistema ofrece a quien diseña el contexto apunta a inyectar menos, sin distinguir si lo recortado era o no parte del estadístico suficiente. La cláusula que hace verdadera la frase del diseño es «para el mismo resultado», y el resultado no se mide. Comprimir bien y comprimir a secas se ven idénticos en el libro mayor.
Existe una señal que podría corregir eso y no lo hace. Al terminar el renderizado el
motor sella las aristas que llegaron al prompt, y el comentario dice: «Runs after
rendering so only genuinely-used facts earn their decay exemption (CM0)»
(retrieval.go:164-169). El comentario afirma más que el código: renderedEdgeIDs
registra lo que se inyectó, no lo que el modelo usó. Esa diferencia es
justamente la magnitud que haría falta para saber si el contexto se ganó sus tokens.
Hay una segunda grieta, más pequeña y más comprobable: el motor planifica en bytes y
el proveedor cobra en tokens. El presupuesto de memoria se convierte con
approxCharsPerToken = 4 y se compara contra len(s), que en Go son bytes
(retrieval.go:99-119 y :302-314); en el árbol no existe ningún tokenizador. La
constante es la regla del propio proveedor —«As a rough estimate, 1 token is
approximately 4 characters or 0.75 words in English»— con dos salvedades que el
motor no recoge: se enuncia in English, mientras cada acento español gasta el
doble de presupuesto en bytes, y el factor no es estable ni dentro del mismo
proveedor —«This tokenizer produces approximately 30% more tokens for the same
text»—. Ninguna de las cifras que el motor llama «tokens» (800 de memoria, ~150 del
mapa organizacional, 120.000 del paquete) se ha medido contra un tokenizador real, y
todas se mueven solas cuando el despliegue cambia de generación de modelo.
Invariantes, enunciados para poder ser refutados
Los siguientes enunciados son propiedades que el código sostiene hoy. Cada uno indica qué observación bastaría para tumbarlo.
Toda completación de texto lleva el sello de reloj como último mensaje, y ningún
sitio de construcción de prompt puede saltárselo. Falso si aparece una ruta de
completación en internal/models que no pase por completeChat y no llame a
withSystemClock.
El bloque de memoria entra en el prompt exactamente una vez por turno. Falso si
MemoryContextSection se ejecuta dos veces en el mismo turno; el parámetro
includeMemory existe porque antes ocurría (app.go:5045-5051).
El bloque de memoria nunca supera 800 tokens nominales, 12 hechos y 4 episodios.
Falso si algún llamante fija TokenBudget, o si el recuento por bytes deja pasar
más de lo declarado.
El cuerpo de una skill nunca entra en el prompt si el modelo no lo pidió por id.
Falso si alguna ruta llama a SkillLoader fuera de executeSkillUse.
Una herramienta de conector es invisible si allowed_tools no la nombra; una
nativa es visible siempre. Falso si toolVisibleToAgent deja pasar un conector
sin patrón que lo cubra, o esconde una nativa sin un deny explícito.
El catálogo de herramientas viaja íntegro en cada llamada al modelo del bucle del
enjambre. Falso si aparece un paso de raíz o de trabajador cuya ToolRequest
no lleve el catálogo completo que su runtime proyecta.
Nada se elimina nunca de la lista de mensajes de una ejecución. Falso si
aparece una operación de poda, resumen o desalojo sobre r.messages o messages
en swarm_loop_v3.go.
Ninguna llamada al modelo ve su techo de salida recortado por el saldo restante de
la misión. Falso si aparece un llamante de MissionBudget.ClampCall fuera de sus
propias pruebas.
El resumen de sesión no llega nunca a un prompt. Falso si algún constructor de
prompt lee session.Summary para algo que no sea un booleano o una traza.
Lo que falta, lo que está roto y lo que no tiene evidencia
No hay compactación de contexto en el motor. Es la carencia mayor, y la única cuya
ausencia se notará en cuanto los topes de pasos suban. Lo que más se le parece está
construido y desconectado: refreshSessionSummary genera con un modelo, cada cinco
turnos de asistente, un resumen de la sesión y lo persiste (app.go:4779-4811), y
sus dos únicos lectores en todo el motor son un booleano has_summary (app.go:928)
y una línea de traza (app.go:1014). El diagnóstico que motivó el rediseño de
memoria —«nunca los reinyecta (se pagan y se tiran)»— sigue siendo literalmente
cierto, y describe justamente la pieza que la compactación necesitaría: «taking a
conversation nearing the context window limit, summarizing its contents, and
reinitiating a new context window with the summary».
La reserva de salida por llamada tampoco está cableada. MissionBudget.ClampCall
encoge el techo de salida hasta que la reserva quepa en el saldo, y su comentario
explica por qué debe aplicarse antes de emitir la petición: «rating the excess away
afterwards would leave the provider's bill already incurred»
(internal/economics/budget.go:269-280). Buscar el símbolo en los nueve
repositorios devuelve su definición y dos pruebas: ningún llamante de producción.
No hay tokenizador. Todos los presupuestos son de bytes disfrazados de tokens.
No hay carga diferida de herramientas: el suelo nativo, cerca de medio centenar de nombres, se paga entero en cada llamada de cada agente, tenga sentido o no para su trabajo. El catálogo organizacional no existe —sigue inyectándose el mapa que su propio diseño califica de párrafo publicitario— y el personal existe como herramienta, no como inyección permanente, contra lo que dice el suyo.
La medición es parcial donde importa: en streaming la telemetría depende de que el
proveedor honre stream_options.include_usage, y si no lo hace «usage stays nil and
nothing is reported here» (internal/models/openai.go:1030-1062). Esa llamada se
mide como cero.
Y, sobre todo, no hay evidencia interna de nada de lo anterior: ninguna medición de si el bloque de memoria cambia la respuesta, de si el sello al final se lee mejor que en el prefijo, ni de cuántos tokens reales ocupan los 800 nominales. Tampoco existe un desglose de qué fracción de los tokens de entrada de un turno es catálogo de herramientas, memoria, historial o constitución; construirlo es la única tarea de esta lista que desbloquea a las demás. Las decisiones de este artículo están bien argumentadas y bien alineadas con la literatura publicada; ninguna está validada aquí. Esa es la deuda que conviene no confundir con las otras.
Referencias
Shannon, C. E. (1948). A Mathematical Theory of Communication. The Bell System Technical Journal, vol. 27, pp. 379–423, 623–656. https://people.math.harvard.edu/~ctm/home/text/others/shannon/entropy/entropy.pdf — «The fundamental problem of communication is that of reproducing at one point either exactly or approximately a message selected at another point.» · «Frequently the messages have meaning; that is they refer to or are correlated according to some system with certain physical or conceptual entities. These semantic aspects of communication are irrelevant to the engineering problem.» · «This does not mean that the teletype channel will always be transmitting information at this rate — this is the maximum possible rate and whether or not the actual rate reaches this maximum depends on the source of information which feeds the channel, as will appear later.»
Fisher, R. A. (1922). On the Mathematical Foundations of Theoretical Statistics. Philosophical Transactions of the Royal Society A, 222, 309–368 (p. 316). https://jhanley.biostat.mcgill.ca/bios601/Likelihood/Fisher1922.pdf — «That the statistic chosen should summarise the whole of the relevant information supplied by the sample.» · «This may be called the Criterion of Sufficiency.» Advertencia de procedencia: las dos copias localizadas del original (McGill y UNC) son PDF escaneados de los que la herramienta de recuperación de esta revisión no consigue extraer texto; las frases de arriba proceden de la redacción anterior de este artículo y no han podido re-verificarse contra el original en esta pasada. La entrada siguiente es la corroboración independiente que sí se ha recuperado.
Hand, D. J. (2015). From evidence to understanding: a commentary on Fisher (1922) 'On the mathematical foundations of theoretical statistics'. Philosophical Transactions of the Royal Society A, 373(2039):20140252. https://pmc.ncbi.nlm.nih.gov/articles/PMC4360088/ — «an estimator is sufficient if it contains the whole of the information about the unknown parameter that is contained in the sample»
Tishby, N., Pereira, F. C. y Bialek, W. (2000). The information bottleneck method. arXiv physics/0004057. https://arxiv.org/abs/physics/0004057 — «We formalize this problem as that of finding a short code for X that preserves the maximum information about Y.» · «This constrained optimization problem can be seen as a generalization of rate distortion theory in which the distortion measure d(x,x̃) emerges from the joint statistics of X and Y.»
Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F. y Liang, P. (2023). Lost in the Middle: How Language Models Use Long Contexts. arXiv 2307.03172. https://arxiv.org/abs/2307.03172 — «We find that performance can degrade significantly when changing the position of relevant information, indicating that current language models do not robustly make use of information in long input contexts.» · «In particular, we observe that performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts, even for explicitly long-context models.»
Hsieh, C.-P., Sun, S., Kriman, S., Acharya, S., Rekesh, D., Jia, F., Zhang, Y. y Ginsburg, B. (2024). RULER: What's the Real Context Size of Your Long-Context Language Models?. arXiv 2404.06654 (v3). https://arxiv.org/abs/2404.06654 — «Despite achieving nearly perfect accuracy in the vanilla NIAH test, almost all models exhibit large performance drops as the context length increases.» · «While these models all claim context sizes of 32K tokens or greater, only half of them can maintain satisfactory performance at the length of 32K.»
Modarressi, A., Deilamsalehy, H., Dernoncourt, F., Bui, T., Rossi, R. A., Yoon, S. y Schütze, H. (2025). NoLiMa: Long-Context Evaluation Beyond Literal Matching. arXiv 2502.05167 (v3). https://arxiv.org/abs/2502.05167 — «At 32K, for instance, 11 models drop below 50% of their strong short-length baselines. Even GPT-4o, one of the top-performing exceptions, experiences a reduction from an almost-perfect baseline of 99.3% to 69.7%.» · «Our analysis suggests these declines stem from the increased difficulty the attention mechanism faces in longer contexts when literal matches are absent, making it harder to retrieve relevant information.»
Hong, K., Troynikov, A. y Huber, J. (2025). Context Rot: How Increasing Input Tokens Impacts LLM Performance. Chroma Research, 14 de julio de 2025. https://www.trychroma.com/research/context-rot — Informe técnico de proveedor, no revisado por pares; protocolo descrito y dieciocho modelos evaluados. «Our results reveal that models do not use their context uniformly; instead, their performance grows increasingly unreliable as input length grows.» · «We demonstrate that even under these minimal conditions, model performance degrades as input length increases, often in surprising and non-uniform ways.» · «As needle-question similarity decreases, model performance degrades more significantly with increasing input length.» · «Models perform worse when the haystack preserves a logical flow of ideas. Shuffling the haystack and removing local coherence consistently improves performance.»
Rajasekaran, P., Dixon, E., Ryan, C. y Hadfield, J. — Anthropic (2025). Effective context engineering for AI agents, 29 de septiembre de 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents — Entrada de blog de proveedor; sin datos reproducibles desde fuera. «Context, therefore, must be treated as a finite resource with diminishing marginal returns.» · «Like humans, who have limited working memory capacity, LLMs have an "attention budget" that they draw on when parsing large volumes of context.» · «Every new token introduced depletes this budget by some amount, increasing the need to carefully curate the tokens available to the LLM.»
Anthropic (2025). Tool search tool. Documentación de la plataforma Claude. https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool — Documentación de producto de un proveedor; las cifras son suyas y no independientes. «Instead of loading all tool definitions into the context window up front, Claude searches your tool catalog (including tool names, descriptions, argument names, and argument descriptions) and loads only the tools it needs.» · «A typical multiserver setup (GitHub, Slack, Sentry, Grafana, and Splunk) can consume ~55k tokens in definitions before Claude does any work.» · «Claude's ability to pick the right tool degrades once you exceed 30–50 available tools.» · «Use tool search when any of the following apply: You have 10 or more tools available. Your tool definitions consume more than 10k tokens.» · «Internally, the API excludes deferred tools from the system-prompt prefix. […] The prefix is untouched, so prompt caching is preserved.»
Anthropic (2025). Code execution with MCP: Building more efficient agents, 4 de noviembre de 2025. https://www.anthropic.com/engineering/code-execution-with-mcp — Entrada de blog de proveedor. «Most MCP clients load all tool definitions upfront directly into context, exposing them to the model using a direct tool-calling syntax.» · «Tool descriptions occupy more context window space, increasing response time and costs.» · «This reduces the token usage from 150,000 tokens to 2,000 tokens—a time and cost saving of 98.7%.» · «Presenting tools as code on a filesystem allows models to read tool definitions on-demand, rather than reading them all up-front.»
Anthropic (consultado el 4 de agosto de 2026). Pricing. Documentación de la
plataforma Claude. https://platform.claude.com/docs/en/about-claude/pricing —
Documentación de producto de un proveedor. «As a rough estimate, 1 token is
approximately 4 characters or 0.75 words in English.» · «This tokenizer produces
approximately 30% more tokens for the same text. The exact increase depends on the
content and workload shape.» · «Cache read (hit) | 0.1x base input price» · Tabla
del coste de habilitar herramientas: «Claude Opus 5 | auto, none / any,
tool | 286 tokens / 406 tokens».
Anthropic (2025). Prompt caching. Documentación de la plataforma Claude.
https://platform.claude.com/docs/en/build-with-claude/prompt-caching — «Prompt
caching references the entire prompt - tools, system, and messages (in that
order) up to and including the block designated with cache_control.» · «Changes
at each level invalidate that level and all subsequent levels.» · «Cache read
tokens are 0.1 times the base input tokens price.»
Nielsen, J. (2006). Progressive Disclosure. Nielsen Norman Group, 3 de diciembre de 2006. https://www.nngroup.com/articles/progressive-disclosure/ — «Initially, show users only a few of the most important options. Offer a larger set of specialized options upon request.» · «Progressive disclosure thus improves 3 of usability's 5 components: learnability, efficiency of use, and error rate.»
Miller, G. A. (1956). The Magical Number Seven, Plus or Minus Two: Some Limits on our Capacity for Processing Information. Psychological Review, 63, 81–97. https://psychclassics.yorku.ca/Miller/ — «This asymptotic value we take to be the channel capacity of the observer: it represents the greatest amount of information that he can give us about the stimulus on the basis of an absolute judgment.» · «The channel capacity is the upper limit on the extent to which the observer can match his responses to the stimuli we give him.»