Tus agentes no pueden hablar sin nombres
Tienes tres terminales abiertas, todas trabajando en el mismo repositorio. Una acaba de cambiar un esquema contra el que otra está construyendo. Nada se lo dice. Te enteras cuando algo se rompe, y resulta que la capa de coordinación entre tus agentes eres tú, copiando hallazgos entre ventanas a mano.
Las sesiones pueden mandarse mensajes
La mensajería entre sesiones permite que una entregue un mensaje a otra. Los casos previstos son justo los que te hacen perder tiempo: pasar un hallazgo cuando una sesión descubre un cambio que rompe algo, coordinar worktrees en paralelo para que cada una sepa qué aterrizó, y recibir el estado de una migración larga en vez de quedarte mirándola.
Lo que viaja es un texto que un agente le escribe a otro, nunca el historial de la conversación ni archivos. Es un límite deliberado. Si quieres que otra sesión tenga todo tu contexto, se retoma la sesión, no se le manda un mensaje.
Nada de esto lo invocas tú. El agente descubre los destinos y envía por su cuenta, y puede decidir enviar sin que se lo pidas, por ejemplo justo después de hacer un cambio que afecta trabajo en otra parte.
Pero solo una sesión con nombre es alcanzable
Acá está lo que detiene a la gente. Una sesión responde al nombre que pones con el comando /rename o con la bandera --name. Sin uno, el nombre lo pone la herramienta, y dependes de una etiqueta generada que no conoces.
Así que nombrar es el prerrequisito barato que todos se saltan. Ponle nombre al lanzarla, o renómbrala en marcha, y un panel anónimo se vuelve un destino al que puedes entregar trabajo:
# al lanzarla
claude --name worker
# o a mitad de sesión
/rename worker
Después /list-agents, también disponible como /peers, muestra qué es realmente alcanzable. La primera línea es el nombre de esta sesión, que es el que usan las demás para llegarle. Las filas de abajo son subagentes, integrantes de equipo, tus otras sesiones locales y tus sesiones en la nube o remotas.
Un detalle útil: si dos sesiones vivas terminan compartiendo nombre, el agente agrega un identificador corto para distinguirlas, y el listado muestra el directorio de trabajo de cada sesión local para que puedas separarlas.
Por dónde viajan realmente los mensajes
Esto importa si te interesa qué sale de tu máquina:
- Misma máquina: por un socket por sesión (una tubería nombrada en Windows), nunca por los servidores de Anthropic.
- Otra de tus máquinas: por los servidores de Anthropic, llegando por la conexión de Remote Control de esa máquina.
- Una sesión en la nube: por los servidores de Anthropic, directo a la sesión en la nube.
La primera fila es el caso común y es completamente local. Las otras dos explican por qué el alcance entre máquinas tiene un prerrequisito: una sesión en otra máquina aparece solo si corre con Remote Control y esta sesión también está conectada. Si la tuya no lo está, el mensaje llega pero sin dirección de respuesta, así que el otro lado no puede contestar.
Las fallas, por probabilidad
- Sin nombre: no hay a quién dirigirse. Empieza por acá.
- Versiones desfasadas: la mensajería requiere una versión reciente; una sesión vieja de larga vida simplemente no es alcanzable. Reinicia las que quieras coordinar.
- Sistemas de archivos distintos: las sesiones se registran en archivos en disco, así que dos sesiones solo se alcanzan si ven los mismos archivos. Un contenedor y su anfitrión no. Tampoco WSL 2 y Windows nativo en la misma computadora.
- Controles de entrada: la sesión receptora puede estar configurada para retener o rechazar. Ver el artículo sobre por qué el mensaje de un par nunca es tu aprobación.
Para llevar
Una sesión sin nombre es un cuarto sin puerta. Nombra las que quieras coordinar, corre /list-agents para confirmar que se ven entre sí, y deja que las entregas pasen entre agentes en vez de por tu portapapeles.
¿Construyendo con IA? Yeda AI diseña, audita y lanza sistemas LLM en producción.