¿El contexto de un agente crece en cada vuelta del bucle? Los tres niveles que se suelen confundir
Bucle de thinking, contexto de la tarea y contexto persistente en ficheros son tres cosas distintas. Entenderlas por separado explica por qué cada ticket debería empezar con un contexto limpio.
El punto de confusión
Un modelo mental muy extendido: el agente trabaja en bucle; en cada llamada al modelo se le pasa el contexto, se ejecuta una tool, su resultado se añade al contexto y vuelta a empezar. De ahí sale una pregunta lógica: si el contexto se amplía solo en cada turno, ¿no acabará desbordándose después de unas cuantas tareas?
El modelo mental es correcto a bajo nivel, pero mezcla tres niveles de contexto distintos. Al separarlos, la respuesta queda clara: dentro de una tarea el contexto crece; entre tareas no debería crecer.
Los tres niveles de contexto
1. Bucle interno del modelo (thinking)
El modelo da varias vueltas de razonamiento y encadena el resultado de una con la siguiente.
Control: Bajo: en la práctica solo se elige el nivel de esfuerzo (low / medium / high / max) o se activa/desactiva el thinking.
2. Contexto de la tarea o ticket
Crece a lo largo de los pasos del flujo: exploración, propuesta, implementación y verificación.
Control: Alto: cada paso es un comando del framework y decide qué información se recupera.
3. Contexto persistente en ficheros
Reglas, docs, specs y el archivo de cambios que sobreviven entre tareas.
Control: Total: es el harness del equipo y solo cambia cuando la tarea lo justifica.
El primer nivel apenas se puede tocar, así que el esfuerzo del equipo debe ir al segundo y, sobre todo, al tercero: agentes, comandos, docs, scripts, skills, hooks y la carpeta de specs del producto. Es lo que está completamente bajo tu control.
Un ticket, cinco rondas
En un framework como OpenSpec, las "vueltas" que sí importan son los pasos del flujo. Cada uno es un comando, y el contexto de la tarea crece de forma controlada a lo largo de ellos:
- 1Explore: Observar: recuperar del repositorio, del ticket y del archivo de specs solo lo necesario.
- 2Propose: Razonar: generar los artefactos de diseño y la lista de tareas.
- 3Apply: Actuar: escribir el código siguiendo esas tareas.
- 4Verify: Aplicar los sensores (tests, compilación, review, contratos) sobre lo anterior, sin añadir contexto nuevo.
- 5Archive: Dejar el cambio archivado en un lugar conocido para poder recuperarlo en tareas futuras.
No se carga todo el histórico de specs en cada interacción, porque sería enorme. La exploración va a buscar solo el cambio archivado que la tarea necesita y lo incorpora al contexto.
Entre tareas: empezar siempre limpio
En un sistema agéntico, cada disparador (un ticket nuevo, una alerta, un evento) arranca un contexto nuevo. Ese contexto ya trae información por defecto, se va llenando durante la tarea y, al terminar, no se arrastra a la siguiente. Lo único que persiste son los ficheros que la tarea haya generado o actualizado: un doc nuevo, una spec, una regla descubierta. Esos ficheros sí formarán parte del arranque de la próxima tarea.
El objetivo de diseño es mantener un contexto base controlado, que no crezca por el mero hecho de que el sistema se haya ejecutado cinco o seis veces. Si creciera sin límite, llegaría un momento en que no quedaría espacio para trabajar. No es una regla absoluta, pero sí la base de un sistema agéntico sostenible y mantenible.
Resumen rápido
- Hay tres niveles de contexto: el bucle de thinking del modelo, el contexto de la tarea y el contexto persistente en ficheros.
- Dentro de un ticket el contexto crece a lo largo de explore, propose, apply y verify; entre tickets, cada tarea empieza limpia.
- Solo persisten los ficheros: invierte el esfuerzo en ese harness, que es lo que realmente controlas.
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.