Dividir el Contexto del Agente en Tres Capas para Resolver el Problema del Monolito de 700 Líneas

Al construir agentes autónomos persistentes, surge un problema común: el contexto del agente comienza en un archivo pero crece a más de 700 líneas, mezclando reglas de identidad, estrategia actual, referencias de herramientas, actualizaciones de precios y procedimientos de publicación. Este monolito se vuelve inmanejable: editar en qué enfocarse esta semana está en el mismo archivo que las reglas de "nunca hacer esto", causando vacilación y errores. Un equipo que construye un sistema de 6 agentes que se autoinicia desde cero encontró este problema exacto: para la segunda semana, el lanzador alcanzaba los límites de argumentos y las sesiones fallaban silenciosamente.

La división en tres capas

La solución fue separar el contexto del agente por tipo de preocupación y frecuencia de cambio en tres archivos distintos:

• CLAUDE.md - Identidad: quién es el agente, reglas estrictas, personalidad. Casi nunca cambia. Se puede almacenar en caché.
• BRIEFING.md - Misión: en qué enfocarse ahora mismo, estrategia actual, precios, objetivos. Cambia semanalmente.
• PLAYBOOK.md - Operaciones: cómo hacer las cosas mecánicamente: procedimientos, comandos CLI, referencias de herramientas. Cambia cuando cambian las herramientas.

Una pieza de información vive exactamente en una capa. Si una referencia de herramienta está en PLAYBOOK, no está en BRIEFING. La duplicación conduce a contradicciones silenciosas.

Por qué funciona esta arquitectura

Edición práctica: Todos saben qué archivo editar. ¿En qué enfocarse? BRIEFING. ¿Cómo publicar? PLAYBOOK. ¿Nunca hacer esto? CLAUDE.md. Sin adivinar ni hojear 700 líneas.

Eficiencia técnica: Cuando un agente se reinicia (lo que sucede con frecuencia), la identidad permanece estable. Se usa el mismo CLAUDE.md en cada sesión, permitiendo que las capas de caché vean un prefijo de solicitud idéntico para aciertos de caché casi gratuitos. BRIEFING y PLAYBOOK llegan mediante llamadas a herramientas en el primer inicio: el agente los lee antes de hacer un trabajo sustantivo, por lo que no son redundantes. El argumento de lanzamiento permanece pequeño para siempre, incluso si PLAYBOOK crece a más de 2000 líneas.

Disciplina: Un monolito acepta cualquier contenido en cualquier lugar. Esta especificación te obliga a preguntar: ¿esto es sobre carácter, misión o mecánica? Responder esa pregunta cambia cómo piensas sobre el sistema.

Patrones de inyección

Patrón A (Simple): Lee los tres archivos al lanzar, concatena e inyecta. Funciona si el tamaño total se ajusta al límite de argumentos de tu lanzador.

Patrón B (Agentes persistentes): Inyecta solo CLAUDE.md al lanzar. CLAUDE.md contiene un mandato: Primera acción, leer BRIEFING.md y PLAYBOOK.md. El agente primero llama a herramientas para cargar los documentos de misión y operaciones antes de que comience cualquier trabajo. La solicitud de lanzamiento permanece pequeña incluso cuando los manuales crecen. Este es el predeterminado para agentes que se reinician.

El equipo usa el Patrón B. Cada sesión, el agente se despierta, lee BRIEFING, lee PLAYBOOK, luego ejecuta. Contexto fresco cada vez, identidad en caché, sin ansiedad por límites de argumentos.

Resultados después de la implementación

• La edición tomó segundos en lugar de minutos, sin miedo a romper cosas no relacionadas.
• Las ediciones de BRIEFING entre sesiones simplemente funcionan: el agente lee el BRIEFING fresco en el próximo reinicio.
• PLAYBOOK creció a más de 2000 líneas sin ansiedad de lanzamiento.
• La incorporación de nuevos agentes fue más rápida: hay un esqueleto claro para llenar.

Este enfoque no es revolucionario: es separación de preocupaciones aplicada al contexto del agente. Pero una vez que has encontrado el problema del monolito, esto lo soluciona estructuralmente. Para equipos que construyen agentes autónomos que se reinician, vale la pena conocer esta arquitectura.