Saltar a contenido

File-based agent memory

Patrón: el agente LLM es stateless entre invocaciones; la memoria persiste en archivos markdown del repo que el agente lee al arrancar y reescribe al terminar. Esencial para cualquier routine scheduled.

Estructura típica (según el video)

repo/
├── CLAUDE.md              # system instructions — personalidad + reglas
├── memory/
│   ├── strategy.md        # estrategia de trading vigente
│   ├── trade_log.md       # append-only, todas las órdenes ejecutadas
│   ├── research_log.md    # lo que aprendió leyendo noticias
│   ├── positions.md       # estado actual del portfolio
│   ├── lessons.md         # errores y aprendizajes
│   └── weekly_review.md   # grades + ajustes sugeridos
├── skills/
│   ├── research.md
│   ├── place-trade.md
│   └── update-log.md
└── routines/              # prompts por horario (pre-market, open, etc.)

Flujo por routine

  1. Read phase: agente lee CLAUDE.md + memory files relevantes.
  2. Act phase: ejecuta su lógica (research, trade, review).
  3. Write phase: actualiza trade_log.md, lessons.md, positions.md, etc.

Si falla el paso 3, se pierde la memoria de esa run. Por eso es crítico que el agente escriba antes de notificar/terminar.

Ventajas

  • Auditable: todo cambio queda en git.
  • Agnóstico del harness: funciona en Claude Code, OpenAI Assistants, OpenClaw, cualquier LLM con file-edit tool.
  • Barato vs embeddings/vector DB.
  • Depurable: si algo va mal, lees el log.

Desventajas

  • Escala mal a miles de entradas (context budget).
  • Requiere disciplina del prompt para que el agente realmente escriba y no sólo lea.
  • Race conditions si dos routines corren en paralelo — el video NO aborda esto.

Relación con el método Karpathy

El concepto es idéntico al LLM Wiki Method de Karpathy (ver proyecto hermano karpathy-llm-wiki-method/wiki/concepts/llm-wiki-method.md) aplicado a un dominio vertical (trading). Karpathy lo describe para knowledge bases; Nate Herk lo adapta para un agente operacional.

Relaciones