Train reliable context retrieval, then automate routine updates

Video position: 17:20–18:37

The previous chapter described how to represent a company's processes as a dependency graph. This chapter addresses the next problem: how does a model find the small, relevant part of that graph when it needs to answer a question or change a workflow?

The speaker's point is simple: storing company knowledge is not enough. An agent must also retrieve the right connected context reliably. Only then would it have the context needed for small routine updates.

A large graph can still produce a poor answer

A knowledge graph represents entities and their relationships. In this talk, those entities can include people, processes, documents, and workflow steps. A graph traversal follows relevant relationships through that representation to collect context for a question.

This is different from searching for one matching sentence. A process question may depend on several connected facts. The model may need to identify a person, follow that person's process responsibility, and then follow dependencies to an earlier or later workflow step. The useful answer is the resulting subgraph—the relevant neighborhood—not the entire company graph.

That creates a second model challenge:

1. Analysis quality: given useful context, produce a clear and properly normalized process flow.
2. Retrieval quality: find the useful context in the first place.

The previous chapter focused on the first challenge. This chapter focuses on the second. A very capable general model can still fail if it selects the wrong part of a very large graph. More stored information does not automatically mean more useful context.

Train the model to use graph tools

The speaker describes exposing a post-trained model to custom tools for graph traversal inside a reinforcement-learning (RL) environment. In general, an RL environment lets a model take actions and receive feedback that helps it learn which actions lead to better results. Here, the relevant actions involve investigating and checking the company's graph.

The talk names several kinds of custom tool:

• People or entity resolution: determine whether two differently written references point to the same person or entity.
• Redundancy detection: find repeated or unnecessary information in the represented process.
• Graph-structure checks: identify problems such as a redundancy cycle or what the speaker calls a DAG violation.

Entity resolution matters because business information rarely uses one perfectly consistent label. An employee might be named one way in an email and another way in a document or chat message. If the system treats those references as different people, it can construct the wrong ownership or dependency chain. Resolving them to one entity gives the model a more faithful path through the graph.

The structural checks address a different failure. Even if the model identifies the right people and documents, it can still assemble a workflow with duplicated steps or an invalid dependency. The speaker mentions cycles and DAG violations as examples of these graph-level problems. The transcript does not define a formal graph rule for each case, so the important lesson is the boundary: retrieval must be checked not only for topical relevance, but also for consistency with the represented workflow.

What the source does not specify: the talk does not give the RL objective, reward design, training data, tool interfaces, evaluation metrics, or safeguards. The description supports the training approach at a high level, not a claim about a measured accuracy or a complete autonomous-agent design.

Click to enlarge

Figure (around 17:40): A slide titled "Building The Agent" shows a three-stage pipeline: representing company operations as a Postgres dependency graph, training a model over the graph, and deploying knowledge-graph and retrieval tools via MCP.

The slide makes the sequence concrete: represent operations, train over that representation, and expose graph and retrieval tools through MCP. It also visibly presents training with supervised fine-tuning (SFT)—training on examples—and RL focused on traversal failures, along with evaluation of retrieval. The visual supports the implementation overview; it does not supply the missing training objectives or evaluation methodology.

From reliable context to bounded automation

The speaker then describes a future third stage. Once the system understands the company's processes and can retrieve the relevant context, it could manage small workflow tasks autonomously. The example is a routine client-requested change, such as updating who receives a QC report.

The intended path is:

1. A client sends a request by email.
2. The agent looks up the relevant company context.
3. It changes the corresponding workflow on the platform.
4. The FDE is not required to handle that routine update manually.

This is not presented as general autonomous operation of an enterprise. It is a bounded capability for small changes that do not require the FDE's attention. The speaker explicitly describes this final stage as future work, and the talk does not explain its approval process or safety controls.

That boundary preserves the role of the human FDE. Automation handles routine workflow minutiae so the FDE can spend more time interviewing customers, understanding how work actually happens, and improving the process design. This connects retrieval back to the larger argument: the goal is not merely to make an agent answer questions. It is to scale the high-value context work without replacing the human discovery needed for bespoke enterprise operations.

The core chain

The chapter's logic can be summarized as:

Company operations
      ↓
Dependency-graph representation
      ↓
Reliable traversal and entity/structure checks
      ↓
Relevant context for process analysis
      ↓
Small, bounded workflow updates
      ↓
More FDE time for customer understanding

The key distinction is between knowing that information exists and retrieving the connected facts needed for one decision. The proposed agent must improve both its ability to write a useful process analysis and its ability to locate the right context before writing it. Only the second capability makes later routine automation plausible.