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 explorar 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 muestra el punto de entrada propuesto en Devin Desktop, antes Windsurf. El círculo resaltado en rojo abriría el Context Manager; 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 situado debajo de la captura 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. Junto a cada bloque editable habría una acción Editar para revisar su contenido, guardarlo o cancelar los cambios sin alterar el checklist.

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. Cada skill explicaría cuándo se utiliza, qué instrucciones aporta y qué recursos necesita; cada herramienta mostraría su función, entradas y contexto asociado. La demo utiliza Skill A y Skill B para representar cualquier workflow. Conviene distinguir tres cosas: que una herramienta esté disponible, que sus instrucciones estén cargadas y que sus resultados anteriores formen parte del contexto. Las ediciones se aplicarían a la variante de contexto de la rama, sin modificar automáticamente los archivos originales de la skill ni los permisos del servicio.

3. Memoria de sesión y conversación completa. El historial ordenado de prompts del usuario y respuestas visibles del asistente, con su autor, procedencia y estado de inclusión. Se podría editar un mensaje individual o abrir Editar conversación completa para revisar todos los turnos juntos. Los mensajes excluidos seguirían visibles en el historial, marcados como tales: excluir un mensaje de la siguiente acción no lo borra. Las ediciones crearían una versión alternativa dentro de la rama y conservarían los mensajes originales para consulta. También tendrían que representarse los resúmenes, archivos referenciados y resultados que el sistema conserve; si hubo compactación, el inspector distinguiría el historial visible del resumen que realmente se enviará. La vista se refiere a mensajes visibles, no a razonamiento interno privado.

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 editadas, la conversación utilizada, 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.

Volver al prototipo interactivo ↑