--- title: "Agent Context Needs an Import Statement" canonical: https://workspace.socra.com/blog/engineering/agent-context-needs-an-import-statement author: "Mike Morton" published: 2026-09-07 updated: 2026-09-07 --- # Agent Context Needs an Import Statement 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. ![Meme: a person prepares to code, then prompts an agent to make no mistakes.](/images/blog/agent-context-needs-an-import-statement/make-no-mistakes.jpg) ## SemDAG So far we've been abstract, so let's discuss the architecture for what we call the Semantic Directed Acyclic graph, or SemDAG. ![A directed acyclic graph with five numbered nodes and branching dependencies.](/images/blog/agent-context-needs-an-import-statement/semantic-dependency-graph.png) 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 and optimized for comprehension. This process proceeds much like following a script's imports, where a single import may load an entire transitive closure into memory before executing a single line of code in a target file. In doing so, we can guarantee that all declared dependencies are loaded into the context window before trying to “teach” or “execute” our target module, so the agent is far more capable of understanding the target module **in context**. Finally, we can load or **“flash”** this bundle into an LLM's context window and use In-Context Learning (ICL) to turn a generic agent into an optimized subject matter expert on that topic in a reusable, composable, and scalable manner. 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. With focused Modules and necessary dependencies, we load only the knowledge required to understand the target topic, and each piece appears once. This is _perhaps the most token-efficient way to teach an LLM any kind of complex or specific knowledge_. 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. [![A Cortex knowledge graph connecting shared foundations to downstream Modules.](/images/blog/agent-context-needs-an-import-statement/cortex-introduction.jpg)](/images/blog/agent-context-needs-an-import-statement/cortex-introduction.jpg) ## 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. Define your context once, then use it wherever your agents work, across people, tools, and time. 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 the Cortex agent plugin and MCP server to teach agents how to find, use, and maintain this knowledge. You can keep working in familiar tools like ChatGPT, Claude, Codex, and Claude Code. As you work, your agents draw on relevant Modules and propose additions or updates when your conversations reveal knowledge worth keeping. You review those changes, and the graph grows with your work. 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. [![Cortex displaying the web-app Module and highlighting its 25-Module flash in the SemDAG.](/images/blog/agent-context-needs-an-import-statement/cortex-knowledge-graph.jpg)](/images/blog/agent-context-needs-an-import-statement/cortex-knowledge-graph.jpg) ## 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.