El modelo descentralizado de git y sus clones completos se diseñaron para flujos de trabajo humanos sin conexión: cada desarrollador tiene una copia del repositorio y calcula localmente el historial, las diferencias y el blame. A escala de agentes, esas características se convierten en costes: el historial completo dispara las necesidades de almacenamiento y transferencia, generar packfiles y mantener réplicas exige mucho trabajo de CI y operaciones, y los clones parciales dan lugar a casos límite frágiles en las consultas que dependen del historial. Cuando las fusiones llegan a decenas de miles al día, centralizar esas operaciones y ofrecerlas mediante API eficientes reduce el trabajo redundante y da soporte a consumidores programáticos, como los procesos de CI y los entornos aislados.

Scion adopta un modelo en el que el servidor es el centro: los conjuntos de cambios se crean en el servidor, los blobs son inmutables y están direccionados por contenido, y los clientes solicitan únicamente los árboles y blobs que necesitan. Un aspecto clave es que Scion separa los datos primarios, similares a los commits, de los índices derivados. El blame, el historial de rutas y la ascendencia se calculan mediante pipelines genéricos y recursivos de datos derivados, que pueden ejecutarse de forma anticipada o bajo demanda. Esta separación modular permite escalar el sistema horizontalmente —los servidores funcionan como grandes cachés que responden a solicitudes de objetos deterministas— y habilita nuevos flujos programáticos que evitan materializar copias de trabajo.

Centralizar las operaciones introduce otros modos de fallo: interrupciones de las cachés regionales, amplificación de lecturas durante el calentamiento y necesidad de controles IAM y auditorías sólidos en el nivel de la API. Anthropic mitigó estos riesgos mediante una segmentación estricta por niveles, objetivos elevados de aciertos de caché y un modelo de control de acceso completo. También cambian la seguridad y el cumplimiento: las políticas deben aplicarse en el servidor, la revisión adversarial debe ser programática y la observabilidad debe mostrar la intención de los agentes y la procedencia de las revisiones. Para mantener la confianza a escala, los equipos deben invertir en controles automatizados de políticas, simulaciones herméticas del comportamiento de los agentes y registros robustos.

Adoptar un sistema de control de versiones a escala de agentes implica replantear las revisiones, la propiedad del código y CI. Los flujos de revisión deberían validar la intención y las invariantes, en lugar de inspeccionar cada línea; los ingenieros pasarán de leer todos los cambios a auditar la intención y los casos límite. CI y los pipelines de lanzamiento deberían priorizar las comprobaciones mediante API y la materialización selectiva para evitar clones costosos. En el plano operativo, los equipos necesitarán nuevos perfiles: responsables de cachés e índices, especialistas en políticas del servidor y responsables de fiabilidad de los pipelines de datos derivados. También serán esenciales la formación y las guías de actuación que definan los límites de los agentes y sus modos de fallo.

Empieza con un enfoque híbrido: incorpora API de metadatos y servicios de datos derivados en el servidor, pero conserva git para los flujos de trabajo de cada desarrollador. Prueba entornos aislados para agentes que utilicen copias dispersas y valida la exactitud de los datos derivados. Invierte pronto en la topología de caché y el aislamiento regional, y crea interfaces de revisión automatizadas y sencillas para controlar las acciones de los agentes. Por último, ajusta las políticas y la experiencia de desarrollo —con árboles de trabajo materializados o copias virtualizadas— para que las personas sigan trabajando con eficiencia mientras los agentes escalan. Usa como métricas principales la latencia de las fusiones, la tasa de aciertos de caché y el cumplimiento de las políticas.