8:39 - 10:21

A context graph for finding software and business context

By the end of this chapter, you should be able to explain how a context graph turns scattered context gathering into connected retrieval. You should also be able to compare the speakers' SQL-with-graph and SQL-without-graph example without treating the graph as a replacement for SQL or the underlying data systems.

The bottleneck appears before coding

An agent can have a model, tools, and a prepared workspace and still spend much of its run looking for basic information. In a large monorepo, a repository containing a very large shared codebase, it may first need to determine:

where a service is located;
which services or components it depends on;
who owns it; and
which engineering patterns it should follow.

Uday says that execution traces, records of agent runs, showed agents spending a lot of time on this kind of context discovery. The problem is not only finding a file. The agent must connect code to ownership, dependencies, design information, operational history, and data.

The speakers say that this information is scattered across 20 to 30 systems. They describe each system as needing its own skill and MCP for context gathering. A skill is a reusable agent capability or workflow. MCP is the tool-integration mechanism used in the talk to expose APIs and other tools to agents; the talk does not expand the acronym.

That arrangement creates a fan-out problem:

many source systems
        ↓
separate skills and MCP calls
        ↓
more context, reasoning turns, and waiting
        ↓
higher token use, latency, and unpredictability

Here, a token is a unit of text or other information held in the model's context. Each independent lookup can add information that the model must process and another turn in which it decides what to ask next. The result may be slower and less predictable even when every individual lookup works.

The fifth platform block is the speakers' context graph: a connected representation of software, organizational, documentation, incident, and data context that agents can query. Context retrieval means finding the service, dependency, owner, pattern, document, incident, or data information needed for a task.

In graph terms, a node represents an entity, such as a service or document. An edge represents a relationship between entities, such as dependency or ownership. The term node and edge type refers to a category of entity or relationship represented in the graph. These connections let an agent retrieve related information instead of reconstructing the relationships from unrelated search results.

The speakers report 150 unique node and edge types and 40 million entries in the graph. These are speaker-reported scale figures. The supplied material does not define their counting method, freshness, ranking, or access-control design.

Caption: A Context Graph slide shows Service at the center of a connected network of engineering, product, operational, and application entities. The slide also frames the problem as missing relationships, scattered context, and fan-out that consumes tokens and time. Source at 9:20

From separate lookups to connected retrieval

Consider this teacher-created walkthrough. An agent is asked to plan a change to a service. Before it proposes a change, it needs the service's location, dependencies, owner, required patterns, related design documents, recent incidents, and relevant data.

Without connected context, the agent may use one skill to find code, another to find ownership, another to search documents, and another to check incidents. An MCP call may be involved for each system. The agent then has to combine the responses and decide whether they refer to the same service and the same proposed change.

With a context graph, the conceptual retrieval path starts at the service and follows its connected relationships to dependencies, owners, patterns, documents, incidents, or data. This is a change in the shape of retrieval. It does not require the agent to treat every system as an unrelated search destination.

The talk does not describe the graph's exact traversal, ranking, ingestion, or synchronization implementation. The teaching model is therefore not a claim that every task becomes one graph query. It explains why explicit relationships can reduce the work of joining separately retrieved context.

The graph also does not replace the underlying systems. Code, documents, issue records, incident records, and data remain distributed. The graph is a shared context layer that helps agents find relevant parts of those systems.

Broader than code search

The speakers describe a scope wider than a source-code index. They say the graph reaches from how Uber's mobile apps are built, through backend systems, to the data lake. They also name design documents, Jira, and incident bugs. This combines technical context with product, operational, and organizational context.

That breadth changes the questions an agent can approach. Code search can help locate a function. Connected context can relate that function's service to its owner, dependencies, intended design, operational incidents, or data used to analyze a feature. The graph does not make a relationship true merely by storing it. Its value depends on whether the needed relationship is represented and usable.

The speakers say they are plugging skills and use cases into the graph. They name on-call RCAs, meaning root-cause analyses, along with planning, data analysis, and security scans. The same context layer can therefore support work that starts from code, operations, a business question, or a security concern. The later Cortana layer packages this kind of shared context for users; it is still distinct from the graph itself.

The execution traces explain why this layer matters. A trace can show that an agent spent time searching for context rather than reasoning about or changing code. That observation makes context discovery a visible part of the workflow and gives the team a reason to improve the skills and use cases connected to the graph. The source does not specify a complete evaluation method for those improvements.

Keep the platform layers separate. A model produces or reasons about an answer. An MCP gateway organizes access to tools. A context graph connects the information that agents and tools need to find. A skill can use all of them, but none of them is the graph.

The SQL example: context before query construction

The speakers then use a data question to compare SQL work with and without graph context. The transcript preserves the question only in fragmented form, roughly asking how many mobility trips in India are “cash.” Its exact business meaning is uncertain. Treat it as an illustrative question shape, not as a precise requirement or a reported business result.

To answer a question like this, an agent first needs to understand the business concepts and identify the relevant tables and data context. The graph changes what the agent knows before it constructs the SQL:

SQL without graph context	SQL with graph context
The agent first discovers which data source, concepts, and related context answer the question.	Connected context can relate the business question to relevant data before query construction.
That discovery may require several tool calls and reasoning turns.	The graph is intended to reduce scattered context gathering.
The agent combines separate results before it can form a targeted query.	The agent can use the retrieved relationships to construct a more targeted query.

The graph does not replace SQL. SQL still expresses the data query, and the underlying data system still supplies the data. The graph helps the agent find the context needed to write that query.

Caption: A Context Graph slide compares a SQL question answered with and without graph context. The graph column visibly shows lower displayed time, cost, and tool-call usage than the no-graph column, alongside the connected network diagram. Source at 10:08

The speaker describes the SQL-with-graph comparison as showing a “massive improvement” in tokens, turns, and latency, and says similar improvement was seen in earlier infrastructure evaluations. The supplied source gives no numeric result, units, denominator, or evaluation design. The slide's displayed comparison therefore supports the direction of the argument, not a universal performance guarantee for every query or graph implementation.

Check your understanding

Why can a graph help with a service-ownership-and-dependency question?

It can make ownership and dependency relationships available from the service context, reducing the need for several independent lookups and the turns needed to combine their results. The speakers present this as an intended reduction, not a guarantee for every task.
Does “SQL with graph” mean that the graph writes the query or replaces the data system?

No. The graph supplies connected context so the agent can form a more targeted SQL query. SQL and the underlying data system remain part of the workflow.

Synthesis

The context graph addresses a bottleneck before implementation: finding connected software and business context. The speakers present one graph as a shared layer over information that remains distributed across many systems. By exposing relationships among services, owners, dependencies, documents, incidents, and data, it is intended to reduce the tokens, turns, and latency spent gathering context. The reported scale and improvements remain speaker claims, while the graph's ingestion, freshness, ranking, access controls, and general evaluation method are not specified.