A year ago I broke our own product with coding agents. Every commit looked fine on its own and the tests passed. Those thousands of commits together erode the things that made the product work, because the reasons behind each file lived only in my co-founder Mike's head, and no model was trained on them. The agents filled the gap with the average of their training data. We lost power users. Mike spent nights reverse engineering damage I had shipped to his own codebase.
I tried the obvious fixes first. Pasting session summaries forward by hand. Markdown instruction files, then a folder of them, then a mess of them that nobody maintained. The codebase changed every day and the files stood still, so my agents read last month's decisions and applied them with full confidence. They also burned an obscene amount of tokens since they were getting more context than what they needed. Writing the knowledge down was easy. Keeping it updated and feeding my agents only what they needed it, the moment they needed it, the part I had no system for.
Cortex is what Mike built to answer this question: how does an agent get everything it needs to know before it acts, and nothing else, and how does that knowledge stay current?
The model is simple:
A Module is a named, versioned specification of how one part of your system should work and why. It holds should-state and reasons.
Modules declare dependencies on other Modules. The result is an Semantic Directed Acyclic Graph (SemDAG).
flash is the read and it happens in milliseconds right before an agent acts. The agent receives that Module's complete transitive dependency closure as one bundle, foundations first, each Module emitted once. Understanding one decision almost always requires the decisions underneath it, and this is the part a per-file instructions doc cannot do.
Every Module has exactly one human owner who approves its words. Agents can propose an exact change against a known revision. They cannot publish. Changes are versioned, so you can see who changed what and when.
Issues live on the same graph, filed against the Module they concern, so an agent can pull a unit of work and the exact context required to do it from one place. Modules are "what should be" and Issues reconcile the code.
Some things worth knowing:
Cortex is not an agent. It plugs into the agents you already run.
There is no embedding or similarity search.
You do not have to write Modules to start. Once installed, your agents learn what Cortex is and start proposing Modules from what you tell them during normal work. They will also know when to Flash. Installing the plugin is all you have to do.
eduardadotai•41m ago
A year ago I broke our own product with coding agents. Every commit looked fine on its own and the tests passed. Those thousands of commits together erode the things that made the product work, because the reasons behind each file lived only in my co-founder Mike's head, and no model was trained on them. The agents filled the gap with the average of their training data. We lost power users. Mike spent nights reverse engineering damage I had shipped to his own codebase.
I tried the obvious fixes first. Pasting session summaries forward by hand. Markdown instruction files, then a folder of them, then a mess of them that nobody maintained. The codebase changed every day and the files stood still, so my agents read last month's decisions and applied them with full confidence. They also burned an obscene amount of tokens since they were getting more context than what they needed. Writing the knowledge down was easy. Keeping it updated and feeding my agents only what they needed it, the moment they needed it, the part I had no system for.
Cortex is what Mike built to answer this question: how does an agent get everything it needs to know before it acts, and nothing else, and how does that knowledge stay current?
The model is simple:
A Module is a named, versioned specification of how one part of your system should work and why. It holds should-state and reasons.
Modules declare dependencies on other Modules. The result is an Semantic Directed Acyclic Graph (SemDAG).
flash is the read and it happens in milliseconds right before an agent acts. The agent receives that Module's complete transitive dependency closure as one bundle, foundations first, each Module emitted once. Understanding one decision almost always requires the decisions underneath it, and this is the part a per-file instructions doc cannot do.
Every Module has exactly one human owner who approves its words. Agents can propose an exact change against a known revision. They cannot publish. Changes are versioned, so you can see who changed what and when.
Issues live on the same graph, filed against the Module they concern, so an agent can pull a unit of work and the exact context required to do it from one place. Modules are "what should be" and Issues reconcile the code.
Some things worth knowing:
Cortex is not an agent. It plugs into the agents you already run.
There is no embedding or similarity search.
You do not have to write Modules to start. Once installed, your agents learn what Cortex is and start proposing Modules from what you tell them during normal work. They will also know when to Flash. Installing the plugin is all you have to do.
You can follow this guide to install the plugin: https://workspace.socra.com/docs/cortex/integrations/coding-...
Also available via MCP and CLI. If you use these, add this to your agents.md or equivalent so your agents learn how to use Cortex: https://github.com/socra/agent-plugins/blob/main/shared/cort...