Dejé de Gestionar Mi Ventana de Contexto. Empecé a Diseñar Con Ella.

No tuve la epifanía leyendo un changelog. Me golpeó a mitad de sesión, tres agentes metidos en un refactor, hilo principal apenas al 30%. Sin /compact. Sin reiniciar. Simplemente... limpio.

Seis semanas antes, era como todos los demás. Degradación de contexto al 60%, respuestas vagas, Claude olvidando el archivo que acababa de leer. El tipo de situación donde quieres golpear algo (pero no puedes golpear una IA, así que solo te quedas mirando la pantalla y respiras).

Entonces /insights soltó el diagnóstico que nunca pedí: 219 eventos de solapamiento en 28 días. Estaba haciendo multi-clauding sin saberlo.

Marzo de 2026 fue un festival de herramientas. Subagentes maduros, Agent Teams, context: fork. Este artículo no es un tour de funcionalidades. Es cómo cambió mi modelo mental, y el marco de decisión que uso ahora para decidir si lanzo uno, dos o cinco agentes.

Tres Agentes, Un Refactor, Cero Compactación

El refactor era una sincronización de productos WooCommerce que había estado acumulando deuda técnica durante seis meses. El tipo de código donde cada archivo tiene un comentario que dice "arreglo temporal" de enero.

Tres agentes, cada uno en su propio contexto. Uno en la capa API (doce endpoints, validación, rutas de error). Uno reescribiendo la lógica de transformación que se había vuelto espagueti por seis meses de "solo agrega una condición". Uno auditando la suite de tests para descifrar cuáles tests realmente probaban algo versus cuáles simplemente... estaban ahí. Tests de vibra.

Hilo principal al 30%, coordinando, sin hacer el trabajo pesado. Ningún momento donde Claude empieza a responder preguntas sobre archivos que leyó hace cuarenta minutos con la confianza de alguien que definitivamente no leyó ese archivo. (Conoces esa cara. La cara de confianza equivocada.)

El mismo refactor, dos meses antes: sesión única, el contexto se llena en el segundo endpoint, las respuestas se vuelven vagas alrededor del archivo siete, reinicio, re-explico toda la mise en place, pierdo veinte minutos, reinicio otra vez. Para el tercer reinicio ya no estoy refactorizando. Estoy cuidando la memoria de Claude.

Esta vez, dos horas. Resúmenes limpios de cada agente. Merge, test, push.

Ya no estaba gestionando una ventana. Estaba diseñando un sistema de contextos.

El Diagnóstico Que No Pedí

Ejecuté /insights en mi uso de Claude Code. 374 sesiones. 219 eventos de solapamiento multi-Claude en 28 días. No porque fuera inteligente. Porque seguía abriendo nuevas sesiones cuando la vieja se degradaba, sin cerrarla. Multi-clauding accidental, la razón detrás de los malos hábitos.

El conteo de solapamientos era un síntoma. La enfermedad estaba debajo: estaba tratando el contexto como un recurso escaso. Cada /compact era una pequeña admisión de que la sesión se estaba degradando. Cada reinicio era una más grande. Y cada vez que abría una segunda terminal "solo para revisar algo rápido," mi flujo de trabajo estaba tratando de distribuir contexto antes de tener las herramientas para hacerlo a propósito.

La degradación de contexto era el síntoma. Tratar el contexto como una limitación era la enfermedad.

Hacer multi-clauding por accidente no es señal de incompetencia. Es una señal de que el flujo de trabajo superó el modelo de sesión única. Si tu /insights muestra solapamientos, probablemente ya llegaste ahí también.

El Contexto Dejó de Ser una Limitación. Se Volvió Material de Construcción.

El resultado primero.

En marzo de 2026, cuatro cosas se lanzaron al mismo tiempo: la ventana de contexto de 1M tokens, tipos de subagentes maduros (Explore, Plan, General purpose), context: fork como funcionalidad de primera clase en custom skills, y Agent Teams como modo multi-agente experimental. Cada una útil por sí sola. Juntas, cambiaron lo que es una ventana de contexto.

No una caja que se llena. Un material que distribuyes.

Piensa en el cambio de monolito a microservicios. No la versión del hype con doce servicios y un message bus para una app de todos. La versión real: dejaste de tratar de ahorrar RAM en un proceso grande y empezaste a diseñar límites de aislamiento. Cada servicio obtiene su propia memoria. El orquestador se mantiene ligero. La comunicación ocurre a través de interfaces definidas, no estado compartido. Mismo cambio, aplicado al contexto. Cada subagente obtiene una ventana fresca de 200K. El hilo principal se mantiene ligero. Los resultados regresan como resúmenes, no sangrado crudo.

La comunidad de practicantes está convergiendo en números similares. "Dividir por contexto, no por rol" sigue surgiendo como patrón. El contexto principal se queda alrededor del 30-40% para la gente que hizo el cambio. Lydia Hallie del equipo de Claude Code presenta context: fork como una funcionalidad de diseño, no un workaround. Simon Willison formalizó los patrones de subagentes en sus escritos de ingeniería agéntica.

¿Por qué ahora? Estos patrones no son nuevos (Docker no inventó los contenedores). Pero la convergencia de marzo los hizo accesibles para cualquier dev solo con un plan Max. Antes de marzo, distribuir contexto significaba pelear con las herramientas. Después, las herramientas lo esperan.

Advertencia justa: la analogía de microservicios se rompe rápido si la empujas. No hay service discovery entre agentes. No hay "context mesh." Agent Teams es experimental, no un runtime distribuido maduro. El modelo mental ayuda. La analogía es un punto de partida, no un destino.

Mismo modelo, mismos tokens. Relación completamente diferente.

La teoría es limpia. En la práctica, la pregunta de cada sesión se reduce a algo brutalmente simple: ¿lanzo uno, dos o cinco agentes?

El Marco de Decisión Que Realmente Uso

Llega tarea
├── Alcance coherente, archivos relacionados, contexto < 40%
│   └── Agente único. Prefijo scope-lock. Listo.
├── Exploración pesada (> 3 archivos no relacionados para leer), resultado = resumen
│   └── Subagente / context: fork. Él explora, tú te mantienes limpio.
└── Subtareas independientes + beneficio de coordinación
    └── Agent Team. Pero: si los agentes necesitan constantemente
        leer el output del otro → de vuelta a agente único.

Tres regímenes. Los límites importan más que las categorías.

Agente único sigue siendo la decisión correcta para la mayoría de tareas. Una adición de funcionalidad tocando tres archivos relacionados. Un bug fix donde el alcance es obvio. Si el contexto cabe cómodamente y los archivos están relacionados, generar un subagente agrega overhead sin beneficio. Un prefijo scope-lock en tu prompt hace el trabajo: "Estás trabajando en X. Solo toca archivos Y y Z. No explores más allá de este alcance."

Subagentes son para cuando la exploración envenenarían tu contexto principal. El trigger al que llegué: si necesito leer más de tres archivos no relacionados para responder una pregunta, eso es un spawn. La semana pasada, un subagente explorando el flujo de auth de una API partner leyó catorce archivos en tres repos, devolvió un resumen de seis líneas. Mi contexto principal no se movió. La misma exploración en una sesión única habría comido 35-40% de la ventana con contenidos de archivos que nunca volvería a ver.

Agent Teams son para cuando las subtareas son independientes pero el resultado general se beneficia de ejecución paralela. El refactor de la sección uno. Una sesión de debugging con tres hipótesis exploradas simultáneamente. La prueba crítica: si los agentes necesitan constantemente leer el output del otro para proceder, no tienes subtareas independientes. Tienes una sola tarea usando gabardina pretendiendo ser tres. Regresa a agente único.

La estructura de prompt que uso para lanzar un Agent Team:

"Tres agentes paralelos. Cada agente obtiene UN alcance:
- Agente 1: [alcance]. Entrega: [output específico].
- Agente 2: [alcance]. Entrega: [output específico].
- Agente 3: [alcance]. Entrega: [output específico].
Ningún agente lee archivos de otro agente. El merge final es mío."

Cada agente recibe un alcance, limitaciones y un entregable esperado. Si reconoces el patrón, es porque los límites de contexto funcionan como contratos de prompt aplicados a arquitectura multi-contexto. Misma disciplina. Alcance, limitaciones, entregable. Excepto que ahora estás escribiendo el contrato para un contexto aislado, no una sesión única.

Este marco está calibrado en uso solo/indie. En un equipo de cuatro devs, la dinámica cambia (conflictos de git, permisos, coordinación humana apilada sobre coordinación de agentes). No he probado Agent Teams bajo estrés en equipo aún. Solo, se mantiene.

La regla: si no puedes escribir el contrato del subagente en dos oraciones, no necesita existir.

La Cuenta de Tokens De La Que Nadie Quiere Hablar

Distribuir contexto cuesta más tokens. Esa es la parte honesta, y pretender lo contrario sería deshonesto.

Agent Teams ejecutan 4-7x los tokens de una sesión única haciendo el mismo trabajo. Subagentes en paralelo en un plan Pro golpean el rate limit en unos veinte minutos. El plan Max a $100-200/mes es el piso realista para este flujo de trabajo.

Ahora la parte que nadie calcula.

El prompt caching cambia las matemáticas. En sesiones pesadas, 90%+ de los tokens son cache reads a $0.50 por millón de tokens para Opus. El multiplicador es real, pero es un multiplicador sobre una base que es dramáticamente más barata que el precio de etiqueta. Mi cuenta mensual subió tal vez 40% después de cambiar a multi-contexto. No 400%. La capa de prompt caching es lo que hace que toda la economía multi-contexto realmente funcione.

Pero olvida la cuenta de tokens por un segundo. Karen de Contabilidad me mataría por decir esto, pero la cuenta de tokens es la hoja de cálculo equivocada.

El costo real de la degradación de contexto: los veinte minutos re-explicando contexto después de un reinicio. El bug que envías porque la respuesta de Claude se basó en un archivo que medio recordaba. El tercer reinicio donde te rindes del refactor y lo haces a mano. Ese costo no aparece en ninguna factura. Aparece en tu viernes por la tarde, el que se suponía pasarías en la piscina con los niños, debuggeando una sesión que se pudrió al 65%.

Multi-contexto elimina el costo invisible. La cuenta de tokens sube. El costo total baja.

Estos números son plan Max con prompt caching de Opus. En Pro, la proporción cambia fuerte. En API directo sin caching, multi-contexto puede volverse prohibitivo. No copies mis números a tu tier.

Qué Cambia Cuando Todos Piensan Así

La señal más clara de que este cambio es real no son las funcionalidades. Es que los practicantes que cambiaron no regresan. "Dividir por contexto, no por rol" se está volviendo un reflejo, no consejo. La gente ejecutando multi-contexto diariamente no lo está evangelizando. Solo lo están haciendo, de la manera que nadie habla de usar git ya. Solo usas git.

Las herramientas están siguiendo. Agent Teams es experimental hoy pero la dirección está establecida. La persistencia de contexto entre sesiones ya se está enviando (auto-memory, /resume). Hay 100+ configs de subagentes comunitarios en GitHub construyendo sobre el patrón antes de que siquiera tenga un nombre oficial.

La mayoría de devs aún usan Claude Code como un monolito con una ventana grande. Y funciona. Pero algunas tareas merecen más. Y saber cuáles, ese es todo el punto. 🤷

Hace dos meses estábamos luchando contra la degradación de contexto. Reiniciar, compactar, limpiar, optimizando MCPs, podando skills... rezando que Claude recordara la línea 42.

Hoy mis archivos CLAUDE.md son un animal diferente. No más listas de "no hagas X". Declaraciones de alcance para cada contexto. Mis skills tienen context: fork por defecto. La estructura del proyecto refleja distribución de contexto, no al revés.

El cambio no fue técnico. Las herramientas ya existían en piezas. El modelo mental se movió: deja de proteger una sesión única, empieza a arquitecturar contextos aislados. Todo lo demás siguió.

Un agente es suficiente para la mayoría de tareas. Pero saber cuándo no es suficiente, y hacer fork en el momento correcto en lugar de aferrarse a una sesión que se está pudriendo, esa es la diferencia entre usar Claude Code y entenderlo.

Fuentes

Simon Willison, "Agentic Engineering Patterns" (simonwillison.net). Lydia Hallie (Anthropic), documentación y presentaciones de Claude Code context: fork. Akshay Pachaar, "split by context, not by role" (X/Twitter, marzo 2026).

(*) La portada es generada por IA. Los tres agentes en la imagen tienen mejor coordinación que la mayoría de standups a los que he asistido.