Use case: Agent memory

Situation

You use LLM agents for recurring work — audits, code reviews, technical writing, compliance checks. Each session is productive on its own, but the agent has no memory of what happened before. It re-discovers patterns, re-makes decisions, and re-encounters the same blockers.

Chat history is not memory. It is a raw transcript that grows too large to fit in context and does not distinguish a significant decision from a trivial greeting.

---

Solution

Cortex provides a structured, per-project memory layer that agents read at the start of each session and write to at the end.

What gets stored

Memory in Cortex is not a flat log. It is organized into typed entries:

• Decisions — what was decided, why, what impact it had. Decisions can be superseded when a better approach is found.
• Errors and corrections — what went wrong, what the fix was, what lesson was learned. Next time the agent sees the same situation, it has a correction ready.
• Patterns — recurring observations. When the same thing shows up three times, Cortex records it as a pattern with a recurrence counter.
• Blockers — what blocked the agent, which tool or rule was involved, and what workaround was applied.
• Needs — capabilities or information the agent identified as missing.
• Feedbacks — inter-agent feedback from collaborative missions.

How it works

1. At session start, the agent requests a memory resume from Cortex (cortex_memory_resume via MCP or GET /api/memory/resume via REST). The resume contains active decisions, open errors, known patterns, current blockers and identified needs — a compact, structured context.

2. During the session, the agent can deposit new memory entries via cortex_memory_deposit (MCP) or POST /api/memory/deposit (REST).

3. At session end, a note writer can produce a Praxis note — a structured synthesis (level L2 to L5) that captures what happened and why it matters.

4. For multi-agent handoffs, a checkpoint trace records what was passed between agents, what was validated and what the resilience protocol is if something goes wrong.

Semantic enrichment

Memory entries can optionally carry embeddings (generated locally via Ollama + bge-m3). This enables semantic search across memory — finding related decisions even when the wording is different.

---

Key concepts involved

• Memory — the full memory model
• ATOM — memory entries are stored as graph nodes with the six-layer atom structure
• Versioning — Praxis notes are versioned; updates bump the semantic version

---

Example flow

Scenario: a QA agent auditing a codebase over multiple sessions.

1. Session 1 — The agent audits module A. It decides to use a 7-axis QA method. It encounters a test coverage gap and records a blocker (CI pipeline times out on integration tests). It deposits: one decision (method chosen), one blocker (CI timeout), two patterns (inconsistent naming, missing error handling).

2. Session 2 — The agent receives the memory resume. It sees the CI blocker and skips integration tests for now. It applies the same 7-axis method (decision reused, not re-decided). It audits module B, finds the same naming inconsistency, and Cortex increments the pattern’s recurrence counter.

3. Session 3 — The CI team fixes the timeout. The agent marks the blocker as resolved. It runs the full test suite. The naming pattern now has recurrence 5, which triggers a recommendation to create a project convention.

At no point did the agent read raw transcripts. It read structured, typed memory entries and wrote structured entries back.