Represent company functioning and improve output quality

In the previous chapter, JD Pruitt described three parts of an FDE agent. This chapter moves one level deeper: what representation of the customer should the agent use, and how can its output become useful rather than merely detailed?

The proposed answer has two parts:

1. Represent how the company works as a dependency graph.
2. Train the model to turn that representation into a clear, selective process flow.

These are different problems from simply giving a model more documents. Documents contain information, but the agent also needs to understand relationships and decide which details matter for the current question.

Build one coherent representation of the company

JD proposes a “single source of truth” for how a company functions. Here, that phrase means a coherent representation of the company's processes, dependencies, and relationships. It does not necessarily mean one physical database or one document.

The important design choice is the representation as a dependency graph, not the particular storage technology. A graph makes relationships explicit:

• one activity can depend on another activity;
• a person or team can own part of a process;
• one decision can require several earlier decisions;
• a later step can send work back to an earlier step.

The speaker says that workflows are mostly linear, but they also contain dependencies and cycles. In other words, a workflow may look like a sequence when described broadly, while its real operation includes cross-links, prerequisites, and repeated paths. The talk later refers to violations of a directed acyclic graph (DAG), but it does not define the exact formal graph structure. The safe lesson is that a simple list of steps is not enough to capture all of the relationships in company work.

Example: why dependencies matter

Suppose step C is an approval that must wait for both A and B. A plain list might say:

A → B → C

That list incorrectly suggests that B must finish before C, but it hides the fact that C also needs A. A dependency representation makes the requirement explicit:

A ─┐
   ├──→ C
B ─┘

This is a teaching example of the structure JD describes. It is not a claim about one specific customer workflow. Its point is that the agent should know why a step can happen, not only which step appears next.

Click to enlarge

Source visual at about 16:04: the slide visibly demonstrates prerequisite relationships through directed arrows. It does not visibly label process owners, approvals, or cycles, and it does not show the A/B/C example above.

The visual supports the distinction between a conceptual graph and its implementation. The graph is the model of how work depends on other work. Whether that model is stored in a graph database, Postgres, or another system is secondary to preserving those relationships. The speaker explicitly says that choosing a graph database over Postgres is not the main point.

First model problem: make the process flow useful

Once the company is represented, the agent still has to produce a usable analysis. The source describes a problem with using a generic frontier model for this task: its answer may be verbose, but it may not focus on what the client actually cares about.

This is a quality problem, not simply a length problem. A short answer can omit an important dependency. A long answer can bury that dependency under details that do not affect the decision. The desired output balances:

• detail, so important process information is not lost; and
• clarity and selectivity, so the reader can see the relevant path and dependencies.

The speaker compares this judgment to the work of a good consultant. A consultant does not treat every fact as equally important. They try to identify which details matter to the client's question and which can be glossed over. The transcript does not explain how that judgment is encoded in the model or how it is measured.

The proposed response is to post-train an open-source model for this kind of output. Post-training means continuing to train a base model so that it behaves better for a target task. In this case, the target is a normalized process flow: turning notes and other company material into a structured account of how work proceeds and what it depends on.

The source does not specify the model, training set, training objective, or evaluation metric. Therefore, the claim is about the direction of the system design: specialize the model for selective process analysis instead of assuming that a general model will produce the right level of detail automatically.

Raw information versus a normalized process flow

Consider the difference between these two outputs:

Raw analysis:
“The team uses several approval systems, messages different people,
and sometimes checks a spreadsheet. There are also exceptions...”

Normalized process flow:
1. The request enters the approval process.
2. A and B must approve it.
3. C acts only after both approvals.
4. If an approval fails, the work returns to the responsible owner.

The second form is easier to inspect and use because it exposes sequence, ownership, and dependency. The exact example above is illustrative. The source's central point is that the agent must preserve the client-relevant structure while avoiding unnecessary explanation.

Keep two model questions separate

The chapter identifies one model challenge and points toward another. They should not be confused.

1. Can the model write a good process analysis from context?

This is the quality issue discussed here. Given the relevant company context, can the model produce a process flow with the right detail and clarity? Post-training is presented as a way to improve this behavior.

2. Can the system find the right context in the first place?

A model can write an excellent explanation of the wrong department, person, or workflow. That answer is still wrong for the user's question. The next chapter continues with this retrieval problem: traversing the larger knowledge graph to select the relevant context.

This separation is important. Better writing does not repair missing context, and a perfect representation does not guarantee that the model will retrieve the right part of it. The FDE agent needs both a useful company representation and a model that can reason over the appropriate portion of that representation.

Why this matters for the FDE agent

The FDE's earlier work—learning how the customer operates and redesigning workflows around AI—creates the knowledge that this system must represent. The dependency graph turns that knowledge into relationships the agent can use. Model specialization then aims to make the resulting process descriptions understandable and operationally relevant.

This is the broader shift in the talk. The challenge is not only to make an AI system execute an isolated task. It is to capture how a particular company works, including dependencies that are easy to miss, and then express that understanding at the level of detail needed for a real decision.

The source presents this as an engineering direction, not as a fully specified or independently validated system. Its architecture details, training procedure, and quality measurements are not supplied here. The next chapter addresses how the model is intended to retrieve the right subgraph and how that may support bounded automation of routine workflow changes.