Introducing Cortex

We released Cortex on September 1, 2026. Cortex lets you share context across your AI agents, giving each agent the right knowledge before it acts. You write down how your system should work and why, connect that knowledge by dependency, and let an agent retrieve the part its task needs.

The reasons behind your system

An agent can read a function and understand what it does. The reason you chose that behavior can be much harder to recover. A constraint may come from a customer promise or a failure you investigated months ago. The code shows the decision. It may leave out the reason that still makes the decision correct.

As agents take on more work, you have to carry those reasons into more conversations. Missing context can produce AI slop: competent-looking generic work that loses the specific judgment behind your system. Reviewing the patch helps, but by then the agent has already acted.

We built Cortex so you can give it that knowledge at the start.

Write the rule where the next agent can find it

A Module is a named, versioned specification of how one part of a system should work and why. It gives a piece of knowledge a stable name and an owner. You can change the implementation while keeping the requirement clear.

For example, imagine a team building an AI research assistant. Its answers need a rule for handling missing source material. The following is a fictional Module, included to show what a small piece of useful knowledge could look like.

The reason belongs beside the rule. An agent asked to reduce latency then has enough context to recognize that dropping source checks would change the product's promise. This example describes a decision the rule is meant to inform; it is not a measured result from a customer run.

Bring the dependencies with it

Knowledge often needs other knowledge to make sense. An answer policy may depend on rules for retrieving documents. Those rules may depend on who owns each document and who can read it.

Cortex connects Modules through declared dependencies. We call this structure a Semantic Directed Acyclic Graph (SemDAG). It connects Modules by dependency.

An agent flashes a Module to receive it with its complete dependency tree, foundations first. Each Module appears once, even when several paths lead to it. With a Module named answer-policy in your Account, the call is:

socra cortex flash answer-policy

The agent receives the knowledge the team declared necessary for that subject. It still needs to inspect the repository and verify current evidence before making a change. A flash supplies context; the agent's host and your team's approval rules govern how it acts on that context.

Keep the work connected to the knowledge

An Issue records bounded work and names its owning Module. An agent can read the Issue, flash that Module, and compare the requested change with the rules that govern it.

This gives the next task a clear starting point. It also keeps two different questions explicit: what should the system do, and what work is needed to bring it there? Module dependencies describe what must be understood. Issue dependencies describe what must finish first.

As the team learns, the knowledge can change. Cortex preserves immutable Module revisions so earlier rules and their authors remain available. Agents should propose durable knowledge changes under the team's approval rule. The person responsible for the rule decides what to keep.

Use Cortex with your agent

You can work with Cortex through its web app, CLI, or hosted MCP server. The integration guides explain how to connect the agent you use. Start with one subject you already find yourself explaining, and write the reason another person would need to preserve it.

Then ask your agent to find and flash that Module when the work needs it. A successful flash is the first useful checkpoint: the knowledge has reached the agent in the conversation where it can use it.

Open Cortex to work with your team's Modules, or read how SemDAG assembles context for the technical details.