Por qué los equipos de agentes de Claude Code no comparten contexto — y cómo solucionarlo (2026)

Primero, el marco honesto: esto es experimental y está desactivado por defecto

Antes que nada, los equipos de agentes están desactivados a menos que los actives. La documentación incluye una advertencia: son "experimentales y están desactivados por defecto", y se habilitan configurando CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 en tu configuración o entorno, y "sin esa variable, no se configura ningún equipo al inicio de la sesión, no se escriben directorios de equipo y Claude no genera ni propone compañeros de equipo".

Así que nada de esto es una promesa rota. Es una característica joven con limitaciones documentadas, y el límite de contexto es una decisión de diseño más que un descuido.

La coordinación se comparte; la conversación no

Mira de qué está hecho un equipo, según la sección de arquitectura: un líder de equipo, compañeros de equipo, una lista de tareas compartida y un buzón de correo. El buzón es un archivo JSON en ~/.claude/teams/{team-name}/inboxes/{agent-name}.json. La lista de tareas vive en ~/.claude/tasks/{team-name}/.

Esas dos cosas —tareas y mensajes— son todo el sustrato compartido. Los compañeros de equipo pueden ver el estado de las tareas, reclamar el trabajo disponible y enviarse mensajes entre sí por su nombre. Lo que no pueden ver es el razonamiento de los demás, ni el tuyo.

Compáralo con los subagentes, como lo hace la documentación directamente: los subagentes tienen su propia ventana de contexto y reportan los resultados al llamador; los compañeros de equipo tienen su propia ventana de contexto y son "totalmente independientes", enviándose mensajes entre sí en lugar de reportar hacia arriba. Ambos modelos aíslan el contexto. Los equipos simplemente añaden un canal.

El prompt de generación es todo el briefing

Esta es la consecuencia práctica, y vale la pena enunciarla como una regla: lo que quieras que sepa un compañero de equipo tiene que estar en el prompt de generación (spawn prompt), en un archivo que cargue o en un mensaje que alguien le envíe más tarde.

La propia buena práctica de la documentación lo dice: los compañeros de equipo cargan el contexto del proyecto automáticamente "pero no heredan el historial de conversación del líder", por lo que debes "incluir detalles específicos de la tarea en el prompt de generación". Su ejemplo de prompt de generación tiene varias frases de longitud y especifica el módulo, las áreas de enfoque, el enfoque de almacenamiento de tokens y el formato de salida.

Ten en cuenta quién escribe ese briefing en la práctica: el líder, a partir de su propia comprensión comprimida de tu conversación. El conocimiento inicial de cada compañero de equipo es un resumen escrito por otro modelo, de una discusión que tuviste, filtrado a través de lo que el líder consideró relevante.

Los compañeros de equipo obtienen contexto de proyecto, no tu contexto

La división importa. Los compañeros de equipo leen CLAUDE.md desde su directorio de trabajo —los documentos confirman que "CLAUDE.md funciona normalmente"— además de los servidores MCP y las habilidades (skills) de tu proyecto y configuración de usuario.

Así que el conocimiento confirmado en forma de archivo se propaga. Todo lo demás no. La restricción que mencionaste en el chat, la corrección que le diste al líder hace una hora, la decisión que tomaste en la reunión antes de abrir la terminal: nada de eso está en un archivo, por lo que nada de eso llega al equipo.

Hay un problema relacionado si usas definiciones de subagentes como tipos de compañeros de equipo: los documentos señalan que los campos de frontmatter skills y mcpServers de una definición "no se aplican cuando esa definición se ejecuta como compañero de equipo", porque los compañeros de equipo cargan habilidades y servidores MCP desde la configuración del proyecto y del usuario como una sesión normal.

Lo que aprende un compañero de equipo muere con el equipo

Los equipos tienen alcance de sesión. El nombre del equipo se deriva de la sesión —session- más los primeros ocho caracteres del ID de la sesión— y "el directorio de configuración del equipo se elimina cuando finaliza la sesión". El directorio de la lista de tareas persiste localmente y nunca se sube, con una retención gobernada por el mismo cleanupPeriodDays que usas para las transcripciones.

So las tareas sobreviven y el equipo no. Nada se acumula: el compañero de equipo revisor que aprendió tu convención de manejo de errores esta mañana ya no está esta tarde, y el revisor de mañana comienza desde el mismo prompt de generación. Tampoco hay reanudación de sesión para los compañeros de equipo en proceso —/resume y /rewind no los restauran, y el líder "puede intentar enviar mensajes a compañeros de equipo que ya no existen".

Los mensajes son texto y deliberadamente de baja confianza

Podrías pensar que el buzón de correo puede transportar el conocimiento. Puede transportar frases, y está diseñado para desconfiar de ellas.

Cuando un agente envía un mensaje a otro, "Claude Code le dice al agente receptor que el mensaje provino de otra sesión de Claude, no de ti". Un compañero de equipo "no puede aprobar una solicitud de permiso ni otorgar consentimiento en tu nombre", y un compañero de equipo al que se le niega una acción "no puede transmitirla a otro compañero de equipo para eludir la verificación". En modo automático, un clasificador trata una solicitud de aprobación transmitida como entrada no confiable y revisa cada mensaje antes de la entrega, bloqueando algunos por completo.

Ese es un diseño de seguridad correcto, y significa que el buzón es un canal de coordinación, no un bus de conocimiento. También vale la pena conocer la forma práctica: para llegar a todos, envías un mensaje por destinatario.

Y restablecerlo cuesta dinero real

Los documentos dicen claramente que los equipos de agentes "usan significativamente más tokens que una sola sesión", escalando con el número de compañeros de equipo activos, y recomiendan de 3 a 5 para la mayoría de los flujos de trabajo. Parte de lo que compran esos tokens es que cada compañero de equipo lea de forma independiente los mismos archivos para reconstruir la misma comprensión, lo cual es la versión costosa de un problema que un almacén compartido resuelve de una sola vez.

Escribir prompts de generación enormes. La respuesta documentada, y funciona hasta cierto punto. Luego estás redactando a mano un briefing por compañero de equipo por sesión, y el briefing es una compresión de tu conversación, por lo que la razón detrás de una restricción se descarta exactamente cuando un compañero de equipo la necesitaría para tomar una decisión.

Poner todo en `CLAUDE.md`. Instinto correcto, ya que los compañeros de equipo sí lo leen. El límite es el tamaño: la guía es mantener los archivos de instrucciones cortos, porque los largos consumen contexto y se siguen con menos consistencia. Un CLAUDE.md que contiene todo lo que necesitan cuatro compañeros de equipo es uno que nadie sigue.

Hacer que el líder transmita los hallazgos. Funciona, y convierte al líder en un cuello de botella que gasta tokens reescribiendo lo que aprendió un compañero de equipo para que otro pueda leerlo. También tiene pérdidas de información de la misma manera que el prompt de generación.

Leer tú mismo la transcripción de cada compañero de equipo. Puedes hacerlo: selecciona un compañero de equipo en el panel y presiona Enter para verlo y enviarle mensajes directamente. Útil para guiar, inútil como mecanismo: te conviertes en la capa de integración.

Usar subagentes en su lugar. A veces es lo correcto. Los subagentes cuestan menos y reportan de vuelta, y los documentos los recomiendan cuando los trabajadores no necesitan hablar entre sí. Tampoco resuelve el intercambio de conocimientos — los subagentes tienen el mismo aislamiento, menos el buzón de correo.

Mantener un archivo borrador (scratch file) en el repositorio. La solución alternativa más efectiva, y es una versión artesanal de la respuesta correcta: un lugar fuera del contexto de cualquier agente que todos ellos leen y escriben. Vale la pena señalar que esto es en lo que la gente converge de forma independiente.

Mantén el aislamiento. Las ventanas de contexto independientes son la razón por la que un equipo de cinco agentes puede trabajar en paralelo sin ahogarse mutuamente en salidas, y las reglas de mensajería de baja confianza te están protegiendo.

Lo que necesita solución es que "contexto aislado" actualmente significa "conocimiento aislado". Esos conceptos son separables. Dale al equipo un almacén fuera de cada ventana de contexto: el líder escribe las restricciones y decisiones en él, los compañeros de equipo lo leen al inicio de su trabajo y escriben de vuelta lo que descubren, y el próximo equipo al día siguiente comienza a partir de lo que aprendió el anterior en lugar de un prompt de generación nuevo.

MemoryLake es una capa de memoria para eso: decisiones, restricciones y documentos de origen en un solo almacén, accesible a través de MCP desde cada compañero de equipo, desde Codex y desde ChatGPT a través de la API. La lista de tareas coordina el trabajo; el almacén transporta el conocimiento.

Paso 1: Crea una clave API

Genera una clave y realiza tu primera solicitud en unos 30 segundos. Manténla en tu entorno o en un gestor de secretos en lugar de pegarla en una sesión.

Paso 2: Sube tus primeras memorias

Sube los documentos, imágenes y archivos que tus compañeros de equipo siguen redescubriendo: las decisiones de arquitectura con sus razones, los informes de incidentes, los contratos de API, las convenciones, la lista de enfoques que ya has descartado. Sube las fuentes en lugar de un resumen; el prompt de generación ya es un resumen, y esa es la capa que pierde las razones.

Paso 3: Conecta tu IA y agentes

Dale a Claude, Codex, OpenClaw y otros agentes de IA acceso a la memoria a través de MCP o la API. Los compañeros de equipo cargan los servidores MCP desde la configuración de tu proyecto y de usuario, igual que en una sesión normal, por lo que configurar el servidor una vez le da a cada compañero de equipo el mismo almacén: sin configuración por compañero de equipo y sin depender de que el líder se acuerde de transmitir la información.

La primera diferencia es que el prompt de generación se vuelve más corto y mejor. En lugar de comprimir toda tu conversación en un briefing, dice de qué es dueño este compañero de equipo y apunta al almacén para el resto. Menos pérdida de información, menos escritura e idéntico para cada compañero de equipo.

La segunda es que un descubrimiento sobrevive al equipo. Cuando el compañero de equipo de depuración aprende que el endpoint de reintento no es idempotente, eso va al almacén, y el equipo de mañana lo hereda. En este momento, ese hallazgo vive en una ventana de contexto que se destruye con la sesión.

La tercera es que el trabajo en paralelo deja de volver a derivar el mismo contexto cinco veces. Que cada compañero de equipo lea una restricción recuperada es drásticamente más barato que que cada compañero de equipo lea la base de código para inferirla, lo cual importa dada la propia advertencia de los documentos de que los equipos usan significativamente más tokens, y vuelve a importar para un agente que vuelve a leer tu base de código en cada sesión.

And se integra con lo que Claude Code ya hace. CLAUDE.md sigue llevando las reglas permanentes, la memoria automática (auto memory) conserva sus notas locales y la lista de tareas sigue coordinando. Ninguno de ellos tiene que convertirse en el sistema de registro, algo que de todos modos no pueden ser, ya que la memoria automática no sale de la máquina que la escribió.

Escribe las restricciones antes de generar a nadie

Si tú y el líder acaban de pasar cuarenta minutos llegando a una conclusión, esa conclusión debe existir en algún lugar que un compañero de equipo lea. Diez minutos de escritura antes de generar (spawn) te ahorran que tres compañeros de equipo reinventen de forma independiente un diseño rechazado.

Mantén el prompt de generación enfocado en la responsabilidad, no en la educación

Di de qué es responsable este compañero de equipo, cómo se ve el estado de "terminado" y dónde buscar contexto. Intentar enseñar todo el proyecto en un prompt es la razón por la que los briefings se convierten en 600 palabras que aún omiten lo que realmente importaba.

Dale a los compañeros de equipo nombres predecibles

El líder nombra a cada compañero de equipo al generarlo, y cualquier compañero de equipo puede enviar un mensaje a cualquier otro por ese nombre. Dile al líder cómo llamarlos en tu instrucción de generación para que puedas hacer referencia a ellos más tarde, y recuerda que llegar a todos significa un mensaje por destinatario.

No confíes en los mensajes para mover el conocimiento

El buzón de correo es texto, y los mensajes entrantes se tratan como si provinieran de otra sesión de Claude en lugar de provenir de ti, con las solicitudes de permisos explícitamente no confiables. Usa los mensajes para la coordinación —"Terminé con el módulo de autenticación"— y un almacén para los hechos.

Espera que el equipo no sobreviva a una reanudación (resume)

/resume y /rewind don't restore a los compañeros de equipo en proceso, y el líder puede intentar enviar mensajes a compañeros de equipo que ya no existen. Si eso sucede, dile que genere otros nuevos, y asegúrate de que los nuevos puedan leer lo que aprendieron los antiguos.

Comienza con 3 a 5 compañeros de equipo y en trabajo de solo lectura

La recomendación documentada, y coincide con el modo de fallo: la sobrecarga de coordinación y el costo de tokens escalan con el tamaño del equipo, y la implementación en paralelo invita a conflictos de archivos. La revisión, la investigación y la depuración de hipótesis en competencia es donde los equipos justifican su costo.

No confundas nada de esto con la aplicación de reglas (enforcement)

Los archivos de instrucciones y la memoria son contexto, no configuración obligatoria. Si algo debe cumplirse en la salida de cada compañero de equipo —formato, rutas protegidas, sin envíos directos a main— colócalo en un hook o CI, lo cual se aplica a todos ellos sin depender de lo que haya leído cualquiera de ellos.

Los equipos de agentes de Claude Code no comparten contexto porque los compañeros de equipo son independientes por diseño: cada uno tiene su propia ventana de contexto, cada uno carga el contexto del proyecto —CLAUDE.md, servidores MCP, habilidades (skills)— y "el historial de conversación del líder no se transfiere". Lo que comparten es una lista de tareas y un buzón de correo, y el buzón trata deliberadamente los mensajes de agente a agente como no confiables para cualquier cosa que se parezca al consentimiento. El equipo en sí tiene alcance de sesión: el directorio de configuración se elimina cuando finaliza la sesión, los compañeros de equipo en proceso no sobreviven a una reanudación (resume) y nada se acumula de un equipo al siguiente.

Así que mantén el aislamiento y soluciona el intercambio. Escribe las restricciones y decisiones en un almacén que cada compañero de equipo pueda leer y escribir, mantén el prompt de generación enfocado en la responsabilidad en lugar de la educación, y deja que la lista de tareas se encargue de la coordinación. Así, cinco agentes trabajarán a partir de una única comprensión de tu proyecto en lugar de cinco compresiones de tu conversación.