In this chapter, we examine the second model challenge in building an AI agent that understands how a company works. Having a large knowledge graph is not enough. The model must reliably find the parts connected to a question. The talk describes a way to train for this and a future use of that understanding for automation.
At the earlier stage, the challenge was to turn scattered information such as notes and documents into an understandable workflow. Frontier models can produce analyses that contain a great deal of information. However, they can be too detailed and fail to select what the client really wants to know. The talk explains that the balance between useful detail and clarity matters, not just the amount of information. The team therefore post-trains an open-source model so that it can represent business processes in a more useful form.
会社の働き方を依存関係グラフで表す
Represent How the Company Works as a Dependency Graph
The team wants to create one coherent representation of how the company works. Here, a “single source of truth” does not necessarily mean one database or one document. It means a representation in which people, tasks, decisions, order, and prerequisites can be followed using the same model.
The talk emphasizes the idea of a dependency graph, not the choice of a particular graph database. Whether the implementation uses a graph database or Postgres is not the central issue. What matters is that the representation can show how one task or decision depends on another. Workflows may be mostly linear, but they can include dependencies and cycles. The talk later mentions DAG violations, but it does not provide a formal graph definition here.
For example, suppose task C requires both A and B to be approved first. A simple employee list or document list makes this condition hard to see. A dependency graph can connect “approval by A” and “approval by B” to “start C” with arrows. This lets an agent handle not only who is involved, but also which conditions must be met first. This example is added to make the idea in the talk easier to understand.
図：会社の業務を依存関係グラフで表し、モデルを訓練してから展開する流れです。
Figure: The flow from representing company operations as a dependency graph, through model training, to deployment.
The slide shows company operations represented as a Postgres dependency graph, a model trained over that graph, and knowledge-graph and retrieval tools deployed through MCP (Model Context Protocol). The arrows show prerequisite relationships. However, the diagram does not detail process owners, approvals, or cycles. Its display alone cannot establish the implementation method or performance.
The second challenge is knowledge-graph traversal. This is not about storing still more information. It means selecting the connected people, tasks, decisions, and dependencies relevant to one question, then retrieving the necessary subgraph.
The larger the graph becomes, the harder this selection is. If the model follows irrelevant branches, the analysis becomes longer. If it drops a necessary connection, the answer becomes incomplete. In other words, putting company information into a graph does not improve answers unless the model can reliably move to the right part of it.
In the approach described in the talk, the post-trained model is placed in a reinforcement-learning (RL) environment. The model is given specialized tools for traversing the knowledge graph. The idea is that, before writing an answer, the model learns which information to check and which relationships to follow.
The talk does not explain the reward design, the exact tool interfaces, the training data, the evaluation metrics, or the safeguards. Therefore, the supported claim is only the design direction: use an RL environment and custom tools. We cannot infer retrieval accuracy from numbers.
One example of a tool identifies the same person. For example, a name in an email and a differently written name in Slack may refer to the same employee. Entity resolution is the task of linking those two references to the same person. This is different from finding duplicate facts or finding an invalid structure in a business graph.
Other tools detect problems such as duplication, cycles, and DAG violations. They might check whether the same relationship was registered twice, whether a dependency has become circular, or whether a connection that is not allowed in a DAG has appeared. The talk gives these as examples, but it does not specify the formal definition or implementation of each check.
「書く力」と「探す力」を分けて考える
Treat the Ability to Write and the Ability to Find as Separate
The key point in this design is not to confuse two problems. First, given context, the system must explain the business workflow that matters to the client, with an appropriate level of detail. Second, it must retrieve the correct context from the graph before writing that explanation. Improving only the first produces a polished, detailed wrong answer if the input is wrong. Improving only the second still leaves an FDE with a result that is difficult to use if the retrieved information cannot be organized into a clear workflow.
The third stage described in the talk is for an agent that understands the company and its workflows to manage small workflow tasks autonomously. For example, when a client requests a routine change to an owner or notification recipient, the agent could look up the company context and update the relevant flow on the platform. This is a future proposal, not a claim that it can run general enterprise activity without people.
This boundary for automation also connects to the earlier judgment about value and risk. A low-impact, easy-to-check routine update might be assigned to an agent. An FDE would continue to interview people, understand exceptions, and learn how departments actually work. The goal of reducing routine tasks is not to remove human FDEs. It is to return their time to higher-value customer understanding.
In short, collecting a large amount of company information does not by itself create a reliable business agent. The system must represent work as dependencies, retrieve the right parts, and turn that context into a clear workflow. The proposal in the talk is to train the model with tools and eventually automate small updates within a safe boundary. This lets FDEs focus less on routine changes and more on re-understanding how the client works.