Contexto en agentes background: qué heredan y qué no
Al lanzar un agente en background, ¿parte de un contexto limpio o hereda el de la ventana principal? La respuesta cambia según uses un orquestador real o el modo background de Claude Code.
El concepto de contexto en agentes
El context window es la memoria de trabajo del agente. Contiene toda la información que el modelo puede tener en cuenta en un momento dado: las instrucciones del sistema, la conversación hasta ese punto, los archivos que ha leído, los resultados de las herramientas que ha ejecutado. Todo lo que no está en el context window, no existe para el agente en ese momento.
Cuando se lanza un agente en modo background, la pregunta que surge es inmediata: ¿ese agente parte de un contexto limpio o hereda el de la sesión principal? La respuesta tiene implicaciones prácticas importantes en términos de eficiencia, predictibilidad y coste.
Regla de oro: el agente solo puede razonar sobre lo que está en su context window. Diseñar qué entra en ese contexto — y qué no — es una decisión de arquitectura con impacto directo en la calidad del output y el coste por tarea.
Modo background en Claude Code
Cuando se lanza un subagente en background desde Claude Code CLI con la flag --background, el comportamiento es el de un fork del contexto: el subagente hereda el contexto de la sesión principal en el momento del lanzamiento. No parte de cero — parte de una copia del estado del contexto en ese instante.
Esto significa que el subagente tiene acceso a todo lo que la sesión principal había acumulado hasta ese punto: las instrucciones del sistema (CLAUDE.md, reglas), los archivos leídos, las decisiones tomadas en la conversación. A partir del momento del lanzamiento, los dos contextos evolucionan de forma independiente — lo que pasa en uno no se refleja automáticamente en el otro.
El subagente hereda el contexto del momento del fork, pero no recibe actualizaciones posteriores de la sesión principal. Si la sesión principal modifica un archivo después del lanzamiento, el subagente no lo sabrá a menos que lo lea explícitamente.
Orquestador real vs. background ad-hoc
En un sistema multi-agente con un agente coordinador real, el modelo es diferente: cada subagente arranca con su propio contexto limpio más las instrucciones específicas que le pasa el orquestador. No hay herencia del contexto del orquestador — hay inyección controlada de información relevante.
La diferencia de eficiencia es significativa en sistemas con muchos subagentes: el background ad-hoc hace que cada agente arranque con el peso del contexto completo acumulado; el orquestador real hace que cada agente arranque con solo lo que necesita para su tarea concreta.
Implicaciones prácticas
Si dos agentes se lanzan en background desde la misma sesión, comparten el contexto del momento del fork pero luego evolucionan de forma independiente. Los conflictos surgen cuando ambos trabajan sobre los mismos recursos:
Cuándo usar cada modo
Background ad-hoc
Tareas independientes dentro de una sesión de trabajo activa
Ejemplo: Mientras terminas una implementación, lanzas un agente en background para que genere tests del módulo anterior
Orquestador real
Pipelines repetibles, sprints automáticos, sistemas productivos
Ejemplo: Un agente orquestador que lanza N subagentes por sprint con contexto limpio y controlado para cada uno
La regla práctica: para trabajo ad-hoc en una sesión, el background de Claude Code es suficiente y conveniente. Para pipelines productivos o sprints automáticos donde el control del contexto es crítico para la calidad y el coste, invertir en un orquestador real con contexto inyectado explícitamente es la decisión correcta.
¿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.