GitLab Orbit: un grafo de contexto para tus agentes

El grafo de contexto de GitLab, ya disponible

Un agente de código suele ver el código y poco más. No ve la merge request que lo cambió por última vez, ni el pipeline que lo ejecutó, ni la vulnerabilidad que arrastra, ni quién lo mantiene. El 29 de octubre GitLab anunció la disponibilidad general de GitLab Orbit, un grafo de contexto que intenta darle todo eso de una vez, y me parece un buen ejemplo de hacia dónde van las herramientas para agentes.

Antes de seguir, una aclaración: no lo he probado. Todo lo que cuento sale del anuncio de GitLab, y las cifras de rendimiento son del propio fabricante.

Qué es Orbit

Según GitLab, Orbit es una vista consultable de tu código, merge requests, tareas, pipelines, vulnerabilidades y responsables, con las relaciones actualizadas con cada push, merge y despliegue. Usa los datos que ya tienes en GitLab, así que no hay conectores ni ETL que mantener, y respeta los permisos de grupos y roles que ya tengas.

Los agentes de GitLab Duo lo consultan de forma nativa. Claude Code, Codex, Cursor, OpenCode, Gemini CLI, Antigravity y cualquier agente compatible con MCP se conectan por MCP o con la CLI de GitLab, y para herramientas propias hay una API REST. La idea es que todos los agentes pregunten al mismo grafo en vez de rastrear ficheros cada uno por su lado.

Los números, con su contexto

GitLab dice que, en sus pruebas, los agentes conectados a Orbit necesitaron hasta 45 veces menos reintentos y usaron hasta 4,5 veces menos tokens en las mismas tareas con el mismo modelo. El anuncio no detalla qué tareas ni qué repositorios, y “hasta” no es “de media”, así que lo leo como una pista y no como una promesa.

El caso más concreto es el de Compare the Market, una plataforma británica de comparación de precios. Probó cuatro formas de dar contexto a un revisor de código con IA sobre 79 merge requests reales. Según GitLab, el revisor apoyado en Orbit coincidió con cerca del 70% de los comentarios esperados y la versión con RAG, con un 58%, algo peor que no añadir contexto. Es un solo caso, contado por el proveedor, pero la comparación está bien planteada.

Lo que me quedo

• El problema es el contexto, no solo el modelo. GitLab dice que la limitación no es el modelo sino el contexto, y yo lo comparto en parte. Es lo que veo cuando un agente falla: casi nunca le falta inteligencia, le falta saber qué hay alrededor de lo que toca.
• Pregunta antes de tocar. Las consultas del anuncio son las que haría un buen ingeniero antes de un cambio: qué se rompe si toco esto, qué depende de lo que voy a migrar, por qué falla este job y en qué otros proyectos.
• El contexto compartido encaja con SDD. En Spec-Driven Development ya dejo en el repositorio specs, reglas y documentación para que el agente no adivine. Orbit hace algo parecido con el ciclo de vida. Lo que ya cuento en guardrails para agentes de código y en seguridad de AGENTS.md va en la misma línea: lo que el agente necesita saber tiene que estar escrito y al alcance.

Lo que preguntaría antes de adoptarlo

Orbit está disponible para clientes Premium y Ultimate, ya en GitLab.com; GitLab dijo el 29 de octubre que llegaría “en las próximas semanas” a Self-Managed y Dedicated, y se puede probar 30 días con tu equipo de GitLab. Además de eso, yo miraría:

1. El precio por consulta. Cada paquete cuesta 30 dólares en GitLab Credits por usuario y mes y suma 1.000 consultas a un fondo compartido; a partir de ahí se factura a unos 0,03 dólares por consulta. Si tus agentes consultan en bucle, ese contador merece vigilancia. Esto es opinión mía, GitLab no dice nada del consumo de un agente real.
2. Qué cuenta como reintento. Quiero saber qué tareas y qué tamaño de repositorio hay detrás del 45x antes de dejarme llevar por la cifra.
3. Qué pasa con lo que no está en GitLab. El anuncio dice que está pensado para ampliarse a otras fuentes, pero hoy el grafo es el de tu instancia.
4. Quién lo revisa. Un grafo con permisos heredados es cómodo, pero conviene comprobar qué ve cada agente, igual que haces con los permisos de tus agentes en producción.

Mi lectura

Me quedo con la idea, más que con la herramienta: darle al agente una vista conectada del proyecto me parece más sensato que dejar que la reconstruya a base de reintentos. Si ya trabajas en GitLab, merece una prueba controlada con una tarea que hoy te dé guerra. Si no, la pregunta sigue siendo válida: ¿dónde está escrito, y es consultable, lo que tu agente necesita saber?

Cierre

En onext ayudamos a empresas y equipos a adoptar agentes de IA, y casi siempre empieza por decidir qué contexto necesita cada agente y dónde vive. Si quieres revisarlo con tu equipo, escríbenos.