Context Manager: depurar el contexto en un IDE agéntico

En un entorno de desarrollo agéntico, escribir el siguiente prompt es solo una parte del trabajo. El agente también opera con instrucciones del proyecto, skills, herramientas, resultados anteriores y decisiones acumuladas durante la sesión. Ese conjunto condiciona lo que hará después.

Mi propuesta es dar a ese contexto una interfaz propia: un Context Manager que se abra desde el indicador circular de contexto del compositor. Un lugar para inspeccionar el estado de la sesión, seleccionar los bloques que participarán en la siguiente acción y crear ramas para comparar alternativas.

El objetivo es mejorar el context engineering: diseñar y revisar la información y las capacidades que ponemos a disposición del agente para una tarea concreta. Quiero que podamos depurar ese contexto con una intención tan clara como cuando revisamos un diff.

Del indicador de uso a una superficie de control

La siguiente captura, aportada y anotada por AIPRODUCTGOD, señala el punto de entrada propuesto en Devin Desktop, antes Windsurf. El rótulo rojo sitúa la mejora; el desplegable que se describe a continuación es un diseño conceptual.

Hoy, un indicador de ocupación puede ayudarnos a entender cuánto espacio queda. La oportunidad de diseño es responder también a otras preguntas: ¿qué se está incluyendo, de dónde viene, por qué sigue activo y qué cambiaría si lo excluyera?

Esta propuesta está pensada para entornos como Devin, Codex y Antigravity, y nace de una sesión real de trabajo. El prototipo al final del artículo permite explorar la interacción propuesta.

Un árbol de contexto para la siguiente acción

Al pulsar el círculo, se abriría un panel desplegable con grupos expandibles y casillas. Cada bloque mostraría su procedencia, alcance y estado: disponible, incluido, resumido, excluido o protegido. La selección correspondería a una acción concreta y a una versión del contexto.

1. System prompt e instrucciones. Una vista de las instrucciones que el producto permite inspeccionar, incluyendo las del proyecto y sus prioridades. Las instrucciones de plataforma no expuestas se representarían como una capa protegida; el inspector no debe prometer acceso a contenido interno que el proveedor no publica. Las reglas obligatorias serían de solo lectura.

2. Skills, herramientas y contexto asociado. Un listado de skills y capacidades disponibles, con su origen y recursos vinculados. Conviene distinguir tres cosas: que una herramienta esté disponible, que sus instrucciones estén cargadas y que sus resultados anteriores formen parte del contexto. Seleccionar una skill tampoco implica que todo su contenido ya se haya cargado: la interfaz debería hacer visible esa diferencia.

3. Memoria de sesión. Un árbol de intercambios con los prompts del usuario y las respuestas visibles del asistente. También incluiría los resúmenes, archivos referenciados y resultados de herramientas que el sistema conserve. No se trata de exponer razonamiento interno privado. Si la conversación se ha compactado, debe indicarse qué mensajes fueron sustituidos por qué resumen.

4. Tool guardrails. Una vista de los límites efectivos de ejecución: permisos, ámbitos y puntos de aprobación. Aquí es esencial separar las preferencias de la tarea de las restricciones que aplica el sistema. Desmarcar un bloque de contexto nunca debería conceder permisos ni desactivar una protección obligatoria.

Para que el árbol sea útil, las dependencias también deben ser visibles. Excluir un resultado de herramienta y conservar una respuesta que se apoya en él puede dejar una conclusión sin evidencia. El producto debería advertirlo y permitir revisar el conjunto relacionado antes de continuar.

Context Branches: comparar una decisión, no solo dos chats

El siguiente paso es agrupar estas selecciones en Context Branches: variantes explícitas del estado de una sesión, creadas desde un mismo punto de partida.

Una rama A conservaría el contexto de referencia. Una rama B podría excluir una hipótesis descartada, sustituir un resumen desactualizado o cargar una skill más específica. Ambas recibirían el mismo prompt para observar cómo cambia el resultado cuando cambia el contexto.

También podríamos mantener el contexto y variar el prompt. Si cambiamos ambas cosas a la vez, el experimento sigue siendo útil para explorar, pero ya no permite atribuir la diferencia a un único factor. La interfaz debería señalarlo.

Cada snapshot tendría que registrar el prompt, los bloques seleccionados y sus versiones, el modelo y su configuración disponible, los recursos accesibles y la política de ejecución. Cuando exista recuperación dinámica de información, habría que guardar además qué se recuperó en cada ejecución. Un árbol visual, por sí solo, no garantiza reproducibilidad.

Un ejemplo: una decisión antigua que ya no aplica

Imaginemos una sesión de refactorización. Al principio se descartó migrar una API; más tarde, el requisito cambió. El agente sigue proponiendo una solución basada en la decisión anterior.

Con el Context Manager, la persona podría localizar el intercambio antiguo, ver si está presente de forma literal o dentro de un resumen y crear una rama que lo sustituya por la nueva decisión. Desde el mismo commit del repositorio, repetiría la tarea con el mismo prompt y una configuración equivalente.

La revisión compararía el diff, los tests y la coherencia con el requisito vigente. Si la rama B funciona mejor, eso sería evidencia para ese escenario; harían falta más tareas y repeticiones para concluir que la estrategia general mejora el desarrollo agéntico.

Ese es el papel del human in the loop: intervenir en una decisión identificable, entender su efecto y revisar la evidencia antes de aceptar el resultado.

Encaje en Devin, Codex y Antigravity

Hay piezas de esta idea en el ecosistema actual, aunque sus interfaces y alcances difieren:

• Devin Desktop, antes Windsurf. Cognition presenta un entorno para gestionar agentes locales y cloud y compartir contexto mediante Spaces. La propuesta de este artículo añade una vista por bloques y snapshots para una acción de sesión. Presentación oficial de Devin Desktop.
• Codex de OpenAI. Los prompts, las instrucciones de AGENTS.md y las skills influyen en cómo trabaja el agente. OpenAI recomienda revisar instrucciones acumuladas y evitar contexto innecesario. El Context Manager haría más visible esa composición en el momento de actuar. Guía de OpenAI sobre skills y prompts.
• Google Antigravity. Su documentación distingue reglas persistentes y skills, y describe reglas con distintos ámbitos y modos de activación. Una vista de procedencia y prioridad ayudaría a inspeccionar qué reglas se aplican a una acción concreta. Documentación oficial de reglas.

Estas referencias sitúan la propuesta; no implican que los tres productos implementen el mismo sistema ni que carezcan de otras herramientas de gestión del contexto.

Cómo evaluar si mejora la experiencia

La hipótesis es que inspeccionar y ramificar el contexto reduce el esfuerzo de diagnosticar errores de contexto y permite intervenciones humanas más precisas. Todavía no hay resultados medidos para este prototipo.

Una evaluación compararía tareas equivalentes con el flujo habitual y con el inspector. Mantendría el mismo punto de partida del repositorio, modelo y herramientas; registraría las variaciones que no puedan fijarse y repetiría las ejecuciones para contemplar la variabilidad del agente.

Mediría el tiempo hasta localizar y corregir la causa, la tasa de tareas resueltas con tests y revisión humana, las regresiones, el coste y la latencia. También observaría errores introducidos al excluir información útil y si la persona entiende qué seleccionó. Menos tokens o una respuesta más corta no equivalen automáticamente a un mejor resultado.

Las ramas deberían ejecutarse en entornos aislados para evitar que una altere el repositorio o los servicios que utiliza la otra. Los resultados aparecerían junto al snapshot que los produjo, con sus pruebas y límites, sin convertir una valoración del propio modelo en la única medida de calidad.

Primer alcance: hacer visible lo que podemos controlar

Una primera versión podría empezar por bloques del proyecto y mensajes seleccionables, una capa protegida de instrucciones y permisos, snapshots de solo lectura y una comparación entre dos ramas. Más adelante se podrían incorporar trazas de recuperación, estimaciones de tokens y ejecuciones de evaluación.

El reto de producto es que esta precisión no convierta cada interacción en un formulario. El círculo seguiría siendo discreto; la complejidad aparecería cuando necesitamos investigar, corregir o experimentar.

Construir mejores productos agénticos también exige mejores herramientas para entender cómo los estamos guiando. Un Context Manager acercaría ese trabajo al lugar donde ya decidimos qué pedirle al agente.

Explorar el prototipo interactivo ↓