Skip to content

Updated

How agents grow your knowledge

View as Markdown

Cortex does not require a separate documentation project. Your agent can preserve the knowledge revealed by the work you already do: a correction during review, the reason behind an architecture choice, or a preference you explain while building something.

The coding-agent plugin supplies guidance for this work. Other installation paths explain where to save that guidance. You choose whether the agent maintains knowledge within its authority or recommends changes for your approval.

Work reveals the knowledge

Suppose you are reviewing an interface with your agent. You point out that selected text is difficult to read in the dark theme and ask for the same readable treatment throughout the product. That is ordinary design work. The agent can preserve the requirement and reason while it fixes the interface.

The same applies to a discussion of why customers belong to Accounts, which architecture tradeoff the team chose, or how the company should sound. You provide intent and judgment through the work. The agent turns useful specifics into maintained knowledge.

What the work revealsWhat the agent preserves
A design correctionThe requirement and reason in the relevant design Module.
An architecture decisionThe chosen behavior, constraints and tradeoff, linked to the knowledge needed to understand it.
An exceptionIts scope and reason, without changing the rule for unrelated work.
A changed decisionThe new current knowledge, with history retained and affected dependencies checked.

One temporary instruction is not automatically a lasting preference. When its scope or meaning is unclear, the agent asks a focused question instead of turning a guess into policy.

Start with material you already have

Existing work can give a new graph a useful starting point. Authorize the agent to inspect relevant documents, repositories, review comments or conversations it can access. It should extract decisions and reasons rather than copy an entire source into Cortex.

For example, you can say:

Use our design review and the project documentation you can access to preserve the decisions that should guide this work. Keep private material within its authorized scope. Ask me about contradictions rather than guessing.

The agent checks existing Modules first, distinguishes current decisions from old proposals, and retains enough source context to resolve uncertainty. If a codebase shows what was implemented but not why, the agent must not invent the missing reason or assume every implementation choice is a requirement.

An agent can only learn from information it receives or is allowed to inspect. Cortex does not observe an expert's work on its own or extract knowledge they have never expressed or demonstrated to an agent. A recording or transcript can be useful input when you are permitted to share it; it is not a guarantee that every part of someone's expertise can be recovered.

The agent maintains the structure

A Module states what is defined for one subject and why. Its dependencies identify the other knowledge needed to understand it. The agent searches for the existing owner of a subject, updates it when possible, and creates a Module only when that subject has no suitable home.

For example, a product-specific design decision can depend on the shared design principles it uses. The agent records that relationship so a later Flash brings both into context. You do not have to name the Modules or connect them manually.

The structure follows meaning, not a copy of repository folders. Keep specific decisions and reasons in Cortex; models already know general programming concepts. Adding more text or more Modules is not the objective.

After a change, the agent reads back the saved knowledge and Flashes the affected Module to check the assembled context. It explains the useful change briefly. The CLI reference documents the underlying operations for agents and people who want to inspect them.

Keep knowledge and implementation aligned

Modules state the system. Issues track work to reconcile code and other artifacts with that knowledge.

In the design example, updating the requirement does not change the interface. The agent still needs to correct the shared component, check the affected consumers and verify the result. That work and its evidence belong on the Issue. The Module remains the current requirement, rather than becoming a running implementation log.

When later work changes the decision, the agent updates its narrow owner, checks relevant dependencies and identifies affected work. The next Flash returns the updated knowledge. It does not replace context an agent already loaded, so an agent continuing the affected work must retrieve the correction before relying on it.

Knowledge stays current through new work and corrections that the agent can see. Cortex does not promise that an unseen change will be discovered automatically.

Choose automatic maintenance or review

You can let agents maintain authorized knowledge and tell you what changed, or require them to recommend each Module change and wait. Ask your agent to adapt the setup instructions to your preference and preserve it for future sessions.

Keep three controls distinct:

  • Your instructions say what you want the agent to do and when it should ask.
  • Host permissions decide whether a tool invocation needs confirmation.
  • Cortex access decides what the authenticated principal is allowed to read or change.

An instruction does not grant missing access or override a host confirmation. A tool permission does not authorize unrelated publication or deployment. The security model explains these boundaries.

Share useful knowledge across the team

Agents connected to the same Account can reuse the same Modules when they have access. A decision preserved during one person's work can guide another person's agent later; nobody needs to paste the same instructions into every conversation.

Connect each host to the intended Account and grant the knowledge and Issue access it needs. Do not copy personal credentials between agents. Private customer or team material should stay within the appropriate access boundary, including the dependencies returned by a Flash.

If two people provide conflicting decisions, the agent should identify the conflict and resolve it with the responsible owner. It should not silently turn the most recent comment into a new rule for everyone.

Check whether the knowledge helped

Look at later work. Did the agent retrieve the relevant decision before acting? Did it use that decision correctly? Did it need less repeated explanation? When the requirement changed, did the agent update the existing knowledge and correct affected artifacts?

An empty graph on the first day is normal. Useful existing material can shorten the start, and repeated work can make preserved knowledge more valuable. Neither installation nor Module count proves that benefit. If the agent is not learning or reusing what it should, use Troubleshoot Cortex.