Cómo gestionar la memoria en agentes entre sesiones de forma eficiente

Context Engineering — el arte de gestionar el contexto del agente entre sesiones

Tiempo estimado de lectura: 5 min

• Context Engineering es disciplina operativa para mantener la memoria de agentes entre sesiones y evitar que “arranquen desde cero”.
• Tres archivos clave (CLAUDE.md, AGENTS.md, memory files) convierten reglas, roles y memoria en infraestructura reutilizable.
• Arquitectura de sub-agentes (orquestador, especialistas, QA) minimiza ruido y mejora precisión, latencia y coste.
• Prácticas concretas: cierre de sesión obligatorio, outputs estructurados (JSON/Zod), RAG con caché semántico y auditoría por ejecución.

Context Engineering es la práctica de diseñar y mantener la memoria operativa de agentes entre sesiones. Si aplicas GSD a equipos humanos, Context Engineering aplica GSD a agentes: dividir tareas, documentar decisiones y asegurar que la próxima sesión no sea una pizarra en blanco. Sin esta disciplina, los agentes alucinan, revierten decisiones y se vuelven caras e ineficaces.

Resumen rápido (lectores con prisa)

Context Engineering diseña la memoria y reglas permanentes de agentes para mantener continuidad entre sesiones. Úsalo cuando un sistema de agentes necesita precisión, trazabilidad y bajo coste operativo. Importa porque evita alucinaciones, pérdida de progreso y decisiones reversibles. Funciona con tres capas: reglas estáticas, memoria dinámica y sub-agentes especializados.

El problema

El problema es elegante y directo: los LLMs razonan bien, pero olvidan. El historial de chat como única memoria funciona en demos; colapsa en repositorios reales. Más tokens en el prompt solo añaden ruido. La solución práctica es convertir el repositorio en la memoria del agente mediante tres capas: reglas estáticas, memoria dinámica y sub-agentes especializados.

Tres archivos que cambian el juego: CLAUDE.md, AGENTS.md y memory files

CLAUDE.md (o .cursorrules) — la “constitución” del proyecto

Propósito: reglas inmutables que el agente debe respetar.

Contenido práctico: stack exacto (Node 20, React 18), políticas de seguridad, restricciones arquitectónicas y decisiones no negociables.

Ejemplo (resumen):

• Stack: Node 20, TypeScript 5.x, Next.js 14.
• Convenciones: ESLint + Prettier; tests en Vitest.
• Restricciones: “Nunca acceder a Supabase desde cliente; usar Server Actions”.

CLAUDE.md es lo primero que un agente debe leer al comenzar.

AGENTS.md — el organigrama legible por máquinas

Propósito: definir quién hace qué en un sistema multi-agente.

Contenido práctico: routing de tareas, roles (FrontendWorker, DBOptimizer, QAReviewer), permisos para commits.

Resultado: orquestador capaz de delegar la tarea correcta al sub-agente correcto sin mandar TODO el repo como contexto.

Memory files — la memoria viva (.context/ o .ai/)

– active_task.md: la tarea actual, objetivo y criterios de éxito.

– changelog_ai.md: decisiones y porqués (no sólo el qué).

– lessons_learned.md: problemas recurrentes y soluciones definitivas.

Rutina obligatoria: al cerrar sesión el agente actualiza estos archivos. Al abrir sesión, los lee y retoma.

Sub-agentes: aislar contexto, reducir ruido, mejorar precisión

Arquitectura propuesta:

Arquitectura propuesta

• Agente Orquestador (Router): lee AGENTS.md, empaqueta contexto mínimo y llama al especialista.
• Agente Especialista (Worker): recibe solo lo necesario (e.g., esquema DB + active_task.md) para reducir ruido.
• Agente Revisor (QA): valida output contra CLAUDE.md y tests antes de aplicar cambios.

Ventaja: un sub-agente con 10k tokens relevantes produce mejores resultados que un mega-agente con 100k tokens llenos de ruido. También reduce costos y latencia.

Prácticas operativas (lo que realmente marca la diferencia)

• Obliga a un “cierre de sesión”: el prompt final del día debe ser “Actualiza active_task.md, changelog_ai.md y sugiere el siguiente paso”.
• Usa esquemas para outputs: fuerza JSON/Zod para evitar outputs malformados.
• RAG + caché semántico: externaliza historial pesado en una vector DB y recupera solo lo necesario por tarea. (Ver LangChain)
• Streaming y UX: implementa streaming token a token para evitar bloqueos de UI. (Vercel AI SDK: Vercel AI SDK)
• Auditoría y permisos: registra cada ejecución de sub-agente y limita quién puede hacer merges automáticos.

Estructura mínima recomendada del repo

/project-root
  /src
  /.ai
    CLAUDE.md
    AGENTS.md
    active_task.md
    changelog_ai.md
    lessons_learned.md
  /.ai/logs
  /docs

Herramientas y lecturas útiles

• Claude / Anthropic docs
• Cursor
• n8n (orquestación de workflows)
• LangChain (RAG & retrievers)
• Prisma
• OpenAPI Spec
• Vercel AI SDK

Criterio final para equipos técnicos

Context Engineering no es documentación bonita. Es infraestructura operativa que convierte agentes en miembros persistentes del equipo. Si inviertes en reglas estáticas (CLAUDE.md), memoria dinámica (memory files) y una red de sub-agentes bien definida (AGENTS.md + orquestador), ganarás precisión, velocidad y trazabilidad. Sin esto, los agentes seguirán siendo costosos “showrooms” en lugar de fuerza productiva real.

Aplica GSD a tus agentes: trocea, documenta, cierra sesiones. Si lo haces bien, el agente no volverá a arrancar desde cero.

Dominicode Labs

Si te interesa profundizar en automatización, agentes y workflows aplicados a equipos técnicos, puedes continuar explorando recursos y experimentos en Dominicode Labs. Es una continuación lógica para poner en práctica patrones de Context Engineering mencionados aquí.

FAQ

• ¿Qué es Context Engineering?
• ¿Cuándo debo usar CLAUDE.md?
• ¿Para qué sirve AGENTS.md?
• ¿Qué contienen los memory files y quién los actualiza?
• ¿Por qué usar sub-agentes en lugar de un mega-agente?
• ¿Qué es RAG y por qué es relevante aquí?
• ¿Cómo auditar ejecuciones de sub-agentes?