Cómo dar a los External Agents de Zed el contexto que no heredan (2026)

Zed aloja el hilo; el agente es dueño de todo lo demás

La frase definitoria se encuentra en el primer párrafo de la documentación: "Zed aloja el hilo en el Agent Panel y en la Threads Sidebar, mientras que el External Agent normalmente es dueño de su propio entorno de ejecución, autenticación, selección de modelo, herramientas y configuración nativa."

Esa es una división arquitectónica limpia y explica casi todas las sorpresas. El panel es de Zed. El listado de conversaciones es de Zed. El agente es un proceso independiente que se comunica a través de ACP y trae consigo todo lo suyo.

La tabla de límites responde a la mayoría de las preguntas con "depende"

Zed publica una tabla de límites de configuración (Configuration Boundaries). Léela tal como está escrita, con todas sus ambigüedades incluidas:

Dos filas son firmes y negativas: los perfiles de Zed Agent no se aplican, y las Zed Skills no se aplican como Zed Skills. Todo lo demás es "normalmente", "puede" o "depende del agente".

Eso no es vaguedad por el simple hecho de serlo. Zed no puede prometer lo que un proceso de terceros hace con un archivo de configuración, por lo que prefiere no hacerlo. Pero esto significa que la respuesta a "¿se leerán mis instrucciones?" es genuinamente desconocida desde el lado de Zed, y tienes que determinarla para cada agente.

Incluso el único archivo por el que apostarías es ambiguo

La sección de Claude Agent dice: "Los archivos específicos de Claude, como CLAUDE.md, pueden ser leídos directamente por Claude Agent".

Pueden ser. No "son". La razón es la misma de tipo arquitectónico: el agente lee su propia configuración a través de su propio entorno de ejecución, por lo que el hecho de que se detecte tu archivo depende de cómo se inició ese agente y de lo que considere su directorio de trabajo. Este es el mismo tipo de problema que explica por qué los agentes ignoran tus archivos de instrucciones en general.

Las credenciales y los proyectos remotos añaden otra capa

"Las claves API del proveedor de LLM de Zed guardadas en el llavero local no son automáticamente las mismas que las credenciales de un External Agent". Y para el trabajo remoto: "Los External Agents pueden leer las credenciales de forma local, remota o a través de su propio flujo de inicio de sesión".

Por lo tanto, una clave API de Anthropic configurada para Zed Agent "no configura automáticamente Claude Agent", y una suscripción de Cursor "no configura los ajustes del proveedor de LLM de Zed". Cada agente se autentica a sí mismo.

Asumir que las Zed Skills se transfieren. No lo hacen; la tabla lo dice claramente. Las habilidades escritas para Zed Agent no están disponibles como Zed Skills en un hilo de agente externo, y el hecho de que el agente tenga un equivalente propio "depende del agente".

Configurar un perfil de Zed Agent y esperar que limite al agente externo. Los perfiles "no se aplican a menos que la integración indique lo contrario". Vale la pena verificar especialmente los permisos de las herramientas aquí, ya que los permisos de las herramientas nativas dependen del agente y no de tu configuración de Zed.

Configurar MCP una vez en Zed y darlo por terminado. Los servidores MCP de Zed "pueden ser reenviados a través de ACP" y la configuración MCP nativa "también puede ser leída por el agente". Dos "quizás", lo que significa que la respuesta práctica es probar en lugar de asumir; una variación de que la capa MCP es sin estado por diseño.

Importar hilos antiguos y esperar una transferencia en vivo. Zed puede importar hilos existentes de agentes externos configurados, y esta es una característica real: "Zed se conecta a cada agente seleccionado a través de ACP y añade sesiones que aún no están en tu historial". Pero ten en cuenta lo que obtienes: "Los hilos importados son entradas archivadas; abre una para restaurarla y continuar donde lo dejaste", y ten en cuenta lo que se omite: "Se omiten las sesiones sin un directorio de trabajo asociado".

Concluir que los External Agents de Zed no tienen ningún contexto. Comprensible si solo lees las filas negativas, pero erróneo. Cada agente externo aporta su propio sistema de instrucciones, su propia memoria si la tiene y su propia configuración nativa; el punto es que estos pertenecen al agente, no a Zed. El contexto existe; simplemente no proviene del editor.

Resolverlo estandarizando en un solo agente. Esto funciona, pero renuncia a la razón por la que instalaste External Agents en primer lugar. La función existe para que puedas iniciar un hilo de Claude Agent para una tarea y un hilo de Codex para otra; reducirse a un solo agente para evitar mantener dos capas de instrucciones es pagar por la flexibilidad y luego no usarla.

Copiar el mismo archivo de instrucciones en la ubicación de cada agente. La solución obvia, y funciona durante aproximadamente un mes. Luego, una copia recibe una corrección que las demás no, y terminas con dos agentes en el mismo editor discrepando con total seguridad sobre tus convenciones, sin ningún error en ninguna parte, porque cada uno está leyendo fielmente el archivo que se le dio.

Paso 1: Prueba el límite en lugar de deducirlo

Para cada agente externo que utilices, realiza una prueba deliberada en lugar de confiar en las ambigüedades de la tabla en cualquier dirección.

Coloca una instrucción distintiva e inofensiva en el archivo que crees que lee el agente: una preferencia de formato específica, un nombre de variable sin sentido que deba preferir, cualquier cosa que vayas a notar. Inicia un hilo de agente externo desde el Agent Panel y haz una pregunta cuya respuesta revele si la instrucción se aplicó.

Haz esto para cada capa por separado: el propio archivo de instrucciones del agente, la configuración MCP nativa y cualquier habilidad que el agente admita de forma nativa. Terminarás con una pequeña tabla por agente de lo que realmente funciona en tu configuración, que es algo que la documentación de Zed no puede escribir por ti porque depende de cómo se instaló e inició el agente.

Mientras estás allí, verifica el directorio de trabajo. La importación de hilos de Zed omite las "Sesiones sin un directorio de trabajo asociado", lo cual es un fuerte indicio de que el directorio de trabajo es fundamental en esta integración, y la detección de archivos de instrucciones suele ser relativa a él.

Paso 2: Configura la propia capa de cada agente de forma nativa

Una vez que sepas qué lee un agente, configúralo allí en lugar de en Zed.

Para Claude Agent, eso significa su propia autenticación (ejecuta /login en un hilo de Claude Agent) y configuración nativa de Claude. Para Codex, significa "inicio de sesión de ChatGPT, claves API de Codex, claves API de OpenAI o configuración nativa de Codex según la versión instalada y el entorno". Para Gemini CLI, su propio inicio de sesión de Google o Vertex AI. Para OpenCode, su propia autenticación, selección de modelo y comportamiento de suscripción. Para Poolside, pool login. Zed documenta cada uno de estos como propiedad del agente, y la forma más rápida de luchar contra la arquitectura es intentar centralizarlo en el editor.

Si estás desarrollando un agente ACP o ejecutando uno que no está en el registro, la ruta de Custom Agents añade una entrada agent_servers en tu archivo de configuración, y se le aplican las mismas reglas de límites.

Paso 3: Coloca el conocimiento que ambos agentes necesitan fuera de ambos agentes

Los pasos 1 y 2 hacen que cada agente funcione. Te dejan manteniendo N capas de instrucciones paralelas, una por agente, todas describiendo el mismo proyecto.

Ese es el costo real de un editor multiagente, y no es un error en Zed: es la consecuencia honesta de que "el External Agent es dueño de su propia configuración nativa". Lo único que reduce N copias a una sola es un almacén que ninguno de los agentes posee.

Una capa de memoria hace precisamente eso. No es una configuración de Zed ni una configuración de agente, por lo que no le importa qué fila de la tabla de límites se aplique. MemoryLake se configura en tres pasos.

Paso 1: Crea una clave API

Inicia sesión y genera una clave API desde tu panel de control. Debido a que la credencial es tuya y no de un agente, esquiva la fragmentación de autenticación que documenta Zed: las claves del llavero de Zed, la autenticación de Claude Agent y la autenticación de Codex son todas independientes, y esta es independiente de todas ellas.

Paso 2: Sube tus primeras memorias

Coloca el conocimiento del proyecto que has estado duplicando: convenciones, decisiones arquitectónicas y sus razones, términos de dominio, las preferencias permanentes que repites en cada nuevo hilo. Cualquier cosa que hayas escrito en los archivos de instrucciones de dos agentes diferentes es un candidato.

Mantén la configuración genuinamente específica de cada agente donde corresponde. Esto es para los hechos, no para las conexiones.

Paso 3: Conecta tu IA y tus agentes

Apunta cada agente al almacén. Cambiar de un hilo de Claude Agent a un hilo de Codex a mitad de la tarea deja de significar una nueva explicación del proyecto, que es lo que el Agent Panel facilita y el límite encarece.

El primer cambio es que cambiar de agente se vuelve económico. Toda la propuesta de Zed es que puedes elegir el agente adecuado por hilo; eso solo vale la pena si cambiar de hilo no significa volver a establecer el contexto. Hoy en día, normalmente lo significa.

El segundo es que la tabla de límites deja de ser una fuente de sorpresas. Cuando el conocimiento duradero vive fuera, las filas ambiguas importan mucho menos: te siguen importando la autenticación y los permisos de las herramientas, pero dejas de preocuparte por si se detecta un archivo de instrucciones en particular, porque los hechos no están en él.

El tercero es que la importación de hilos se vuelve realmente útil. Los hilos importados llegan como entradas archivadas que abres para continuar; cuando el conocimiento del proyecto está en una capa compartida, continuar un hilo antiguo no depende de cuánto del contexto original estuviera en la transcripción. Es la misma razón por la que una capa compartida ayuda con la memoria entre agentes en general.

• Trata la tabla de límites como una lista de verificación, no como una especificación. Dos filas son negativas firmes; el resto son hechos por agente que estableces mediante pruebas.
• Configura la autenticación por agente y no esperes que se comparta. Una clave del llavero de Zed no configura Claude Agent; una suscripción de Cursor no configura los ajustes del proveedor de Zed.
• No portes las Zed Skills. No se aplican como Zed Skills en hilos externos. En su lugar, comprueba si el agente tiene un equivalente nativo.
• Verifica el reenvío de MCP en lugar de asumirlo. Los servidores MCP de Zed pueden ser reenviados a través de ACP y la configuración nativa también puede ser leída: dos "quizás" merecen una prueba.
• Ten en cuenta el directorio de trabajo. Las sesiones sin uno se omiten al importar, y la detección de instrucciones generalmente depende de él.
• Espera que los hilos importados sean archivos. Abre uno para restaurarlo; volver a importar es seguro porque se omiten los hilos que ya están en tu historial.
• Mantén una única fuente canónica de conocimiento del proyecto. Si un párrafo existe tanto en CLAUDE.md como en un archivo de instrucciones de Codex, no pertenece a ninguno de los dos.
• Vuelve a realizar pruebas después de las actualizaciones. Las opciones de autenticación de Codex varían "según la versión instalada y el entorno", lo cual es una fuerte señal de que estos límites cambian.

La documentación de los External Agents de Zed es inusualmente confiable precisamente porque se niega a prometer de más. "Normalmente", "puede" y "depende del agente" son las respuestas correctas cuando un proceso independiente posee su propia configuración, y pretender lo contrario solo pospondría la sorpresa.

La lectura práctica es: deja que cada agente sea dueño de sus conexiones, deja de intentar centralizar eso en el editor y saca por completo de los agentes lo único que realmente debería compartirse: lo que tu equipo sabe sobre el proyecto.