Anthropic usa BM25 para herramientas pero solo directorios para la memoria de agentes
Mientras el catálogo de herramientas tiene búsqueda semántica, el endpoint de memoria en beta obliga a los desarrolladores a diseñar la recuperación basándose en la jerarquía de carpetas.
Anthropic maneja el problema del desbordamiento de contexto de forma distinta según el recurso que toque el agente. Para el catálogo de herramientas, ofrece búsqueda indexada; para la memoria, entrega una lista plana similar a un comando ls de terminal. Es una diferencia de arquitectura que redefine cómo deben estructurar los datos quienes desplieguen agentes en su plataforma.
El catálogo de herramientas sufre cuando las definiciones exceden el límite de contexto. Para evitarlo, la plataforma integra herramientas de búsqueda basadas en regex y BM25, además de permitir implementaciones personalizadas con embeddings. El endpoint tool_search_tool_bm25 permite al modelo lanzar consultas en lenguaje natural. La API devuelve un máximo de cinco resultados por defecto, ajustables. El modelo nunca carga todo el catálogo de golpe; opera sobre la lista corta que la API le devuelve tras filtrar por relevancia. La recomendación oficial es clara: los nombres y descripciones de las herramientas son el índice. Un naming consistente y un namespace lógico determinan si el agente encuentra lo que busca.
La memoria guarda otro comportamiento. El endpoint List memories no incluye parámetros de búsqueda ni consulta semántica. Solo acepta depth, limit, page, path_prefix y view. La documentación compara explícitamente depth=1 con el comando ls y la omisión de profundidad con find. El orden de retorno es estable y definido por el servidor, pero no por relevancia. La lógica de recuperación recae enteramente en cómo se organizan las rutas. Si los desarrolladores no estructuran bien los prefijos y la profundidad, el agente no distinguirá lo útil del ruido.
La guía de buenas prácticas sugiere fragmentar los almacenes por usuario, dominio o proyecto, pero dentro de cada uno, la jerarquía de carpetas es el único mecanismo de filtro. No hay instrucciones sobre cómo nombrar las rutas para optimizar la recuperación, a diferencia de la documentación de herramientas. Esto convierte al desarrollador en arquitecto de la indexación: la estructura de directorios es la estrategia de búsqueda.
Hay un matiz técnico importante. Esta falta de búsqueda semántica afecta al endpoint HTTP de la API. Cuando un almacén de memoria se monta en el sandbox del agente bajo /mnt/memory/, el agente interactúa con él como con archivos estándar mediante herramientas de sistema de archivos. Allí, la ausencia de un endpoint search en la API no impide que el agente lea y escriba directamente en los archivos.
El endpoint sigue marcado como Beta, bajo el encabezado anthropic-beta: agent-memory-2026-07-22. La diferencia no implica que un enfoque sea superior al otro de forma inherente, sino que expone una decisión de diseño: para herramientas, la plataforma gestiona la relevancia; para memoria, delega la organización en el cliente. La pregunta abierta es si esta delegación simplifica la latencia o añade fricción en flujos de trabajo complejos. La evidencia actual solo describe la interfaz, no mide el rendimiento comparado.
Implicaciones para el desarrollo
Quien implemente agentes que dependan de memoria a largo plazo debe asumir que la recuperación no será automática por significado. El diseño de nombres de directorios y la segmentación de almacenes se convierten en una parte crítica del desarrollo, no en una configuración opcional. Si el agente necesita encontrar una memoria específica entre miles, la estructura del path path_prefix debe ser tan precisa como la descripción de una herramienta para BM25.
