Cómo revisar lo que cambian los agentes de IA en tus notas

Cuando dejas que un agente de IA trabaje en tus notas, necesitas una forma de comprobar sus cambios antes de depender de ellos. Un agente de código es rápido y escribe con soltura, y ahí está el problema: una frase errónea se lee exactamente igual que una correcta. En el código, cuando un agente se equivoca, a menudo falla un test. En una base de conocimiento no falla nada. La fecha equivocada simplemente se queda ahí.

Hay cosas que salen mal una y otra vez:

• Reescrituras silenciosas. Pides una nota nueva y el agente, de paso, “ordena” tres antiguas y cambia el sentido de una frase que escribiste con cuidado.
• Ediciones sobrescritas. Ayer corregiste una cifra a mano. Hoy el agente reescribe la nota a partir de una fuente más antigua y tu corrección desaparece.
• Errores que se propagan. La siguiente sesión lee el dato erróneo como contexto, lo repite en dos notas más y ahora parece confirmado.
• Ningún registro. Un mes después no sabes qué notas escribiste tú, cuáles escribió un agente y cuáles revisó alguien alguna vez.

La solución tiene dos partes: ver cada cambio antes de que se quede y anotar quién revisó qué. Esta guía explica cómo hacer las dos cosas a mano con git y unos cuantos campos de frontmatter y, después de cada paso, cómo lo resuelve Knowtarium. Hacemos Knowtarium para esto: allí, los cambios de los agentes van firmados y se pueden deshacer por defecto, y la revisión antes de que un cambio se quede es un interruptor que activas por carpeta.

Git es la mejor herramienta gratuita para esto. Si tus notas son una carpeta de archivos markdown, ponlas bajo git y haz commit antes de cada sesión con un agente. Así, todo lo que haga el agente es un diff que puedes leer, conservar en parte o descartar.

# una sola vez, en tu carpeta de notas
$ git init$ git add -A && git commit -m "Notes before agents"
 
# antes de cada sesión con un agente: un punto de partida limpio en su propia rama
$ git switch -c agent/2026-09-26-cleanup

Trabajar en una rama mantiene limpio tu historial principal: si toda la sesión fue un error, vuelves atrás y borras la rama. Cuando el agente termine, lee lo que ha cambiado:

# qué archivos han cambiado, y cuánto
$ git status$ git diff --stat
 
# lee los cambios palabra por palabra, que va mejor con la prosa que las líneas enteras
$ git diff --word-diff
 
# quédate con los bloques con los que estés de acuerdo (y = guardar, n = saltar, s = dividir, e = editar)
$ git add -p$ git commit -m "Keep claude-code edits to pricing notes"
 
# descarta todo lo que no hayas guardado
$ git restore .
 
# de vuelta en main, incorpora lo que has aprobado
$ git switch main$ git merge agent/2026-09-26-cleanup

git add -p es lo que convierte esto en una revisión de verdad. Te muestra cada bloque cambiado y te deja añadirlo o saltarlo, así que puedes quedarte con la nota nueva y descartar la reescritura no pedida de una antigua. Pulsa s para dividir un bloque grande en otros más pequeños y e para editar uno a mano.

Pon el nombre del agente en el mensaje del commit. Así, git log te dice qué sesión escribió qué, y git log -p -- path/to/note.md muestra el historial completo de una sola nota.

En Knowtarium

En Knowtarium, cada cambio de un agente se guarda como una versión nueva firmada con la propia clave del agente, así que el historial de la nota lista cada versión con quién la hizo y cuándo, See changes muestra la edición del agente como un diff y Undo recupera la versión anterior. En las carpetas que quieras leer antes, activa la revisión (“Ask me first”): los cambios de los agentes ahí esperan como diffs hasta que los apruebas, o los rechazas con un comentario.

(se abre a tamaño completo en una pestaña nueva) (se abre a tamaño completo en una pestaña nueva)

Si usas Claude Code, tiene tres funciones que ayudan. Ninguna sustituye a git, pero detectan los problemas antes.

Modos de permisos

Un modo de permisos decide qué puede hacer Claude sin preguntar. En el modo Manual (valor de configuración default) pregunta antes de editar archivos. acceptEdits le deja editar sin preguntar, algo que Anthropic sugiere cuando prefieres revisar después con git diff. El modo plan hace que Claude investigue y proponga cambios sin aplicarlos hasta que apruebes el plan. Pulsa Shift+Tab para cambiar de modo durante una sesión. Las versiones recientes inician las sesiones interactivas en modo auto, en el que un clasificador revisa las acciones en tu lugar, así que cambia al modo Manual o al modo plan en las sesiones que toquen notas que te importan.

Checkpoints

Claude Code guarda un checkpoint antes de cada prompt que envías. Ejecuta /rewind, o pulsa Esc dos veces con el prompt vacío, para restaurar los archivos, la conversación o ambos. Conoce sus límites: los checkpoints no siguen los archivos cambiados con comandos de shell como mv o rm, normalmente no restauran las ediciones hechas por subagentes y se borran al cabo de unos 30 días por defecto. La documentación de Anthropic dice claramente que los checkpoints no sustituyen al control de versiones.

Reglas de permisos

Las reglas de .claude/settings.json bloquean las ediciones en carpetas concretas o las someten a permiso. Las reglas de denegación se imponen a todo lo demás y se aplican en todos los modos:

{
  "permissions": {
    "ask": ["Edit(/decisions/**)"],
    "deny": ["Edit(/journal/**)", "Edit(/people/**)"]
  }
}

Aquí Claude nunca puede editar journal/ ni people/, y tiene que preguntar antes de tocar decisions/. Las reglas Edit cubren las herramientas de archivos integradas de Claude y los comandos de archivos que reconoce en la shell, pero no un script que abra archivos por su cuenta. Para una garantía absoluta, Anthropic remite a su sandbox.

La mayoría de los agentes leen un archivo de instrucciones antes de empezar: AGENTS.md en Codex, Cursor y muchos otros, CLAUDE.md en Claude Code. Pon ahí tus reglas de edición. Que sean breves y lo bastante concretas como para poder comprobarlas:

## Cambios en los documentos
 
- Nunca borres un documento. Pon `status: deprecated` y explica por qué.
- Nunca edites archivos de journal/ ni de people/.
- No reescribas un párrafo que no te hayan pedido cambiar.
- Firma en `generated` cada documento que escribas, con tu nombre y tu versión.
- Nunca añadas una entrada `human:` a `verified`. Eso solo lo hace una persona.
- Termina la sesión con una lista de todos los archivos que has creado, cambiado o movido.

La última regla es la útil para revisar: una lista de todos los archivos tocados, que puedes comparar con git status. Si no coinciden, mira más de cerca.

Las instrucciones son contexto, no un candado. La documentación de Anthropic describe CLAUDE.md como algo que Claude lee, no como una configuración que haga cumplir, y por eso existen las reglas de permisos de arriba. Nuestra guía sobre AGENTS.md y CLAUDE.md para una base de conocimiento tiene una plantilla completa.

En macOS y Linux también puedes hacer que una carpeta sea de solo lectura con chmod -R a-w journal/. Tómalo como un badén: un agente que puede ejecutar comandos de shell puede volver a cambiar los permisos.

Un diff te dice qué ha cambiado hoy. No le dice a quien lea la nota el mes que viene si alguien la revisó. Para eso, escríbelo en la propia nota. El Open Knowledge Format (OKF), una especificación abierta publicada por Google Cloud, tiene campos justo para esto:

---
type: Decision
title: Pasar la facturación a planes anuales
generated: { by: claude-code/2.1, at: 2026-09-26T09:12:00Z }
verified:
  - { by: human:maya, at: 2026-09-26T11:40:00Z }
stale_after: 2027-03-31T00:00:00Z
---

• generated dice quién escribió el contenido actual y cuándo. Los agentes firman como name/version, las personas como human:name.
• verified enumera a todos los que lo han revisado desde entonces, con la hora. Un documento sin ninguna entrada es unverified, uno revisado solo por agentes o procesos es machine-confirmed, y uno revisado por un actor human: es human-reviewed.
• stale_after es el momento a partir del cual el documento deja de ser seguro para citarlo.

La rutina es sencilla. El agente escribe y firma generated, nunca verified. Tú revisas el diff y luego añades tu propia entrada en verified. Con eso en marcha, encontrar lo que nadie ha revisado es un solo comando:

# documentos que nadie ha revisado todavía: sin ninguna línea verified
$ grep -rL "^verified:" --include="*.md" .

1. Haz commit y luego crea una rama para la sesión.
2. Inicia el agente en modo Manual o en modo plan, con reglas de denegación para las carpetas que nunca debe tocar.
3. Dale una sola tarea. Pídele al final una lista de los archivos tocados.
4. Compara esa lista con git status y luego lee git diff --word-diff.
5. Quédate con lo que te parezca bien usando git add -p y restaura el resto.
6. Añade tu entrada verified a cada nota que hayas revisado, haz commit con el nombre del agente en el mensaje y fusiona.

Cada herramienta detecta algo distinto:

Para unas pocas docenas de notas y un solo agente, git y esta rutina pueden bastar. Se vuelve tedioso cuando los agentes escriben a diario, cuando un cambio toca diez notas o cuando tu propia edición deja mal otras cinco notas sin que te des cuenta. Para eso está hecho Knowtarium: cada cambio de un agente va firmado y se deshace con un clic, y donde activas la revisión, los cambios de los agentes te esperan y tus propias ediciones esperan hasta que pides a un agente que las revise.

Knowtarium integra la rutina anterior en una base de conocimiento cifrada de extremo a extremo. Tus agentes se conectan por MCP y trabajan sobre los mismos documentos OKF, y la app te muestra lo que han hecho y lo que todavía necesita una mirada. La revisión tiene dos niveles: deshacer cualquier cambio, por defecto, y aprobar antes, donde tú lo pidas.

Cada cambio firmado y reversible

Por defecto, el cambio de un agente se guarda al instante como la siguiente versión del documento, firmado con la propia clave del agente. Un punto en la barra lateral marca los documentos que ha editado hasta que los abres, una línea bajo el título dice qué agente fue y cuándo, con un enlace a los cambios y un Undo, y la página del espacio de trabajo lista lo que han editado los agentes en los últimos 14 días. Undo recupera la versión anterior como un cambio tuyo, y el historial guarda cada versión para restaurarla durante el tiempo que configures (30 días al principio, hasta un año).

Ask me first: diffs y luego aprobar

Activa la revisión en un espacio de trabajo o una carpeta, y los cambios de los agentes ahí quedarán como propuestas. Abre una y verás el diff con el resumen del propio agente y quién lo propuso. Apruébalo, recházalo con un comentario o aprueba varios a la vez. Al aprobar, te añades a verified con la hora, que es la entrada human: que de otro modo escribirías a mano. La propuesta del agente ya lleva su propia revisión, así que, en cuanto la apruebas, la nota queda totalmente verificada.

(se abre a tamaño completo en una pestaña nueva) (se abre a tamaño completo en una pestaña nueva)

En esas carpetas, una sola cola reúne todo lo que espera una revisión:

• los cambios que ha propuesto un agente, a la espera de que los revises;
• las ediciones que has hecho tú, a la espera de que un agente las revise;
• los conflictos que ha encontrado un agente al revisar.

Los documentos que han pasado su fecha stale_after, y los que vencen pronto, aparecen en la página Stale and expiring, estén donde estén.

Revisiones en los dos sentidos

En las carpetas con revisión activada, la revisión también funciona al revés. Cuando editas tú un documento, la edición queda firmada como tuya y espera en la cola hasta que un agente la compara con todos los documentos relacionados. Knowtarium no llama a ninguna IA por sí mismo: le pides a tu agente que revise las ediciones de hoy, y él registra su revisión o señala un conflicto allí donde algo ya no cuadre.

Niveles de confianza

En las carpetas con revisión activada, cada documento tiene un nivel de confianza:

Las mismas reglas valen para todos los agentes: no pueden marcar nada como revisado por una persona, solo borran un documento si les diste ese permiso y, en las carpetas con revisión activada, no pueden saltarse tu revisión. Tus documentos están cifrados de extremo a extremo, así que nosotros no podemos leerlos; los agentes que conectes ven lo que leen. Consulta las funciones y cómo se conectan los agentes.