SemDAG

SemDAG grew out of Socra’s work with coding agents. As agents produced more code, reviewing their changes became a bottleneck. They lacked the specific knowledge behind the system: the architectural decisions and the reasons for making them. Mike Morton described the underlying problem: “A lot of that organizational know-how was locked in my head.”

Context has dependencies

Repository instructions helped with the subject each file described. That subject often required other things to be understood first, and those things had their own prerequisites. The agent could learn a rule without understanding the context needed to apply it. As more repositories and agents used the instructions, someone still had to explain how the subjects connected.

Apply modularity to knowledge

After experimenting with several prototypes, Socra applied the structure of software dependencies to context. A library depends on packages that must be available for it to work. Knowledge can follow the same structure. As Morton explains: “So you can break the knowledge into little discrete pieces and connect them together, just like you would modularize code.”

Each Module owns one subject and declares the Modules needed to understand it. Dependencies must be acyclic so that prerequisites can be read before the subjects that depend on them.

Assemble the prerequisites before work begins

To assemble context for a target Module, follow its dependencies recursively. Collect the required Modules, remove duplicates, and sort them so that prerequisites come first. The result is a single bundle that can be loaded into the agent’s context window before it starts the task. Cortex implements this operation as a flash.

Based on Mike Morton’s SemDAG: A Dependency Graph for Knowledge and Agent Context Needs an Import Statement.

For knowledge shared across tasks and projects, SemDAG provides a smaller unit of reuse than a broad instruction file. An agent can request the Module for its task and receive that subject with its prerequisites. Knowledge outside that dependency graph stays out of the bundle.

Reduce unrelated input tokens

When a whole instruction file is included in a request, every included section consumes context space. An invitation task may need membership rules while the same file also contains deployment procedures. Loading both introduces material that does not help explain the task.

With focused Modules, the invitation task loads its declared dependencies. A separate deployment Module is included only if the selected graph requires it. Deduplication also prevents a shared prerequisite from appearing more than once in the assembled bundle.

This can reduce input-token usage compared with loading a broad file. The saving depends on the selected Module and the size of its dependency graph. Caching and model pricing affect the resulting cost. The graph itself does not establish a measured saving.

Maintain shared instructions once

A decision copied into several repository files must be kept current in each copy. In Cortex, the decision can live in one Module. Agents that flash dependent Modules receive its current content on their next flash. Repository instructions can then direct agents to the relevant knowledge without containing a separate copy of every shared rule.

Repository instructions are maintained within a development project. The decisions they need can originate elsewhere, including design and product work. When those decisions remain in separate documents, someone must carry them into the instructions that agents read.

For example, a designer may define a rule that every form field has a visible label. If engineering agents receive no record of that rule, they cannot reliably apply the team’s decision. Copying it into each repository creates several places to maintain as the design system changes.

In Cortex, the rule and its reason can belong to a shared design Module. Product Modules declare a dependency on that knowledge. Their next flash includes the approved rule, so a decision maintained by one team can guide agents working on another team’s implementation.

This makes the knowledge available across projects and tools. Owners must still review changes, and agents must request the relevant context. Updating a Module does not change the context already loaded in an existing conversation.

A SemDAG represents knowledge as Modules connected by directed edges. An edge from one Module to another means the first requires the second to be understood.

The graph is semantic because its relationships describe prerequisites for understanding a subject. It is directed because that requirement has a direction. Several Modules can depend on the same foundation, and one Module can require several prerequisites.

The graph must be acyclic. If A requires B and B leads back to A, neither can be placed before all of its prerequisites. Rejecting cycles preserves a valid order for assembling the knowledge.

Consider a fictional project with four Modules. Identity defines a stable person identifier. Account depends on Identity and defines an organization boundary. Membership depends on Account and Identity and describes who belongs to an organization. Invitations depends on Account and Membership and defines how a person joins.

A flash of Invitations collects all four Modules. Their prerequisite order is Identity, Account, Membership, then Invitations. Identity is reached through several paths but appears once in the bundle.

A separate Billing Module would remain outside this bundle unless one of the collected Modules declared it as a dependency. The example shows how explicit relationships determine both inclusion and reading order. It illustrates the algorithm without claiming a measured effect on agent performance.

The assembly walkthrough provides the graph and an example implementation with cycle detection.

Knowledge quality

A valid dependency graph establishes an order for the declared knowledge. It cannot prove that the content is accurate or that every necessary dependency has been declared. Owners need to maintain the Modules, and agents must verify their work against current evidence.

Context size

Deduplication removes repeated occurrences of the same Module. A large dependency closure can still exceed a model’s context budget. Focused subjects and necessary dependencies determine whether the assembled bundle remains useful for the task.

Relationship to retrieval

Search can help an agent identify a starting Module. Dependency traversal then follows the explicit relationships from that target. The completeness of the result depends on what the graph declares.

Name disambiguation

Socra’s SemDAG describes a Semantic Directed Acyclic Graph for agent context. The separately developed SEMdag method in SEMgraph, published by Mario Grassi and Barbara Tarantino in 2025, learns directed acyclic graphs for structural equation models.