En el vertiginoso mundo de la inteligencia artificial, los desarrolladores de sistemas autónomos se enfrentan a un reto significativo: el comportamiento no determinista de los agentes, que frecuentemente carece de un rastro causal clarificador. La complicación no se origina ni en el modelo ni en la solicitud original, sino en el estado que el agente interpreta y altera. Estos agentes ejecutan flujos de trabajo a través de múltiples etapas, invocando herramientas externas y actualizando objetos compartidos de forma continua. Sin la existencia de mecanismos que permitan el aislamiento de instantáneas y lecturas con conciencia de versión, la percepción del mundo de un agente puede alterarse durante su operación.
Los errores aparentemente menores, como las inconsistencias, lecturas desactualizadas, escrituras parciales y actualizaciones intercaladas, pueden confluir para generar decisiones que resulta imposible replicar. El problema real no radica en la orquestación, sino más bien en los sistemas de almacenamiento de objetos, tradicionalmente concebidos para artefactos estáticos y no para procesos autónomos y concurrentes. En este contexto, Tigris emerge con una solución innovadora, ofreciendo «instantáneas de cubos completos» y el concepto de «forking» de cubos, funciones que los depósitos convencionales como S3 no poseen.
A medida que los equipos amplían el uso de agentes paralelos, los conflictos de escritura, la contaminación entre ejecuciones y los estados irreproducibles se convierten en cuestiones inevitables. Aunque estos problemas parecen manifestarse como fallos en los flujos de trabajo o en la modelización, la auténtica raíz del problema es la carencia de una semántica de versión de datos adecuada. El almacenamiento de objetos ha sido la opción predilecta para mantener el estado de los agentes, especialmente al manejar datos no estructurados y en continua evolución. Sin embargo, no proporciona lecturas consistentes, orden causal ni aislamiento por agente, lo que puede ocasionar que dos agentes que actualizan el mismo cubo terminen sobrescribiéndose mutuamente.
El enfoque de Tigris no se centra en mejorar el rendimiento ni en superponer otra capa a los sistemas de almacenamiento de objetos existentes. En su lugar, aborda un rediseño fundamental de las semánticas de datos para sistemas autónomos, haciendo hincapié en la inmutabilidad como elección arquitectónica esencial. En el entorno de Tigris, cada escritura genera una nueva versión inmutable, las eliminaciones se traducen en «tumbas» y no en mutaciones destructivas, y el sistema mantiene un registro global ordenado de cambios de estado. Esto garantiza un rastreo de linaje preciso, lecturas deterministas y vistas históricas reproducibles, ventajas que los almacenes de objetos tradicionales no pueden ofrecer.
La implementación del «bucket forking» por Tigris permite flujos de trabajo para datos no estructurados similares a Git. Un fork se crea en milisegundos, hereda una instantánea exacta del cubo original y proporciona un espacio de escritura aislado, permitiendo que los agentes o los flujos de trabajo se desvíen segura y autónomamente, sin afectar al conjunto de datos original. Esto facilita la experimentación segura con nuevos comportamientos de agentes, estrategias de resumen o transformación de datos, y las labores de depuración o reproducción de ejecuciones pasadas.
Con el creciente uso de sistemas autónomos en flujos de trabajo de producción, se plantea una imperiosa necesidad de garantías en la capa de datos. Los equipos requieren de mecanismos como el forking, las instantáneas y el estado versionado para prevenir que errores en el estado compartido conduzcan a resultados erróneos, incluso cuando la lógica del agente es correcta. La forma en que estos sistemas tratan los datos debe evolucionar, al igual que lo ha hecho con el código, para asegurar el mismo nivel de control y semántica.
La introducción de almacenamiento inmutable, instantáneas y el forking de cubos como primitivos fundamentales constituye un avance crucial para proporcionar la base de datos necesaria para los sistemas autónomos. Es posible que muchos equipos no reconozcan de inmediato esta necesidad, pero seguramente lo harán a medida que sus agentes comiencen a comportarse de formas impredecibles o difíciles de explicar.
