--- title: "Auditoría de recuperación" description: "La sección Agents → Audit: qué buscó y abrió un agente, si encontró algo y dónde están sus puntos ciegos — consultas que no devuelven nada." --- # Auditoría de recuperación El constructor de contexto decide qué se carga en un agente al inicio. La auditoría es su contraparte durante el trabajo en sí: muestra qué busca realmente el agente (`search` / `recall`) y qué abre (`get_note`), y si encontró algo. Esto importa porque el modo de fallo dominante de la memoria no es «el dato no existe», sino un fallo de recuperación: la nota que necesitas sí existe, pero la consulta nunca llega a ella. Sin observabilidad, cuidar la memoria se vuelve pura adivinación. La sección vive en **Agents → Audit**. ## Qué entra en el registro Cada llamada a una herramienta de lectura (`search`, `recall`, `get_note`) añade una línea al registro: qué se buscó (consulta, alcance, clase) y qué se encontró (los mejores resultados con `noteId`, `title`, `score`, `class`, más el número de resultados). La captura ocurre en segundo plano — no afecta ni a la latencia ni a la corrección de la respuesta que recibe el agente. Las herramientas de escritura (`create_note`, `remember_*`, `edit_note`) **no se registran** en la auditoría de recuperación — su procedencia vive en el [registro de revisiones](/docs/concepts/versioning/). La auditoría trata de la lectura. Cada línea recuerda también el **nombre del agente** — el nombre amigable del token o de la aplicación (por ejemplo, una CLI o Claude), capturado mientras el token está vivo. Así la línea recuerda para siempre qué agente hizo la consulta. ## Puntos ciegos La señal principal de la auditoría son las **consultas recurrentes que no devuelven nada**. Una búsqueda vacía aislada es normal (el agente puso a prueba una hipótesis). Pero una consulta que **una y otra vez** no encuentra nada es un punto ciego: el agente necesita un dato que no está en la memoria, o uno archivado bajo un título desafortunado. Es una indicación directa de qué añadir o cómo reformular. La interfaz condensa esto en dos paneles: - **Blind spots** — consultas vacías recurrentes (umbral: dos o más sin resultado), resaltadas en amarillo/ámbar. - **Frequent** — las consultas más frecuentes. Más un feed de historial (lo más reciente arriba) con un filtro por herramienta (All / Search / Recall / Open): el icono de la herramienta, la consulta en sí, el nombre del agente, la etiqueta de clase/categoría, el proyecto (solo cuando se aplica un alcance), el número de resultados y la hora. Al expandir una línea se revelan los resultados que encontró — son clicables y llevan directo a las notas. > [!note] Resultados vacíos > La auditoría detecta de forma fiable justo el caso del resultado vacío. El caso de «existe algo relevante pero no llegó a los mejores resultados» requiere ejecutar la consulta contra la memoria — esa es una señal aparte, más sutil, que la auditoría no expone. ## Privacidad y alcance El registro es visible solo para el propietario: ves la recuperación de tus propios agentes, ligada a tu nombre de usuario. Como quien mira es el propietario, el nombre de tu agente se muestra sin ocultar. La auditoría abarca todos tus espacios a la vez — una línea no tiene un único espacio de origen. > [!info] Cuándo no se registra la recuperación > La auditoría se guarda en la base de datos de metadatos. Un host sin base de datos de metadatos (por ejemplo, el modo `none` sin base de datos) no registra la recuperación — la sección simplemente queda vacía, sin error. ## Siguiente - [Conjuntos de contexto y pins](/docs/agents/context-pins/) — qué se carga de entrada; la auditoría muestra qué se trae bajo demanda. - [Memoria del agente](/docs/agents/memory/) — qué buscan exactamente `search` y `recall`. - [Seguridad y visibilidad](/docs/agents/security/) — por qué los registros de lectura son visibles solo para el propietario.