Evaluación y comparativa

Dimensiones de evaluación arquitectónica

Evaluar sistemas de memoria para agentes exige ir más allá de la recuperación vectorial superficial y analizar la arquitectura básica de producción: modelo de datos, aislamiento multinquilino, garantías de consistencia, cumplimiento de protocolos, latencia y legibilidad por máquinas.

• Modelo de almacenamiento: Metadatos relacionales híbridos con incrustaciones vectoriales frente a almacenes vectoriales planos. La base relacional garantiza filtrado pushdown exacto, registros de auditoría inmutables y particionamiento determinista de ámbitos.
• Aislamiento multinquilino: Particiones físicas forzadas por hardware o servidor frente al filtrado por metadatos a nivel de aplicación. Los espacios compartidos requieren vinculaciones de espacio firmadas criptográficamente.
• Garantías de consistencia: Consistencia de lectura tras escritura (read-your-writes) en llamadas distribuidas frente a ventanas de consistencia eventual que provocan alucinaciones en bucles continuos de agentes.
• Cumplimiento de protocolos: Puntos de enlace HTTP nativos de Model Context Protocol (MCP) Streamable frente a envoltorios propietarios que requieren adaptadores SDK por framework.
• Legibilidad por máquinas: Respuestas JSON estructuradas y deterministas que cumplen estrictamente los esquemas de herramientas sin textos conversacionales de relleno.

Qué evaluar en cualquier capa de memoria

Evalúe cualquier sistema de memoria para agentes según siete dimensiones fundamentales de producción: aislamiento de ámbito, atribución del autor, eliminación en el ciclo de vida, integración de protocolos, límites de concurrencia, pruebas comparativas reproducibles y características sujetas a planes.

• Aislamiento de ámbito: Pregunte a cualquier proveedor cómo se particionan las memorias de usuario, sesión, agente y espacio de trabajo. XMemo aplica una jerarquía ortogonal de ámbitos de 4 niveles (user, session, agent, team/space) con aislamiento de proyecto de primer nivel en el límite de almacenamiento (consulte /docs/concepts/scopes y /docs/concepts/projects).
• Atribución y procedencia: Pregunte a cualquier proveedor si cada escritura y mutación de memoria se remonta a una identidad de llamada verificada y a un evento de origen. XMemo registra la atribución del llamador, las huellas de instancias de agentes y los metadatos de procedencia en registros de auditoría y conserva el historial de versiones (versiones superseded) con DAG de actualización (consulte /docs/concepts/agent-instance-identity y /docs/concepts/memory-model).
• Eliminación y exportación: Pregunte a cualquier proveedor cómo admite la plataforma el borrado lógico por lápidas, la redacción definitiva y la exportación masiva de datos. XMemo proporciona estados de ciclo de vida gobernados (active, archived, deleted), borrado lógico con restauración, redacción permanente de contenido y exportación JSON estructurada (consulte /docs/concepts/memory-deletion y /docs/api/memory).
• Integración de MCP y REST: Pregunte a cualquier proveedor si la capa de memoria ofrece compatibilidad nativa con Model Context Protocol (MCP) junto con extremos REST estándar. XMemo ofrece un servidor MCP Streamable HTTP nativo que expone un catálogo de herramientas estándar congelado junto con extremos REST autenticados en /v1/ (consulte /docs/mcp/overview y /docs/api/authentication).
• Límites de velocidad: Pregunte a cualquier proveedor cómo se aplican y comunican a los clientes los límites de concurrencia y procesamiento de solicitudes. XMemo aplica una limitación de velocidad en tiempo de ejecución gobernada por la capa api-authentication en lugar de cuotas estáticas publicadas, y los clientes no deben asumir cuotas fijas en el código (consulte /docs/api/authentication).
• Pruebas comparativas reproducibles: Pregunte a cualquier proveedor si las afirmaciones de precisión de recuperación y latencia son verificables de forma independiente con bancos de pruebas abiertos y conjuntos de datos deterministas. XMemo publica contratos de pruebas comparativas propiedad del repositorio con conjuntos de datos deterministas Golden Set (recall_golden_set.jsonl) y registros de ejecución inmutables, distinguiendo la evaluación en memoria del I/O de red (consulte /docs/guides/evaluate#reproducible-benchmark-methodology).
• Características sujetas a planes: Pregunte a cualquier proveedor qué procesos en segundo plano y funciones avanzadas se incluyen en el tiempo de ejecución base frente a los condicionados por niveles comerciales. XMemo incluye el almacenamiento básico de memoria, búsqueda, recuperación y la herramienta reflect con 5 acciones en el tiempo de ejecución base, mientras que la reflexión Dream programada en segundo plano depende de flags de características y del plan o derechos (ajustes predeterminados: manual, daily o weekly; consulte /docs/concepts/how-xmemo-works y /docs/concepts/dream-reflection).

{
  "evaluation_checklist": {
    "dimensions": [
      {
        "dimension": "Scope isolation",        "question": "How are user, session, agent, and workspace memories segregated?",        "xmemo_answer": "4-tier orthogonal scope hierarchy (user, session, agent, team/space) enforced at storage boundary (/docs/concepts/scopes)"      },
      {
        "dimension": "Attribution and provenance",        "question": "Can every memory mutation be traced to a specific caller and event?",        "xmemo_answer": "Caller attribution and agent instance fingerprints recorded in audit logs with version history (/docs/concepts/agent-instance-identity)"      },
      {
        "dimension": "Deletion and export",        "question": "Does the system support soft deletion, hard redaction, and data export?",        "xmemo_answer": "Tombstone soft-deletion with restoration, hard redaction, and structured export (/docs/concepts/memory-deletion)"      },
      {
        "dimension": "MCP and REST integration",        "question": "Is the memory layer accessible via native MCP as well as HTTP REST?",        "xmemo_answer": "Native Streamable HTTP MCP server with frozen tool catalog and authenticated REST endpoints (/docs/mcp/overview)"      },
      {
        "dimension": "Rate limits",        "question": "How are request quotas communicated and enforced?",        "xmemo_answer": "Runtime rate limiting governed by api-authentication without hard-coded client quotas (/docs/api/authentication)"      },
      {
        "dimension": "Reproducible benchmarks",        "question": "Are retrieval accuracy and performance metrics independently verifiable?",        "xmemo_answer": "Open repository-owned benchmark harness with deterministic golden set datasets and run traces (/docs/guides/evaluate#reproducible-benchmark-methodology)"      },
      {
        "dimension": "Plan-dependent features",        "question": "Which features are core runtime versus gated by tier entitlements?",        "xmemo_answer": "Core operations and 5-action reflect tool in base runtime; background Dream reflection is plan/entitlement-dependent (/docs/concepts/dream-reflection)"      }
    ]
  }
}

Guía de selección según escenarios

Evalúe la topología de su carga de trabajo, la estructura de su equipo y los requisitos de gobernanza para seleccionar el patrón de arquitectura de memoria adecuado.

• Flujos de trabajo multiagente en múltiples entornos: Elija una capa de memoria con soporte nativo de MCP, ámbitos de proyecto compartidos y sincronización entre clientes al orquestar agentes en Claude Code, Cursor, ChatGPT, Codex y Gemini CLI.
• Espacios de trabajo empresariales y regulados: Priorice arquitecturas que ofrezcan jerarquías de ámbitos ortogonales (user, session, agent, team/space), registros de auditoría con atribución de llamadas y límites de inquilinos forzados por hardware o servidor.
• Bucles autónomos de alta concurrencia: Seleccione arquitecturas con árboles de actualización versionados, bloqueo optimista y consistencia de lectura tras escritura (read-your-writes) para evitar actualizaciones conflictivas y alucinaciones por memoria obsoleta.

Metodología de pruebas comparativas reproducibles

XMemo proporciona un banco de pruebas abierto integrado en el repositorio para evaluar la precisión de recuperación y las restricciones de gobernanza bajo condiciones controladas. La arquitectura distingue estrictamente entre evaluación sintética interna, latencia de producción real y declaraciones públicas verificadas.

• Contrato metodológico: Las pruebas comparativas siguen un contrato de método congelado y reproducible con conjuntos de datos golden deterministas y trazas de verificación registradas.
• Pruebas sintéticas internas: Se ejecutan de manera hermética mediante scripts/benchmark_runner.py utilizando tests/data/recall_golden_set.jsonl (SHA-256 7533FBDC...) para medir la calidad algorítmica de recuperación en memoria y la lógica de clasificación sin I/O de red ni base de datos.
• Latencia de producción real: La latencia de extremo a extremo incluye negociación TLS, tránsito de red, transacciones de base de datos y sobrecarga de aislamiento multiinquilino. Varía según la topología de despliegue (SaaS en la nube vs. Docker autohospedado) y la distancia geográfica, y no está representada por cifras sintéticas en memoria.
• Declaraciones públicas de rendimiento: Todas las métricas informadas deben citar un benchmark_run_id inmutable y el informe de verificación sin procesar de las ejecuciones de verificación. Las afirmaciones comerciales no verificadas de proveedores y los atajos sintéticos quedan excluidos de las aserciones base.
• Análisis de modos de fallo: Se documentó un caso límite en el que entidades homónimas ('config.py' en dos proyectos distintos) compitieron en la clasificación al carecer de calificación explícita de ámbito; resuelto añadiendo restricciones de ámbito de proyecto.

# Execute reproducible retrieval benchmark against golden set
python scripts/benchmark_runner.py \
  --track standard \
  --dataset tests/data/recall_golden_set.jsonl \
  --cache-state COLD_CACHE \
  --output reports/custom_run_raw.json

Migración hacia XMemo

La transición desde sistemas clave-valor, almacenes exclusivamente vectoriales o servicios externos hacia XMemo sigue un proceso de cuatro fases.

• Fase 1: Exporte los elementos de memoria existentes en formato JSON Lines con text, user_id, session_id y marcas temporales created_at.
• Fase 2: Asigne los identificadores a la jerarquía de ámbitos de XMemo (user_id a owner, session_id a agent_instance_id o project_id, y categorice los hechos según su durabilidad).
• Fase 3: Ingiéralos mediante la herramienta por lotes remember o la API REST (/v1/memories) con los atributos de ámbito y procedencia adecuados.
• Fase 4: Valide la precisión de recuperación y los límites de aislamiento con recall_context antes de habilitar permisos de escritura para los agentes.

import requests

def migrate_legacy_record(legacy_item, api_key):
    payload = {
        "content": legacy_item["content"],
        "path": f"migration/{legacy_item.get('id', 'item')}",
        "scope": "project" if legacy_item.get("project_id") else "user",
        "metadata": {"source": "legacy_migration", "original_id": legacy_item.get("id")}
    }
    response = requests.post(
        "https://xmemo.dev/v1/memories",
        headers={"Authorization": f"Bearer {api_key}"},
        json=payload
    )
    response.raise_for_status()
    return response.json()

Limitaciones conocidas y fronteras operativas

Para evitar usos inadecuados, tenga en cuenta las fronteras de diseño y los límites operativos definidos para XMemo.

• No es una base de datos relacional general: XMemo está optimizado para hechos, estados y habilidades de agentes; no sustituye a la base de datos principal de su aplicación en transacciones SQL arbitrarias.
• No es un vertedero de archivos no estructurados: Los documentos de más de 32 KB deben indexarse en Bases de Conocimiento (Knowledge Bases) y no como nodos individuales en línea.
• Periodicidad de consolidación Dream: La superficie de API y herramienta MCP reflect no expone un programador; la programación en segundo plano de Dream depende de flags de características y del plan/derechos (ajustes: manual [por defecto], daily en la franja local 03:00 del propietario, o weekly), y la consolidación no es síncrona con las escrituras.
• Límites de peticiones: Los extremos alojados aplican límites de velocidad en tiempo de ejecución gobernados por api-authentication en lugar de cuotas estáticas publicadas; los clientes no deben fijar supuestos de cuotas en el código.