En el ámbito de la inteligencia artificial, los desarrolladores de sistemas autónomos se enfrentan a un problema recurrente: el comportamiento incontrolado de los agentes, que a menudo carece de un rastro causal definido. El origen de este problema no reside en el modelo ni en la solicitud inicial, sino en el estado que los agentes interpretan y modifican. Estos agentes realizan flujos de trabajo de múltiples pasos, invocan herramientas externas y actualizan continuamente objetos compartidos. Sin mecanismos de aislamiento para instantáneas y lecturas que consideren la versión de los datos, la percepción del mundo por parte del agente puede cambiar durante su ejecución.
Estas pequeñas inconsistencias, lecturas obsoletas, escrituras parciales y actualizaciones intercaladas pueden combinarse para generar decisiones irreproducibles. El fallo real no está en la orquestación, sino en los sistemas de almacenamiento de objetos diseñados para artefactos estáticos, y no para procesos autónomos concurrentes. Este es el vacío que Tigris busca llenar mediante la implementación de «instantáneas de cubos completos» y el concepto de «forking» de cubos, capacidades ausentes en los almacenes de objetos tradicionales como S3.
A medida que los desarrolladores escalan agentes paralelos, inevitablemente se enfrentan a conflictos de escritura, contaminación entre ejecuciones y estados irreproducibles. Aunque estos problemas se manifiestan como fallas en el flujo de trabajo o en la modelización, la causa raíz es la falta de semánticas de versión de datos. El almacenamiento de objetos se ha convertido en la opción predeterminada para el estado de los agentes, especialmente en lo que respecta a datos no estructurados y en rápida evolución. Sin embargo, no ofrece lecturas consistentes, orden causal ni aislamiento por agente, lo que puede llevar a que dos agentes actualizando el mismo cubo sobrescriban el trabajo del otro.
Tigris no se centra en el rendimiento ni en añadir otra capa sobre el almacenamiento de objetos, sino en un rediseño fundamental de las semánticas de datos para sistemas autónomos, resaltando la inmutabilidad como elección arquitectónica clave. En Tigris, cada escritura genera una nueva versión inmutable, las eliminaciones crean «tumbas» en lugar de mutaciones destructivas, y el sistema mantiene un registro global ordenado de los cambios de estado. Esto asegura un rastreo preciso de linaje, lecturas deterministas y vistas históricas reproducibles, capacidades que los almacenes de objetos tradicionales no pueden proporcionar.
La implementación de «bucket forking» ofrece flujos de trabajo similares a Git para datos no estructurados. Un fork se crea en milisegundos, hereda una instantánea exacta del cubo padre y proporciona un espacio de escritura aislado para agentes o flujos de trabajo, divergiendo de manera segura sin afectar el conjunto de datos original. Esto permite la experimentación segura en nuevos comportamientos de agentes, estrategias para resumir o transformar datos, así como la depuración o reproducción de ejecuciones pasadas.
El aumento de los sistemas autónomos en los flujos de trabajo de producción demanda urgentemente garantías en la capa de datos. Los equipos necesitan mecanismos como el forking, las instantáneas y el estado versionado para evitar que errores en el estado compartido conduzcan a resultados inconsistentes, incluso si la lógica del agente es correcta. La manera en que se manejan los datos debe evolucionar, al igual que se hace con el código, para garantizar el mismo nivel de control y semántica.
La introducción de almacenamiento inmutable, instantáneas y el forking de cubos como primitivos fundamentales es un paso crítico para proporcionar la base de datos que los sistemas autónomos han estado necesitando. Aunque muchos equipos no perciban inmediatamente esta necesidad, seguramente lo harán cuando sus agentes comiencen a comportarse de maneras impredecibles o difíciles de explicar.