GenAI Advisory · GitLab · Agentic AI
GitLab Orbit & Agentic AI
What Orbit's SDLC knowledge graph does for AI agents, where it helps, and the code it won't read — the blind spot to plan around before you rely on it.
What is GitLab Orbit?
Orbit is GitLab's SDLC knowledge graph — a structured index of issues, merge requests, pipelines, deployments, and their relationships across a project's lifecycle. When an AI agent connects to a GitLab instance with Orbit enabled, it can query the graph instead of scraping raw data from individual API endpoints.
The graph answers questions like: "What MRs are open against this service?" or "Which pipeline failed last and what was the error?" without the agent needing to know GitLab's API pagination model or where to find deployment logs. The agent queries a structured relationship map instead of navigating dozens of REST endpoints.
Where Orbit helps agents
- Answering "what changed recently?" across the project — MRs, issues, deployments, pipeline results
- Linking a failed deployment back to the MR and issue that caused it
- Summarizing open work, blockers, and review queues without scraping the UI
- Providing context for a code review: who touched this file, what issues it relates to, whether CI passed
- Feeding planning agents structured project state they can reason over
The blind spot: code it won't read
- Orbit indexes SDLC metadata — not the code itself
- An agent relying solely on Orbit cannot read function signatures, parse imports, or understand internal patterns
- Code-level tasks (refactoring, writing tests, generating implementations) still require direct repo access
- Orbit tells you what happened; reading the code tells you what the system actually does
- Teams that assume "GitLab AI = full codebase understanding" will hit this gap on day one
The practical implication: Orbit is excellent for orchestration and project-awareness tasks — routing work, summarizing state, triaging failures. But it does not replace a code-reading agent (Claude Code, Copilot, Amazon Q Developer) for implementation tasks. Plan for both layers.
Where this fits in an agentic stack
A mature agentic coding setup uses multiple tools with different scopes. Orbit provides the project-level awareness layer — "what's going on in this repo?" — while code-level agents handle the file-level work. The orchestration layer (a planning agent or human) decides which tool gets which task.
In practice this means: Orbit can tell an agent "the last three MRs into main all failed the SAST scan," and a code-reading agent can then look at the actual findings and write fixes. Neither tool does the other's job well.
Recommendations before you rely on Orbit
- Map which agent tasks need SDLC metadata (project state, pipeline results, issue context) vs which need code access — assign tools accordingly
- Don't assume "AI-powered GitLab" means the agent reads your source code — verify what Orbit indexes in your tier
- Pair Orbit with a code-reading agent for implementation work: Claude Code, GitHub Copilot, or Amazon Q Developer
- Test the boundary: ask your Orbit-connected agent to refactor a function. If it can't, you've confirmed the scope and can plan around it
- Treat Orbit as the orchestration/awareness layer and code agents as the execution layer — they complement, not replace, each other
Need help choosing and wiring up agentic coding tools?
Orbit, Claude Code, Copilot, Q Developer — they all have different scopes and costs. I help teams figure out which tool does which job.
See GenAI & AppSec advisory