Before an agent can use your team’s knowledge, someone has to put it somewhere. That’s usually the part people expect to become their job.
Someone has to interview the senior engineer, write down the unwritten rules, organize the documents, and keep everything current. The people who know the most are often the people with the least time for that work. A better place to store knowledge doesn’t help much if nobody puts the knowledge there.
With Cortex, your agents do that work as you work with them. You connect Cortex to the agent you already use, give it the instructions that come with setup, and continue building, reviewing, explaining, and making decisions. You don’t have to fill a knowledge base before you start.
The knowledge comes out of the work
Think about the last time you corrected an agent. You probably explained something specific to your system: why a retry must be safe, why an interface uses a particular component, or why a seemingly simpler approach would cause a problem elsewhere.
That explanation already happened. The problem is what happens to it afterward.
If the reason stays in that conversation, the next agent may repeat the same mistake. You review another patch, explain the same constraint, and make the same correction. The knowledge existed; it just wasn’t available where the next decision was made.
Cortex gives the agent somewhere to preserve it. With the connection, instructions, and permissions in place, the agent can find the Module that owns the subject, add the decision and its reason, and connect any knowledge needed to understand it. If the subject doesn’t have a Module yet, the agent can create one.
You were reviewing the work. The agent was maintaining the knowledge.
This is how we use it
Our engineering and design knowledge is shared across our agents. Mike explains an architectural decision during engineering work. Ed explains what needs to change in an interface. The agents preserve the relevant knowledge, and other agents can retrieve it when they work on the same subjects.
In our design system, Ed can change a shared design decision once. Agents preserve the decision in Cortex, update the shared component, and follow through on the products that use it. Ed doesn’t have to find every copy of the component and explain the change to each agent.
This is the distinction we use: Modules state what is. Issues reconcile the work with that knowledge. The human supplies the intent and judgment. Agents handle maintaining the graph and carrying changes through the work.
Mike has described finding himself repeating his engineering knowledge less often and seeing fewer nonstandard choices from Ed’s agents. Ed says she can’t remember the last time she wrote something manually in Cortex; her agents maintain it for her.
How does the agent know what to keep?
Connecting a tool gives an agent a capability. Instructions teach it how to use that capability.
The Cortex coding-agent plugin includes guidance on finding and flashing relevant knowledge, recognizing specific knowledge worth preserving, and maintaining Modules as the work reveals something new. The agent doesn’t need to save a lesson on what TypeScript is. It may need to preserve why your team uses TypeScript, which conventions you follow, and which constraints another implementation must respect.
The instructions also teach the agent to look for existing knowledge before creating more, preserve the reasons behind decisions, and tell you what changed and why. When later work reveals that a requirement has changed, it can revise the relevant knowledge instead of leaving an obsolete explanation for the next agent.
Different hosts install this guidance differently. Supported coding-agent plugins supply it as part of the integration. Other connections, including direct MCP access, need the suggested instructions saved in the host. The setup guide covers the path for your agent and checks both its connection and its instructions.
Choose how much you want to review
You can change those instructions to match how you work.
Some people want the agent to keep useful knowledge current and report what changed. Others want it to recommend the exact change and wait for approval before saving. Ed has used the review-first approach for design knowledge; Mike prefers his agent to make the updates. Both choices leave the writing and organization with the agent.
Tell your agent which you prefer. For example: “Keep our Cortex knowledge current as we work, and tell me what changed and why.” Or: “Recommend Cortex changes first, and wait for my approval before saving them.” Your Account permissions and the tool approvals in your agent’s host still apply.
It grows with use
An empty graph doesn’t contain twenty years of experience. Cortex also can’t capture a decision the agent never sees, an explanation nobody shares, or information it isn’t allowed to access.
What it changes is the work required to preserve the knowledge that does surface. A correction in a review, a reason explained during an implementation, or a preference expressed while trying a design can become something the next agent can use. Over time, more of the judgment behind your work can survive the conversation in which you explained it.
That value builds as the graph is used and maintained. You should expect the first useful pieces to come from real work, rather than a day spent writing documentation before you can begin. You also decide which knowledge belongs in the shared Account and who can access it; using a service for specific company knowledge is a trust decision, not just an installation step.
Start with your agent
Ask your agent to set up Cortex and follow the instructions for its host. You handle the sign-in and consent that require you, and choose how you want knowledge changes reviewed. The agent can handle the supported setup steps and verify that the connection and guidance work.
Then keep doing the work you were going to do. Build the feature. Review the design. Explain why the first attempt is wrong. Your agent has a way to carry what it learns into the next task.
For the architecture behind that reuse, read Mike’s Agent Context Needs an Import Statement.