UI multiagente: una conversación, hilos con nombre, trabajo visible

La conversación principal debe ser el gestor

En una pantalla multiagente, lo primero que escanea un usuario no es el número de agentes, sino el lugar donde entró la solicitud y donde volverá la respuesta. No quiere un enjambre; quiere un compañero de equipo responsable. Haz que la conversación principal sea el gestor, cada hilo una unidad de trabajo direccionable y el trabajo oculto sea visible.

Anthropic lanzó una versión beta rediseñada de Claude Code Projects el 17 de septiembre de 2026, con un coordinador que dirige hilos de agentes en paralelo. El patrón es útil incluso fuera de la programación: convierte el trabajo paralelo en una superficie que una persona puede inspeccionar.

En ese rediseño, un usuario puede ejecutar múltiples agentes dentro de un proyecto, con memoria común, objetivos y archivos o artefactos almacenados. El proyecto debe contener las decisiones que los hilos posteriores necesitarán, no solo un registro de chat de lo que ocurrió después de que comenzó el trabajo.

Los hilos necesitan nombres, límites y una transición visible

Un hilo necesita un límite visible. En Claude Code Projects, cada hilo se ejecuta como su propia sesión en la nube, con una rama y una copia del repositorio separadas. Un usuario que puede ver qué posee un hilo puede juzgar si la división es razonable.

Los nombres hacen posible la dirección. En la misma configuración, los hilos tienen nombres, lo que permite a un usuario redirigir un hilo en ejecución antes de que termine. Un hilo con nombre invita a la corrección; un proceso sin nombre invita a la ansiedad.

El coordinador es la parte que hace que la división se sienta intencional. El coordinador de Claude Code Projects delimita una solicitud, asigna trabajo, gestiona hilos en paralelo, revisa las salidas y ensambla el resultado final. Si tu producto no puede mostrar esa cadena, el usuario tiene que inventarla.

La memoria compartida, los conflictos y el coste son señales de confianza

En el rediseño del 17 de septiembre de 2026, todos los hilos comparten un pool de memoria que puede retener decisiones del proyecto, con ejemplos como un lanzamiento que se traslada al viernes, una exportación descartada o la persona a consultar antes de cambiar la facturación. Esas decisiones son el tipo de contexto que un usuario espera que un gestor recuerde.

Cuando dos hilos de Claude Code Projects modifican el mismo código, la superposición se trata como un conflicto de fusión similar a otra pull request. Un conflicto visible permite a los usuarios distinguir un evento normal de ingeniería de una sobrescritura silenciosa.

En la beta, los usuarios pueden consultar el uso específico del proyecto y elegir niveles de modelo y esfuerzo para el chat del coordinador y los hilos de trabajo, aunque ejecutar varias sesiones completas puede alcanzar los límites de uso más rápido. Un coste y un esfuerzo invisibles hacen que los usuarios asuman lo peor y dejen de delegar.

Los hilos de Claude Code Projects actualmente se ejecutan en la nube, y el soporte para ejecutarlos en la máquina del usuario con herramientas y código locales llegará muy pronto. Para muchos equipos, esa distinción cambia la revisión de seguridad, el manejo de datos y la planificación presupuestaria antes de que se lance el primer hilo.

Una superficie multiagente responsable pasa una auditoría de un minuto

Usa esta lista como una auditoría de un minuto. Cada elemento debe ser verificable en tu interfaz actual sin que un ingeniero explique el backend.

• Una conversación principal posee la solicitud y la respuesta final. El usuario ve un solo lugar donde el gestor recibe la petición y devuelve el resultado.
• Cada hilo tiene un nombre y un alcance visible. El usuario puede saber qué está haciendo y redirigirlo antes de que termine.
• El coordinador muestra delimitación, delegación, revisión y ensamblaje. La transición de la solicitud a la salida debe ser inspeccionable, no implícita.
• La memoria compartida lleva decisiones, no solo historial de chat. El contexto almacenado incluye decisiones, trabajo descartado y personas a consultar.
• Las ediciones concurrentes aparecen como conflictos de fusión, no como sobrescrituras silenciosas. La superposición se manifiesta como un evento normal de revisión.
• La selección de modelo y esfuerzo es visible por capa. El coordinador y cada hilo de trabajo exponen el modelo y el esfuerzo utilizados.
• El uso del proyecto es visible antes de alcanzar los límites. El usuario ve el consumo del proyecto, no solo un mensaje de fallo.
• La ejecución en la nube/local y los límites de coste son explícitos. La superficie indica dónde se ejecuta el trabajo y cuánto puede gastar el usuario.