ChainMemory Docs

SISTEMAS MULTI-AGENTE

ChainMemory fue diseñado desde cero para un mundo donde múltiples agentes de IA colaboran en el mismo proyecto. Cada agente lee el mismo Project State, cada contribución se atribuye individualmente, y cada handoff es trazable.

El Problema Multi-Agente

Los flujos de trabajo de desarrollo modernos ya involucran múltiples agentes de IA:

Claude diseña la arquitectura y escribe documentación
Cursor implementa el código con asistencia IA inline
GPT-4 revisa PRs y analiza implicaciones de seguridad
Gemini procesa codebases grandes para sugerencias de refactoring

Sin memoria compartida, cada agente empieza de cero. Las decisiones tomadas en Claude son invisibles para Cursor. La arquitectura acordada en GPT es desconocida para Gemini. Vos te convertís en el cuello de botella — constantemente re-explicando contexto.

Cómo ChainMemory Resuelve Esto

Project State Compartido

Todos los agentes conectados al mismo proyecto ven el mismo estado consolidado: decisiones, hitos, riesgos, stack y contexto. Cuando Claude marca una decisión como "active", Cursor la ve inmediatamente.

Flujo de Estado Compartido
┌──────────┐    ┌──────────────────────────┐    ┌──────────┐
│  Claude  │───▶│                          │◀───│  Cursor  │
│  (MCP)   │    │   Proyecto ChainMemory   │    │  (MCP)   │
└──────────┘    │                          │    └──────────┘
                │  decisions: [d001, d002]  │
┌──────────┐    │  milestones: [m001]      │    ┌──────────┐
│  GPT-4   │───▶│  risks: [r001, r002]     │◀───│  Gemini  │
│  (API)   │    │  stack: [Node, Redis]    │    │  (API)   │
└──────────┘    └──────────────────────────┘    └──────────┘

Patrón Agent Handoff

Cuando el trabajo pasa de un agente a otro, ChainMemory proporciona transferencia de contexto sin fricciones:

Claude diseña la arquitectura

Claude guarda decisiones clave vía MCP: elección de base de datos, estructura de API, estrategia de autenticación. Cada memoria se atribuye al ai_id de Claude.

Claude guarda
chainmemory_remember({
  content: "Usar PostgreSQL con row-level security para aislamiento multi-tenant",
  tags: ["architecture", "database", "security"],
  importance: 0.9
})

Cursor toma la implementación

Cuando abrís Cursor, inyecta el contexto del proyecto automáticamente. Cursor conoce la elección de base de datos, la estructura de API, y por qué se tomaron esas decisiones — sin que repitas nada.

Cursor recibe (via inject)
Project State v3:
- Decisión d001: "Usar PostgreSQL con RLS" (active, evidence: #12, #15)
- Decisión d002: "API REST con endpoints versionados" (active, evidence: #18)
- Hito m001: "Schema de BD completo" (pendiente)
- Riesgo r001: "Performance de RLS en tenants grandes" (medio, evidence: #15)

Cursor implementa y guarda progreso

Mientras Cursor implementa, guarda memorias de implementación. Estas se atribuyen al ai_id de Cursor y alimentan el estado compartido.

GPT-4 revisa con contexto completo

Un agente GPT-4 revisando el PR puede consultar ChainMemory para entender por qué se tomó cada decisión, quién la tomó, y qué evidencia la respalda.

Patrones de Handoff

Patrón	Flujo	Caso de Uso
Secuencial	Claude → Cursor → GPT-4	Diseño → Implementar → Revisión
Paralelo	Claude + Cursor + Gemini simultáneamente	Múltiples developers, mismo proyecto
Especialista	Cualquier agente → Agente seguridad → Vuelve	Expertise específica on demand
Supervisión	Humano + Claude supervisan, Cursor ejecuta	Human-in-the-loop con delegación

Resolución de Conflictos Entre Agentes

Cuando dos agentes toman decisiones contradictorias, la Resolución de Conflictos de ChainMemory aplica las mismas reglas:

Precedencia temporal — La decisión más reciente gana, sin importar qué agente la tomó
Peso de evidencia — Una decisión respaldada por 5 memorias de 3 agentes es más fuerte que una con una sola memoria
Supersesión explícita — Cualquier agente puede explícitamente reemplazar una decisión anterior referenciándola
Auditoría completa — Tanto la decisión original como la que la reemplaza se preservan con su respectiva atribución de ai_id

Ningún punto único de verdad — excepto la cadena En un sistema multi-agente, ningún agente individual es dueño de la "verdad". El Project State es una vista materializada derivada de las contribuciones de todos los agentes. El ancla on-chain es la única marca temporal autoritativa. Esto significa que incluso si un agente alucina o comete un error, la cadena de evidencia permite que otros agentes (o humanos) lo rastreen y corrijan.

Configurar Multi-Agente

No se necesita configuración especial. Cualquier agente conectado al mismo proyecto participa automáticamente en la colaboración multi-agente:

Crear un proyecto vía Extension, MCP, o API
Usar la misma API key en todos los agentes (o crear keys específicas por agente bajo la misma cuenta)
Cada agente usa inject_memories al inicio de sesión para cargar contexto compartido
Cada agente usa chainmemory_remember para guardar contribuciones
El Motor de Consolidación fusiona todas las contribuciones en el Project State unificado

Mejor práctica Usá tags descriptivos que identifiquen el rol del agente: ["architecture", "claude-design"], ["implementation", "cursor-code"], ["review", "gpt4-security"]. Esto facilita el filtrado por rol de agente sin necesidad de parsear el ai_id directamente.