Imagine your programming language of choice had no concept of an import statement. What would that mean for you as a developer?
Everything you wrote would need to be entirely self-contained, and you would spend a majority of your time re-implementing the same helper functions, abstractions, and utilities ad infinitum. And every function you copied would bring a trail of dependencies you'd have to track down and copy too. Do not Repeat Yourself (DRY) would be non-existent, there would be no packaging ecosystem, and there would be no code re-use. Programming would be far less productive (and fun) without the modern concepts of modularization, packaging, and distribution.
This is the world we live in today with agent context.
Context has dependencies
Today, we have AGENTS.md, skills, and plugins (Oh my!), but we lack an explicit dependency system for context like we have with code dependencies and import statements. But what is a knowledge dependency, and why is it important?
Let's say your objective is to teach a student calculus. In order to teach that student calculus, you must first teach them algebra. Algebra, in turn, builds or depends on arithmetic. So, in order for your student to learn calculus, they must first learn arithmetic, then algebra, and finally calculus. And the order you teach these topics is consequential - you can't teach algebra before arithmetic, because algebra depends on arithmetic. Your lesson plan therefore becomes a kind of dependency graph of topics you need to teach your student, in the right order, in order for them to understand your target topic.
Now, today's frontier AI models already know arithmetic, algebra, calculus, and other general kinds of knowledge. You don't need to burn tokens teaching an agent what Python is, since it's already trained on a huge corpus of Python slop.
What you do need to teach agents, however, is your specific knowledge. Agents don't know how your company defines a customer, how customers relate to accounts, or how those accounts determine access to your product (or that you only use TypeScript 😎). That knowledge is locked in the heads of your leadership teams and engineering, or documented in some pre-AI system optimized for humans clicking through web pages over agent context and context dependencies, or built into one or more markdown files, accessible to one project but no other other projects or teams. Or, worse yet, each team or project has their own definition of each of these topics, and you end up with unaligned agents and fragmented messaging, because there is no Single Source of Truth (SSoT) for each topic.
In short, context has dependencies, but the systems we use today don't provide a deterministic way to specify those dependencies, or teach agents in dependency order everything they need to know in order to understand a certain topic. Or do this across teams, agents, tools, and time. Or do this before they act, so they don't make mistakes in the first place.
SemDAG
So far we've been abstract, so let's discuss the architecture for what we call the Semantic Directed Acyclic graph, or SemDAG.
In 1972, David Parnas revolutionized programming by proposing that software be divided into Modules, each responsible for hiding a design decision, or a “secret” as he called it, from the rest of the system. We can apply the same idea of modularity to knowledge, where each module owns exactly one subject. However, instead of hiding its knowledge, it makes this knowledge available to the modules that depend on it.
A Module declares dependencies on the other Modules needed to understand it, in context. In the above example, Our calculus module depends on algebra, which depends on arithmetic. These dependencies make knowledge prerequisites explicit across the system and must be acyclic: if understanding A requires understanding B first, B cannot also require A, directly or indirectly, because there would be no valid teaching order.
Then, to assemble context for a target Module, we recursively follow its dependencies and collect every module it requires, both directly and transitively. We then de-duplicate modules so each module can only appear once, and sort the result topologically so pre-requisites always come before the topics that depend on them. The result of this process is a single bundle arranged in dependency order.
This process proceeds much like following a script's imports, where a single import may load an entire transitive closure before executing a target file. An authorized Cortex flash returns the target Module and its complete declared dependency closure, with each Module appearing once and prerequisites first. The agent must explicitly request the flash and read the returned bundle. Its host determines how tool context is presented and which instructions take precedence.
Finally, we can load or “flash” this bundle into an LLM's context window, giving the agent the specific knowledge we've recorded about that topic and its prerequisites. We can reuse those same Modules across agents and tasks, much like we reuse a library across programs.
A keen reader will notice that modularization of context starts to look quite a lot like interpreter execution itself, which makes this concept incredibly exciting! Instead of having a Python “runtime”, we now have the backbone for an agentic context runtime, with similar modularization benefits and capabilities.
A Cortex flash returns the requested Module and its declared dependency closure. Each Module appears once, with prerequisites first, so shared dependencies are not repeated within the returned bundle.
Now that we understand SemDAG in theory, we are well positioned to understand Cortex, the system we built to put this architecture into practice, and how it can benefit you and your agents.
Cortex
Defining how the dependency graph should work is only half the problem, though. The other half is making that knowledge available to people and agents, at the moment they need it, at scale. That's why we built Socra Cortex, a cloud implementation of the SemDAG built to work with you and your agents.
Cortex plugs into the agents you already use and augments them with your organization's shared knowledge graph. Your agents can preserve specific knowledge as it comes out of ordinary work, then use it across people, tools, and time. You don’t have to author the graph before you begin; the agents can maintain it for you.
Instead of repeatedly explaining our business, objectives, products, or style, our agents “flash” the relevant Module to load its knowledge together with the dependencies needed to understand it. We now work one layer of abstraction above code, at the layer of intent. We specify how our systems should work in Cortex Modules, and agents reconcile downstream artifacts, including code, against those specifications. For us, the organizational knowledge we previously repeated in AGENTS.md, markdown files, and skills now lives in the graph.
When I change an architectural decision in a foundational Module, agents working from any Module that depends on it receive that change the next time they flash. I don't have to find and update every place we copied the decision. The same mechanism works for technical conventions, such as how we define database models, and for less mechanical knowledge, such as our company's voice and the reasons behind our product decisions.
We've also designed guidance to help agents find, use, and maintain this knowledge. Supported Cortex coding-agent plugins include that guidance; with ChatGPT's plugin, CLI-only access, or a direct MCP connection, save it separately in your agent's persistent instructions. You can keep working in familiar tools like ChatGPT, Claude, Codex, and Claude Code. With an authorized connection, agents can flash relevant Modules and maintain useful knowledge under your instructions and Account permissions, explaining what changed and why. You can customize this guidance; it does not guarantee that an agent will retrieve or update knowledge in every conversation. The installation guide explains the path for your host and how to check access and guidance separately.
A decision you capture with Claude Code today can inform a conversation in ChatGPT tomorrow or guide an implementation in Codex next week. The knowledge belongs to your organization and remains available across tools and sessions.
Conclusion
An import statement lets us reuse a piece of software without copying its implementation into every file that needs it. Agent context deserves the same separation.
Today, too much of the knowledge behind our work has to be reconstructed every time we start a new conversation or switch tools. When that knowledge can be captured, connected, and imported into future work, each conversation can build on the ones before it.
That changes what we should be leaving behind when we work with agents. Every conversation is a chance to build and shape our shared understanding of ourselves, our organizations, and the things we build.
Think about what modularization and imports made possible in programming. Now, imagine that same ability applied to the knowledge, decisions, and intent that guide agentic engineering.
P.S. Socra Cortex is available now.