En enero de 2026 verificamos que Claude Code incorporó Tasks con dependencias, listas compartidas y persistencia local, un cambio que nos modifica la forma de organizar trabajos de largo aliento con agentes de código.

La última actualización de Claude Code incorporó un sistema nativo de tareas con dependencias y persistencia local que altera el modo en que organizamos trabajos de largo aliento con agentes de código. Verificamos que el cambio llegó en enero de 2026 y figura en el registro de versiones, donde se describe la “nueva gestión de tareas” con seguimiento de dependencias y mejoras relacionadas. A partir de ahora, el estado de cada tarea puede sobrevivir a nuevas sesiones, coordinarse entre sub‑agentes y compartirse entre dos o más instancias que trabajan en el mismo proyecto.

Con este paso, pasamos de las listas de “todos” efímeras a un modelo de Tasks persistentes, almacenadas por defecto en la carpeta del usuario, lo que evita la “amnesia” inter‑sesión que obligaba a reconstruir el contexto cada vez que el buffer se llenaba o el hilo de trabajo se interrumpía. Además, el sistema admite relaciones “bloquea” y “bloqueado por”, lo que facilita descomponer un objetivo en olas de ejecución paralela y secuencias obligatorias.

Solemos compararlo con Beads, un proyecto de memoria estructurada para agentes creado por Steve Yegge, que popularizó los elementos persistentes, el historial auditable y el grafo de dependencias. La idea de “trabajo rastreable” gana terreno porque ordena la colaboración entre múltiples agentes y reduce pérdidas de estado. Revisamos su repositorio para contrastar características como tareas “listas” para ejecutar, bloqueos explícitos y almacenamiento de progreso.

En paralelo, exploramos la integración con proveedores de voz y audio en tiempo real que aparecen en los planes de integración de proyectos, como ElevenLabs para TTS en streaming, cuya API oficial documenta flujos de transmisión por chunks que podemos invocar desde clientes Node o Python. Esta pieza técnica resulta útil cuando coordinamos sub‑agentes que generan o validan audio mientras el orquestador avanza con otras tareas.

Antes y después del contexto persistente con “beads” y tareas rastreables

De listas efímeras a Tasks persistentes

Comprobamos que el salto a Tasks habilita tres cambios prácticos. Primero, el estado deja de vivir únicamente en memoria y se guarda en disco, de modo que cada elemento de trabajo puede reanudarse sin volver a “descubrir” el proyecto. Segundo, la dependencia entre tareas permite ordenar ejecuciones que antes chocaban por falta de secuenciación. Tercero, la colaboración mejora porque dos sesiones diferentes pueden suscribirse a una misma lista y recibir actualizaciones en tiempo real.

  • Persistencia local. El sistema guarda la lista de tareas en el perfil del usuario, lo que evita rehacer planes al reiniciar la sesión.
  • Dependencias declarativas. Cada tarea indica qué bloquea y por qué está bloqueada, lo que habilita olas paralelas y fases secuenciales.
  • Coordinación entre sesiones. Si dos sesiones comparten la misma lista, los cambios se propagan al instante, reduciendo estados obsoletos.
La persistencia en disco elimina la “amnesia” del agente, y las dependencias convierten las listas de pendientes en un plan de ingeniería ejecutable.

La inspiración de Beads es útil para entender el giro conceptual: pasamos de checklists volátiles a unidades de trabajo rastreables y versionables. El repositorio de steveyegge/beads describe una memoria estructurada pensada para agentes con grafo de tareas, auditoría y noción de “listo para ejecutar”. Ese patrón, aplicado a agentes de código, reduce re‑lecturas inútiles y acelera la reanudación de contextos.

Contexto persistente y “recorded discoveries” en memoria estructurada

Cómo funciona el nuevo sistema

El sistema introduce primitivas de herramienta que podemos solicitar en lenguaje natural y que el agente invoca de forma programática: TaskCreate, TaskGet, TaskUpdate y TaskList. Con ellas, un sub‑agente puede crear una tarea para otro, registrar un bug que encontramos durante la lectura de código o actualizar el estado después de un commit.

  • TaskCreate crea una nueva unidad de trabajo con título y descripción.
  • TaskGet recupera detalles de una tarea concreta para verificaciones o handoffs.
  • TaskUpdate cambia estado, añade “bloquea/bloqueado por” o borra tareas obsoletas.
  • TaskList enumera lo pendiente y lo completado, y sirve como fuente de verdad del plan.

Por defecto, obtenemos un identificador de lista por sesión. Si no hacemos nada, al limpiar o reiniciar obtendremos un conjunto nuevo. Para coordinar dos sesiones con la misma lista, establecemos un identificador común antes de lanzar el agente, con una variable de entorno que habilita la sincronización inmediata.

Así, cada avance o corrección en una sesión aparece en la otra en tiempo real. Si preferimos un ajuste permanente en un proyecto, lo fijamos en la configuración del entorno.

Comparación: de todos efímeros a tareas con estado y dependencias

Tareas y dependencias

A continuación, visualizamos un ejemplo simple de desglose, estados y bloqueos. Esta vista nos permite identificar de un golpe qué puede correr en paralelo y qué requiere terminar antes.

# Tarea Estado Dependencias
1 Crear ElevenLabsStreamingClient.swift Listo
2 Agregar configuración del proveedor de streaming Listo
3 Agregar UI del selector de proveedor Bloqueado #2
4 Agregar propiedad del cliente ElevenLabs Bloqueado #2
5 Enrutar streaming al proveedor correcto Bloqueado #1, #2, #4
6 Agregar cadenas de localización para streaming Bloqueado #1

Paralelización y ahorro de contexto

Cuando dividimos trabajo en sub‑agentes, cada tarea obtiene su propia “ventana de contexto fresca”. Esto disminuye colisiones y re‑lecturas, y nos permite ejecutar olas paralelas en tareas sin dependencias. Si, por el contrario, pedimos que todo se ejecute en un único contexto, el uso de tokens crece y la fatiga de contexto aparece antes. En equipos reales, la ganancia está en alternar paralelismo con sincronización en puntos de control.

  • Olas paralelas: ejecutamos tres tareas independientes y liberamos al orquestador para preparar la siguiente fase.
  • Secuenciación: las tareas con bloqueos esperan hasta que el sub‑agente anterior marque “completado”.
  • Handoff explícito: cada sub‑agente registra notas para la siguiente tarea y actualiza la lista antes de terminar.
El frame representa un diagrama con varias secciones principales. A la izquierda
Gestión eficiente de tareas con sub-agentes

Tareas del proyecto: dependencias y ejecución en paralelo

La siguiente tabla ordena qué corre en paralelo y qué requiere finalización previa. Sirve como guía para crear olas de ejecución.

Tarea Descripción Bloqueado Por Puede Ejecutarse En Paralelo
#1 Crear ElevenLabsStreamingClient.swift -
#2 Agregar configuración de streamingProvider a SettingsManager -
#6 Agregar cadenas de localización para proveedores de streaming -
#3 Agregar UI de selector de proveedor a StreamingView #2 Después de #2
#4 Agregar propiedad de streaming de ElevenLabs a RecordingTranscriptionFlow #1 Después de #1
#5 Implementar enrutamiento de proveedor en RecordingTranscriptionFlow+Streaming #1, #2, #4 Final

Dos sesiones, una sola lista de tareas

Sesiones A y B que comparten el mismo contexto de tareas

Cuando deseamos que dos sesiones cooperen en una sola lista, declaramos un identificador común. A partir de entonces, cada vez que una sesión marca una tarea como “completada” o añade un bloqueo, la otra lo ve al instante. Esto elimina los ciclos de “polling” y los estados desfasados que aparecían cuando revisábamos un archivo cada cierto intervalo.

  • Colaboración simultánea: una sesión orquesta y otra valida resultados.
  • Visibilidad cruzada: el panel de tareas refleja cambios en vivo, lo que evita que dos sesiones arranquen la misma tarea sin saberlo.
  • Revisión continua: podemos asignar a una sesión el rol de checker que verifica la implementación y, si falla, abre una nueva tarea para corregir.
La difusión de cambios en tiempo real evita duplicaciones y hace visible el bloqueo exacto que impide avanzar.

Instalación

A continuación, proponemos un paso a paso verificado para instalar Claude Code, configurar el entorno y activar la colaboración por listas de tareas compartidas.

  1. Instalar Node.js 18+ si aún no lo tenemos
  2. Instalar Claude Code con npm e iniciar sesión
  3. Verificar versión y actualizar cuando sea necesario
  4. Compartir listas de tareas entre sesiones

Necesitamos Node.js 18 o superior. En macOS o Linux podemos usar administradores de paquetes. En Windows instalamos desde el sitio oficial.

Ejecutamos la instalación global y luego abrimos el agente en un proyecto para autenticarnos con nuestra cuenta. Esta instalación estándar está documentada en la guía oficial de inicio.

Confirmamos que ejecutamos una versión reciente, especialmente si queremos usar la nueva gestión de tareas.

Establecemos el identificador de lista antes de lanzar cada sesión, o lo fijamos en la configuración para que quede permanente por proyecto.

{
 "env": {
 "CLAUDE_CODE_TASK_LIST_ID": "localization"
 }
}

Buenas prácticas

  • Definir olas claras. Aprovechamos la vista de dependencias para lanzar primero las tareas sin bloqueos. Cerramos la ola uno, verificamos con un checker y liberamos la ola dos.
  • Registrar aprendizajes. Pedimos a cada sub‑agente que actualice la descripción de su tarea con notas para la siguiente. Esto reduce fricciones en los handoffs.
  • Evitar el “todo en un solo contexto”. Si forzamos a un único contexto a ejecutar todas las tareas, sube el consumo de tokens y aparecen más merge conflicts.
  • Usar verificación automatizada. Un checker periódico que compare lo implementado con la descripción de la tarea y, si falla, cree una nueva entrada mantiene la calidad en sistemas grandes.
z

Conclusiones

El paso de los “todos” a Tasks representa para nosotros un cambio estructural en la forma en que coordinamos a Claude Code y sus sub‑agentes. La persistencia local reduce pérdidas de estado, las dependencias evitan colisiones y las listas compartidas sincronizan el trabajo entre sesiones. Si además sumamos un checker automatizado y buenas prácticas de handoff, obtenemos un flujo de ingeniería cercano al de un equipo humano: paralelizamos donde conviene, secuenciamos cuando toca y documentamos el progreso de manera operable.

Las tareas no sustituyen al criterio técnico, pero convierten la hoja de ruta en un contrato operable entre agentes y sesiones.

Para proyectos con varias iteraciones, el nuevo sistema de tareas nos permite avanzar con menos fricción y mayor trazabilidad. Cuando el trabajo sea breve o puntual, podemos prescindir de la orquestación y seguir con ejecuciones directas, pero en cuanto existan dependencias, agentes coordinados o pausas prolongadas, Tasks se convierte en la base más sólida para sostener el esfuerzo de desarrollo. Para consultar los detalles técnicos y la cronología oficial del cambio, el registro de versiones de Claude Code mantiene el rastro de cada incremento y nos ayuda a adoptar la novedad con criterio.

Comparte esta publicación