Context graphs

A context graph is a structured, queryable model of your organization: the entities (people, services, projects), the relationships between them, how that state changes over time, and the decision events that explain why something happened.

Rather than just storing information, a context graph stores the connections between pieces of information as queryable relationships, so an AI agent can ask "how does this connect to that?" and traverse the answer instead of making an assumption.

Think of a typical enterprise as an iceberg. A small, clean layer sits above the waterline with information like CRM records, ERP transactions, and pipeline metrics. Below it sits a much larger mass that most systems never capture: the exceptions, approvals, and judgment calls that run the business.

In the modern enterprise, data is rarely static. It is a sprawling web of interconnected signals, yet our most critical decisions are often made in a vacuum, isolated from the very history that informs them.

AI agents are increasingly tasked with complex reasoning, but they frequently fail because they lack access to the "tribal knowledge" locked away in Slack threads, side-conversations, and the people who have worked with the company for years. This is where the context graph becomes essential.

Most enterprise organizations only manage what's above the waterline. Data sits in a warehouse or scattered across SaaS platforms, but it isn't formatted in a way that lets machines interpret it across disparate workflows, so the reasoning beneath it stays exactly where it always was: undocumented. Context graphs pull that submerged layer up into the light, turning fragmented records into connected, machine-readable relationships that people and agents can query directly.

This matters because, in the age of generative AI, context is the primary currency. When that context is incomplete, agents may create believable output, but they can still miss dependencies, ownership, policy rules, or downstream impact. Context graphs provide the necessary governance policies and decision context to ground agentic reasoning in reality.

They ensure that when an AI suggests a change, it does so with a full understanding of the impact analysis and risk profiles involved, above the waterline and below it.

Unlike traditional vector search which finds isolated but similar documents, context graphs map the explicit relationships between data points, allowing AI to traverse known connections.

Traditional retrieval, such as standard vector search in vector stores, excels at finding documents similar to a query. However, it often lacks the structural awareness required for complex enterprise logic. Traditional retrieval gathers logs or snippets and asks the model to "infer" relationships, which is inherently error-prone.

Context graphs take a different approach: they preserve the graph structure in advance using Resource Description Framework (RDF) triples and typed relationships. By leveraging knowledge graphs and multi-vector search, these systems allow an orchestration layer to traverse known connections instead of guessing them at runtime.

This creates a semantic layer where the model understands where the data came from and what shaped it, not just the semantic similarity of text.

A context graph can represent many kinds of entities and relationships. In a software environment, that may include:

• files, directories, classes, functions, and modules
• relationships such as dependencies, inheritance, and function calls
• lifecycle data such as code, merge requests, pipelines, deployments, vulnerabilities, and ownership
• broader operational and organizational signals, including incidents, environments, and team context

In software environments, this broader model becomes especially valuable in a developer context graph, where code, CI/CD, security, deployments, and ownership can all be queried together rather than understood as separate systems.

Some teams push the model further by treating decision events as first-class records. That means not only capturing what exists and how it connects, but also preserving why a decision was made, what policy was applied, which exception was granted, and who approved it.

The impact of decision events in software development and agentic AI

Hear from Nitin Singhal, the VP of Engineering at GitLab, how context from the decision layer influences software development.

That is why decision events matter: they turn organizational judgment into something durable, queryable, and reusable across future actions.

Learn more about the decision layer and how enterprises can capture decision events so AI agents can reason from judgement, not just data.

Context graphs are very useful when teams and agents need answers that cover repositories, services, pipelines, and ownership boundaries.

Uncover hidden risk in code review

Behind every merge request approval is reasoning that normally disappears: a deferred risk, a deadline-driven shortcut, or a concern raised once and forgotten. A context graph can record that reasoning as a structured decision event, so the next reviewer builds on what was already considered instead of starting over.

Plan and scope migrations

Platform teams can map complex service dependencies before a major infrastructure shift. By querying the lineage traversal of an application, they can visualize potential bottlenecks before a single line of code is moved.

Trace vulnerabilities

Security teams can find where a vulnerable function, library, or pattern appears across repositories. They can also identify affected owners faster, significantly reducing the "mean time to remediate" for critical security flaws.

Triage pipeline failure

Engineers can investigate a failed CI job using one shared graph instead of piecing together logs, merge requests, and configuration changes across five or six systems. They do not have to piece together the path from multiple systems, as the decision lineage provides an immediate audit trail.

Receive analytics on demand

Engineers ask natural language questions about their data in agentic chat and get charts and tables back instantly, covering relationships across code, pipelines, and deployments that previously required manual assembly.

A useful context graph should do more than index files. It should stay current as work changes, support direct querying, and expose structured relationships that AI systems and humans can use consistently.

Important capabilities include:

• a live, continuously updated graph rather than a static export
• coverage across the software lifecycle, not only source code
• support for multiple access patterns such as UI, CLI, REST, or MCP
• queryable relationships that return exact nodes and edges rather than long unstructured dumps
• governance and access controls so agents only reach authorized context

In practice, this means architecting a context graph for AI agents so it can stay current, support multiple query patterns, and preserve the relationships agents need at decision time.

The distinction between a "smart" agent and an "enterprise-ready" agent will be its access to a high-fidelity context graph.

By anchoring generative AI in a semantic backbone of RDF statements and decision lineage, organizations can transform their systems of record into true systems of intelligence.

Whether you are managing a massive supply chain model or a simple service migration, the power to map what’s below the iceberg’s waterline is the next frontier of enterprise software.

GitLab Orbit is how we’re building that layer for the software delivery lifecycle.

It's a live, queryable graph of all your code, merge requests, pipelines, deployments, vulnerabilities, and ownership, with every relationship between them kept current as your team works. Agents reason from first-party GitLab data instead of stitched-together tool calls. Engineers can query the same graph to trace changes, investigate incidents, and answer the cross-system questions that today take hours of manual reconstruction.

Explore GitLab Orbit to discover the context your team is missing.