Contexto

Todo agente trabaja dentro de una ventana de contexto: el registro en curso de tu conversación, los archivos que leyó y la salida de cada herramienta que ejecutó. En una tarea corta, ese registro se mantiene pequeño. En una larga, como una revisión forense de varios pasos, una refactorización grande o una tarde de ida y vuelta, crece rápido, y ahí es donde la mayoría de los agentes fallan sin que se note.

Por qué las ejecuciones largas se desvían

A medida que la ventana se llena, un modelo pierde el acceso confiable a sus instrucciones originales. Empieza a olvidar las restricciones que estableciste al principio, a apoyarse en salidas de herramientas obsoletas y a desviarse hacia objetivos secundarios. Lo importante es que la calidad cae mucho antes del límite estricto de tokens, no al llegar a él. Un agente puede verse bien y aun así estar funcionando con un contexto que ya perdió el hilo del trabajo. Si lo fuerzas un poco más, no solo se degrada: desborda la ventana y la llamada falla por completo.

Perch está hecho para ejecuciones largas, así que trata la ventana de contexto como algo que hay que administrar activamente en cada turno, no como algo que se llena hasta que da error.

El pipeline de compactación

Antes de cada llamada al modelo, Perch pasa el contexto de trabajo por un pipeline ordenado. Cada etapa es más barata y menos destructiva que la siguiente, así los pasos costosos y con pérdida solo se ejecutan cuando los baratos y sin pérdida no alcanzaron.

Paso uno: recortar primero los artefactos pesados, siempre

Las ejecuciones largas engordan con cargas útiles voluminosas y de poco valor: instantáneas completas de páginas del navegador y capturas de pantalla del operador. Perch las recorta en cada turno, incluso antes de revisar el presupuesto. Las instantáneas de página se reducen a sus partes accionables (los controles y la estructura sobre los que el modelo podría actuar), y las más antiguas se reducen a versiones mínimas. Las capturas de pantalla se descartan o se comprimen hasta un tope estricto de tokens. Esto es pura eliminación de desperdicio, así que es incondicional. Una sola instantánea DOM en bruto o una captura de pantalla puede costar más que docenas de turnos de razonamiento real, y casi nunca se necesita unos pasos después.

Paso dos: microcompactar la salida obsoleta de las herramientas, sin llamar al modelo

Si la ejecución sigue por encima del presupuesto, Perch vacía el contenido de los resultados de herramientas más antiguos y conserva textualmente los más recientes. El emparejamiento entre la llamada a la herramienta y su resultado se mantiene intacto; solo el contenido obsoleto del resultado se reemplaza por un marcador breve. Esto importa sobre todo en las cargas de trabajo para las que Perch está hecho: una ejecución forense que lee docenas de archivos y corre muchas comprobaciones en el sandbox acumula una cantidad enorme de salida de herramientas, y el modelo rara vez necesita el texto en bruto de un archivo que leyó hace veinte pasos, solo la conclusión que sacó de él. Este paso es barato, no implica ninguna llamada extra al modelo y a menudo libera suficiente espacio para saltarse por completo el resumen costoso. Ocurre en silencio, porque vaciar el contenido obsoleto de las herramientas es un ahorro de rutina, no un evento por el que valga la pena interrumpirte.

Paso tres: resumir los turnos más antiguos, solo si aún se excede el presupuesto

Si la ejecución sigue por encima del presupuesto después de los pasos baratos, y solo entonces, Perch resume el tramo más antiguo de la conversación en un registro compacto de lo que pasó y lo que se decidió, incorporando cualquier resumen anterior, y sigue trabajando a partir de ahí. Este es el único paso costoso y con pérdida, así que se ejecuta al final. Cuando se ejecuta, se hace visible: la transcripción marca el momento e informa qué cambió.

Paso cuatro: límite estricto como red de seguridad

Como garantía final, Perch aplica el tamaño real de la carga útil contra el límite del modelo antes de enviarla, recortando desde los mensajes más antiguos y conservando un mínimo de turnos recientes. Esta es la red de seguridad que hace que los fallos por desbordamiento sean estructuralmente imposibles: incluso en un caso inusual, la solicitud que llega al modelo siempre cabe.

Medir la ventana real, no una suposición

Las estimaciones de tokens basadas en el conteo de caracteres subestiman de forma sistemática el contenido denso: CSV, JSON, código y largas columnas de números. Eso es justo lo que llena una ejecución financiera o documental. Una estimación ingenua hace que la compactación se active tarde o nunca, y la carga útil se desborda. Perch calibra su estimación con el conteo real de tokens del prompt que reportó el proveedor en la llamada anterior de la misma ejecución, y ancla a ese conteo el disparador de la compactación. La compactación se activa según el tamaño real del contexto, no según una suposición que se equivoca justo en la dirección que hace daño.

Preservar el hilo activo

La compactación nunca toca aquello en lo que estás trabajando en este momento. Perch siempre conserva palabra por palabra un tramo final reciente de la conversación, dimensionado según un presupuesto real de tokens y no según un número fijo de mensajes, y mantiene las llamadas a herramientas emparejadas con sus resultados para que el historial reciente siga siendo coherente. El contexto antiguo se comprime; el hilo activo no se toca.

Respetar el presupuesto real de tu modelo

Perch compacta según el límite de contexto que realmente se aplica a tu ejecución, incluida la ventana más grande que desbloquea un nivel superior, y no según la ventana bruta del modelo subyacente que esté atendiendo el turno. Además, apunta a un presupuesto de trabajo real con margen, en lugar de quedar justo por debajo del tope y volver a llenarse un paso después, así el modelo conserva espacio para pensar en los turnos siguientes.

Visible, no silenciosa

La compactación real es algo que puedes ver. El medidor de contexto muestra qué tan llena está la ventana, y cuando Perch hace un resumen, marca el momento en la transcripción e informa qué cambió: cuánto se liberó, cuánto se resumió, qué tan grande es el resumen y cuánto historial reciente se conservó. Nunca te quedas adivinando si el agente sigue teniendo el hilo. Los pasos baratos en segundo plano se mantienen en silencio; el único paso con pérdida siempre se muestra.

Por qué importa

Esta es la diferencia entre un agente que luce bien en una demo de una tarea de cinco pasos y uno en el que puedes confiar en una ejecución larga y de alto riesgo. Una revisión forense que abarca docenas de lecturas de archivos y comprobaciones en el sandbox tiene que mantenerse anclada a la pregunta original durante todo el recorrido, y no puede fallar a la mitad porque la ventana se desbordó. Perch mantiene el trabajo largo preciso y acotado por diseño, así la respuesta al final se fundamenta en las mismas instrucciones que diste al principio.