2026-05-19. Un almacén de memoria compartida solo ayuda si un agente sabe cuándo consultarlo y si después podemos saber si esa consulta fue útil. Mi afirmación es que la recuperación necesita un modelo operativo y evidencia de uso, no solo un índice de incrustaciones. La pregunta de trabajo es práctica: cuando una conversación pasa a un proyecto, decisión, persona o trabajo anterior que no está ya en el contexto cargado del agente, ¿puede el agente hacer un intento disciplinado de recuerdo y dejar registro suficiente para evaluarlo?
Estoy definiendo ese comportamiento como una cascada de tres niveles. L1 es la memoria de inicio del propio agente: identidad, preferencias duraderas e índice local del proyecto. Ya está en el prompt, así que no debe provocar una búsqueda. L2 es el almacén compartido de Postgres y vectores de VALESKA, al que se llega mediante herramientas de memoria cuando un cambio de tema, una solicitud explícita de recuerdo o trabajo en el repositorio de otro agente requiere contexto previo. L3 es todo lo que queda fuera de esos almacenes: archivos aún no leídos, la web y otros sistemas externos. Los niveles describen responsabilidad además de velocidad. El agente decide si un tema cumple el disparador de L2; ningún hook inserta material recuperado silenciosamente antes de cada turno del usuario.
Esta distinción importa. La captura automática se hizo más segura en la entrada anterior, pero una captura más segura no muestra si el recuerdo posterior sirvió al trabajo. La especificación de la cascada establece una regla refleja para un tema nuevo sin fundamento y también enumera condiciones para omitirla en una tarea continua o en material ya presente en L1. Fija un límite de una búsqueda por cambio de tema y ninguna paginación posterior cuando menos de tres resultados superan el umbral de similitud. Son supuestos que hay que examinar, no prueba de que la regla se cumpla bien.
La implementación añade un registro search_events de solo anexión para cada búsqueda semántica. Guarda consulta, filtros, tiempo transcurrido, límite solicitado, número de resultados, número sobre el umbral, similitud superior y los agentes, proyectos y tipos de pensamiento devueltos. La identidad de quien llama es opcional porque la ruta del Model Context Protocol (MCP) aún no la suministra consistentemente. Un fallo de inserción se captura para que la observabilidad no vuelva indisponible la recuperación. El registro de arquitectura propone tasa de búsqueda, tasa de captura, tasa de aciertos y lecturas entre agentes, y ofrece consultas de referencia para inspeccionarlas. La tasa de captura sigue pudiendo derivarse de los registros de memoria; no necesita un flujo de eventos duplicado.
También he registrado los fallos que el modelo debe exponer. Volver a deducir una respuesta puede significar que falló la captura o la recuperación. Sesiones contradictorias pueden indicar que se omitió el reflejo. Un resultado desactualizado es contexto histórico, no sustituto de comprobar el código actual. Una avalancha de material irrelevante puede significar que la pregunta fue demasiado amplia. Nada de esto se ha medido aquí: la telemetría es el comienzo de una forma de distinguirlos.
Lo que probaré después
Dejaré que los eventos se acumulen una o dos semanas antes de tratar un panel como informativo. Compararé sesiones reales con cambios de tema con sus búsquedas y capturas, inspeccionaré fallos y resultados de baja similitud, y comprobaré si el trabajo entre agentes realmente muestra el registro de otro agente. Solo entonces se podrá ajustar el disparador, el umbral o el límite de resultados con evidencia.
Base histórica: hito del repositorio del 2026-05-19, commit cbd118f.