Per què els agents d'IA necessiten revisions i rollback
Quan un agent pot modificar dades reals, guardar només l'estat final és massa poc. Les revisions i el rollback converteixen errors difícils d'explicar en canvis observables i recuperables.
Quan un agent pot modificar dades reals, guardar només l'estat final és massa poc. Les revisions i el rollback converteixen errors difícils d'explicar en canvis observables i recuperables.
Si un agent modifica contingut, configuració o dades de negoci, el sistema hauria de poder respondre tres preguntes: què ha canviat, respecte a quin estat i com tornem enrere.
Quan cada escriptura substitueix l'anterior, desapareix la història del canvi. Això complica diferenciar un error del model, una instrucció incorrecta o una modificació humana posterior.
En lloc d'editar un registre en calent, cada canvi crea una nova versió que referencia la seva base. L'estat anterior continua existint i es pot inspeccionar, comparar o recuperar.
Si l'agent va llegir la revisió 10 i mentrestant existeix la 11, una escriptura basada en la 10 s'hauria de rebutjar. Aquest patró és una forma d'optimistic locking i evita que el model esborri canvis que no ha vist.
Preferiria implementar el rollback creant una nova revisió que copia l'estat d'una versió anterior. Així, la recuperació també queda auditada i la història continua sent lineal.
Un agent pot generar revisions sense que aquestes arribin immediatament a producció. Separar draft, revisió aprovada i publicació permet automatitzar molt sense convertir qualsevol tool call en un canvi públic.
No perquè totes les dades hagin de viure en Git, sinó perquè els principis són útils: historial immutable, base coneguda, diff, autoria i recuperació. Els agents funcionen millor quan el sistema no depèn que recordin perfectament l'estat anterior.
La pregunta no és si l'agent s'equivocarà, sinó quin cost tindrà quan ho faci. Revisions, optimistic locking i rollback redueixen aquest cost i fan que l'automatització sigui molt més observable.