Memory Palace — Forma Correcta De Hacer Agentes

El error que la mayoría comete al armar sistemas multi-agente: hacer subagentes especializados que duplican trabajo porque cada uno tiene su propia memoria aislada. El "Researcher" investiga algo que el "Writer" ya sabe. El "Analyst" pide data que el "Researcher" ya buscó. Resultado: 3 agentes haciendo el trabajo de 1.5.

Memory Palace propone otra forma: una sola memoria compartida con estructura profesional, donde cada agente lee y escribe. Cada agente nuevo hace al equipo más inteligente, no más lento.

El antipatrón

Setup típico que sale mal:

Crew:
  - Researcher (memory: researcher.json)
  - Writer (memory: writer.json)
  - Reviewer (memory: reviewer.json)
  - Analyst (memory: analyst.json)

Cuando le pedís al crew "armame artículo sobre X":

1. Researcher busca info sobre X. Guarda en researcher.json.
2. Writer empieza a escribir. No tiene acceso a researcher.json. Le pasamos un resumen.
3. Reviewer revisa. No conoce el research. Hace observaciones genéricas.
4. Analyst chequea data. Vuelve a buscar info de X.

El analyst hizo trabajo redundante. El reviewer dio feedback shallow. Pérdida de eficiencia: 30-50%.

La forma correcta: memoria compartida

Crew con shared memory: ./palace/

Researcher → lee y escribe a ./palace/
Writer     → lee y escribe a ./palace/
Reviewer   → lee y escribe a ./palace/
Analyst    → lee y escribe a ./palace/

Todos comparten. Cada agente ve lo que los otros pusieron. El próximo agente que llega tiene toda la historia disponible.

Cuando un agente nuevo entra al equipo (digamos "SEO Specialist"), lee el palace y se entera de:

• Qué se investigó.
• Qué se escribió.
• Qué se revisó.
• Qué decisiones se tomaron y por qué.

Su trabajo es agregar al palace, no empezar de cero.

La estructura del Palace

Sin estructura, el palace se vuelve dump caótico. La propuesta:

./palace/
├── facts/           ← información verificada sobre el tema
│   ├── 001-X-fundamental.md
│   ├── 002-X-statistics.md
│   └── 003-X-comparables.md
├── decisions/       ← decisiones tomadas con justificación
│   ├── 001-tone.md
│   ├── 002-structure.md
│   └── 003-audience.md
├── drafts/          ← versiones in-progress
│   ├── 001-outline.md
│   ├── 002-first-draft.md
│   └── 003-second-draft.md
├── reviews/         ← feedback con timestamp y autor
│   ├── 2026-05-15-reviewer1.md
│   └── 2026-05-16-reviewer2.md
└── index.md         ← tabla de contenidos del palace

Cada agente sabe:

• Para agregar info, va a facts/.
• Para tomar decisión, escribe en decisions/.
• Para draft, en drafts/.
• Para revisar, en reviews/.

Cómo se ve un crew bien diseñado

crew:
  shared_memory: ./palace/
  
  agents:
    - role: Researcher
      memory_access: ./palace/
      instructions: |
        Antes de investigar, leé ./palace/facts/ y ./palace/index.md.
        Solo investigá lo que NO esté ya en facts/.
        Escribí nuevos hallazgos en facts/ con naming descriptivo.
        Actualizá index.md.
    
    - role: Writer
      memory_access: ./palace/
      instructions: |
        Leé todo de ./palace/facts/ y ./palace/decisions/.
        Si una decisión clave no está tomada, pedila al Strategist 
        antes de escribir.
        Tus drafts van en ./palace/drafts/, numerados.
    
    - role: Reviewer
      memory_access: ./palace/
      instructions: |
        Leé el draft más reciente en ./palace/drafts/.
        Cross-checkeá con ./palace/facts/ — flag inconsistencias.
        Tu review va en ./palace/reviews/ con tu nombre y timestamp.

Cada agente con responsabilidad clara sobre el palace.

Implementación práctica

Opción 1: con CrewAI

from crewai import Agent, Task, Crew
from crewai.memory import SharedMemory

palace = SharedMemory(path="./palace/")

researcher = Agent(
    role="Researcher",
    goal="Investigar sobre temas asignados",
    backstory="Especialista en research técnico",
    memory=palace
)

writer = Agent(
    role="Writer",
    goal="Escribir basado en facts del palace",
    memory=palace
)

# ... etc

crew = Crew(
    agents=[researcher, writer, reviewer],
    tasks=[...],
    memory=palace  # ← clave: shared memory para todo el crew
)

Opción 2: con Claude Code multi-agente

# .claude/skills/palace-orchestrator/SKILL.md
---
name: palace-orchestrator
description: Coordina agentes con memoria compartida en ./palace/
---

# Palace Orchestrator

Cuando se invoque, leé ./palace/index.md primero.

Si una sub-tarea requiere agente especializado, spawneá sub-agente 
con instrucción de leer/escribir en ./palace/.

Cada sub-agente DEBE actualizar ./palace/index.md al terminar.

Opción 3: manual con scripts

Si no querés framework, escribís scripts que orquestan:

def run_agent(role, prompt, palace_path):
    # Leer palace
    palace_state = read_palace(palace_path)
    
    # Llamar a Claude/OpenAI con palace_state en contexto
    response = call_llm(prompt + "\n\nPalace state:\n" + palace_state)
    
    # Parsear response, actualizar palace
    update_palace(palace_path, role, response)
    
    return response

Simple pero efectivo para crews chicas.

Cuándo cada agente nuevo HACE más smart al sistema

Antes vs. después de agregar un agente nuevo:

Crew base (3 agentes)

• Researcher
• Writer
• Reviewer

Resultado para artículo: bien, pero falta dimensión SEO.

Crew + SEO Specialist (4 agentes)

Con memoria aislada (antipatrón): SEO Specialist hace research de keywords desde cero. Tarda 30 minutos.

Con palace: SEO Specialist lee ./palace/facts/ y ya conoce el tema. Solo busca keywords específicas. Tarda 5 minutos. Aporta valor sin duplicar.

Crew + Image Specialist (5 agentes)

Con palace: Image Specialist lee ./palace/drafts/ y entiende la narrativa. Sugiere imágenes coherentes con el flow, no genéricas.

Cada agente nuevo se vuelve más útil porque hereda contexto. El equipo escala.

Anti-patrones del palace

Anti-patrón 1: palace sin estructura

Una sola carpeta con archivos sueltos. Después de 50 archivos, nadie encuentra nada. Los agentes se confunden.

Solución: estructura desde el inicio (facts/, decisions/, drafts/, reviews/).

Anti-patrón 2: escribir sin leer

Algunos agentes solo escriben (egoístas). Resultado: duplicación.

Solución: en cada SKILL.md o instruction de agente, mandar "leé primero, escribí después".

Anti-patrón 3: palace sin index

50 archivos en facts/ y ningún índice. El próximo agente tiene que abrir cada uno para saber qué hay.

Solución: index.md actualizado por cada agente que escribe. Una línea por entrada.

Anti-patrón 4: palace inmortal

El palace crece sin límite. Después de 6 meses tiene 5GB de docs viejos irrelevantes.

Solución: archive periódico. Mover contenido viejo a ./palace-archive/<año>/. Resetear a estado limpio para temas nuevos.

Anti-patrón 5: dependencia frágil

Tu crew necesita el palace para funcionar. Si se corrompe el archivo, todo se rompe.

Solución: backups versionados (git el palace). Restauración de cualquier estado anterior.

Compatibilidad con frameworks

Memory Palace es agnostic — no requiere framework específico. Funciona con:

• CrewAI (con SharedMemory).
• LangChain (con shared VectorStore).
• AutoGen (con shared knowledge graph).
• Multi-Claude Code agents (con archivos compartidos).
• Implementación custom.

Lo importante es el patrón, no la implementación.

Sinergia con Memory persistente

Memory Palace es para la sesión actual (este artículo). Memory persistente (Claude-Mem, MemPalace) es para entre sesiones.

Combinación recomendada:

• Palace para un crew/proyecto/sesión específica.
• Memory persistente para conocimiento que sobrevive al palace.

Cuando el palace se "archiva", lo que sea valioso largo plazo se mueve a memoria persistente.

Caso de uso completo: producción de un curso

Pedido: "Armame curso completo de 8 lecciones sobre Tema Y."

Crew con palace:

1. Strategist define audience, objetivos, estructura. Escribe en decisions/.
2. Researcher investiga cada lección. Llena facts/ por lección.
3. Curriculum Designer define learning path. Escribe en drafts/curriculum.md.
4. Lesson Writer escribe cada lección consultando palace. Drafts en drafts/lesson-N.md.
5. Reviewer valida cada lección contra decisions/ y facts/. Reviews en reviews/.
6. Exercise Designer lee drafts/lesson-N.md y genera ejercicios. Va en drafts/exercises-N.md.
7. Video Brief Writer lee todo, propone video brief por lección. drafts/video-brief-N.md.

7 agentes. Sin palace, cada uno empezaría de cero y duplicaría research. Con palace, cada uno hereda del anterior.

Tiempo total: 4-8 horas en lugar de 20-30 horas manual.

Conclusión

El error de "armar más agentes y ya está" lleva a sistemas que parecen sofisticados pero son ineficientes. Memory Palace propone disciplina: una sola memoria compartida, estructura clara, cada agente lee antes de escribir.

Si estás armando tu primer crew, empezá con palace desde el día uno. Si ya tenés crew con memorias aisladas, refactor a palace te toma 1-2 horas y la mejora se siente desde el primer corrido.

Tags: memory-palace, subagentes, agentes, memoria-compartida, claude-code, multi-agente