StrataGate-AgentMemory

StrataGate

Recent conversations stay detailed. Older memories grow more concise.

StrataGate is a cross-session memory plugin for DeepSeek Harness. Recent conversations stay detailed, older conversations become concise, and original records remain available when needed. Important decisions, preferences, and plans become long-term memories for future sessions.

中文说明 · DeepSeek Harness guide · Architecture · Full evaluation

Published evaluation: on 152 questions from one LoCoMo conversation, conv-26, each answer received 10 independent evaluations. Mean judged accuracy was 80.46%, versus 63.22% for Mem0 base. See evaluation scope.

Why StrataGate?

1. Short-term memory: details fade as the conversation progresses and expand when needed.

(1) Recent history stays detailed; older history becomes concise. Each conversation block has six views, L0–L5, with different levels of detail. As more conversation accumulates, older memories gradually shift from full dialogue to key facts, short summaries, and title indexes, reducing the context occupied by history. → Layered memory

(2) Views shrink while original records remain. Complete L5 source messages and tool records are preserved. When details need checking, the agent can expand a memory to recover the original wording and context. → Layered memory

1. Long-term memory: an event timeline preserves history, while a knowledge graph organizes current state.

(1) Events record what happened. Important decisions, preferences, plans, and changes are extracted from conversations as Events. Each retains its source and distinguishes when something was mentioned from when it happened, so future sessions can retrieve and trace it. → Event cards

(2) The knowledge graph represents current state. Historical Events provide the basis for current information and relationships about people, projects, organizations, tools, and places. New Events can supplement or supersede an earlier state while historical Events and their sources remain preserved. → Current-state graph

(3) Long-term weights decay too. As conversations progress, memories that have not been adopted gradually lose weight, affecting their priority during retrieval and automatic recall. Their sources remain available for verification even after their weights decay. → Weights and adoption-based reinforcement

(4) Bring memories from other AIs. Imported content can become traceable Events and update the knowledge graph while the original imported text remains preserved. → External memory import

1. Evidence gate: check whether retrieved evidence is sufficient before answering.

A relevant search result may still be insufficient to answer the question. The agent assesses the evidence and, when needed, searches again, expands Events, or checks the original messages. If it still cannot confirm the answer, it states the uncertainty. → Evidence gate

1. Reinforce only memories actually used.

Search hits and automatic context injection do not trigger reinforcement. Only evidence recorded as actually used in the final answer increases the adoption count and resets the decay anchor. More adoptions mean slower future decay, preventing a memory from reinforcing itself merely because it is frequently retrieved. → Use-only reinforcement

Get started: → Quick start

Quick start: DeepSeek Harness

If DeepSeek Harness is already installed, add StrataGate to the profile you use:

dsh plugin --profile web add stratagate-dsh

DSH compatibility includes the complete 0.2.0 version family: all Alpha, Beta, RC, and stable releases (>=0.2.0-0 <0.2.1-0), alongside the previously supported hosts. A new 0.2.0 prerelease does not require a plugin update just to declare its version.

Restart that profile, then keep using DSH normally. StrataGate will capture completed main-agent turns, build searchable memory in the background, and expose its Memory UI under DSH Settings → StrataGate-AgentMemory.

By default, the database is stored at:

DSH_HOME/stratagate/memory.db

Removing the plugin does not delete the database. For screenshots, configuration, memory tools, and the exact automatic-capture rules, see the DeepSeek Harness plugin guide.

The command uses the web profile; replace web if you use another profile. Developers can go directly to Development and documentation.

How it works

1. Save conversations. Several consecutive turns form a memory Block, stored as six views ranging from an index to the original records.
2. Extract lasting information. Decisions, preferences, plans, and changes become Events with time and source references. The graph builds a current-state view from these Events.
3. Recall when answering. The plugin brings in a small set of relevant memories. When more information is needed, the agent searches Events, the graph, or source messages and assesses whether the evidence is enough.
4. Record actual use. An Event selected as evidence for the final answer counts as a recorded use, called an “adoption” internally, and updates its long-term weight.

Automatic recall currently includes at most 4 Events and 4 graph nodes within approximately 900 tokens. Layered Blocks and unsealed turns supply the active conversation's history separately.

Core design

Mechanism · What changes · What remains Short-term simplification · Which L0–L5 view an older Block displays by default · Original L5 conversations and tool records Long-term weight decay · An Event's priority in later recall · Event history and its sources

Both follow conversation progress: short-term decay uses ready-Block distance, while long-term decay uses turn distance. Elapsed days alone do not trigger either form of decay.

1. Short-term memory: gradually condense older conversations and expand them when needed

Recent discussions usually need their full detail. Older conversations can remain in context as concise views. StrataGate stores several levels of detail for the same conversation block and gradually reduces what older Blocks display by default as more conversation accumulates.

One conversation block, six levels of detail.

The DeepSeek Harness plugin seals a Block every 6 complete turns by default. A turn consists of a user question and the assistant's complete response. The Block size is configurable; the core-library default is 12 turns. Content below the boundary remains in the current conversation.

Each fully processed Block contains these views:

Level · Contents · Primary use L0 · Title and tags · Identify a piece of history with minimal context L1 · Short summary · Understand the discussion's topic L2 · Key facts · Review decisions, constraints, plans, and outcomes L3 · Deterministically condensed dialogue · Remove standalone fillers from a fixed allowlist; keep only the first duplicate long or code-like paragraph; retain tool names and result summaries L4 · Near-verbatim dialogue without internal messages · Remove system messages; only trim outer whitespace and add role labels to user and assistant text; retain names and summaries for recognized tool records L5 · Source messages and tool records · Verify provenance and specific details

The model summarizes L0–L2. Fixed rules generate L3/L4: L3 removes standalone fillers and repeated long content, while L4 stays near-verbatim; both compact recognized tool records. Short-term decay advances with subsequent ready Blocks, not elapsed days.

Exact pruning rules, decay formula, and level thresholds

The model produces L0–L2 summaries. L3 and L4 do not use model paraphrasing; code generates them with these fixed rules:

• L4: Remove system messages. User and assistant text is preserved except for trimming outer whitespace and adding User, Assistant, or other role labels. Recognized structured tool records retain the tool name and a result summary of at most 160 characters while omitting raw arguments, params, input, and request fields. Tool-role text that is not recognized as tool JSON remains unchanged.
• L3: Condense further without semantic rewriting. A sentence is removed only when, after trailing punctuation is stripped, it exactly matches a fixed filler allowlist such as ok, thanks, got it, 好的, 明白, 收到, 谢谢, or 可以. After whitespace normalization and case folding, code-like paragraphs and paragraphs of at least 80 characters are deduplicated: the first copy remains verbatim, and later exact duplicates become an omission marker. Tool records use the same name-and-result-summary form as L4.
• Length guard: If generated L4 would be longer than L5, L5 is used instead. If L3 would be longer than L4, L4 is used instead, preserving L3 ≤ L4 ≤ L5.

Source records are saved first, followed by summarization and Event processing. Only a fully processed, ready Block can replace its corresponding native history and participate in decay.

As more conversation accumulates, older Blocks default to less detail.

Display changes follow exponential decay:

The default decay coefficient λblock is 0.30. Code maps weight ranges to display levels. Smaller coefficients preserve detail for longer and therefore consume more context.

In this formula, age is the distance between the current display anchor and the latest ready Block in the same conversation. It measures conversation progress, not elapsed calendar days. Unsealed turns and Blocks still awaiting model processing do not advance this decay.

For a Block that starts at L5 and is never expanded again, the default schedule is:

Additional ready Blocks · Default display level 0–1 · L5 2 · L4 3–4 · L3 5–6 · L2 7–8 · L1 9 or more · L0

The figure illustrates the trend. Actual changes depend on both the decay coefficient and level thresholds; a new Block does not necessarily cause a one-level drop.

Expand again when details are needed.

Suppose an older conversation currently shows only:

Discussed the project's technical approach and near-term plans.

If the user asks why pnpm was chosen, the agent can expand key facts, condensed dialogue, or the complete source records to find the original reason.

Expansion can proceed one level at a time or jump directly to a requested level. The selected level and current Block position become the new decay anchor. As subsequent conversation accumulates, the view gradually becomes concise again.

Older conversations can therefore remain lightweight during ordinary use while retaining recoverable detail. L0–L4 are derived views of the source and never overwrite L5.

2. Long-term memory: preserve history in Events and organize current state in a knowledge graph

Short-term memory retains a discussion's context. Long-term memory extracts information worth using in future sessions. StrataGate records decisions, preferences, plans, and changes as Events, then uses those Events to organize a knowledge graph.

Event cards record what happened and retain their sources.

A Block can produce multiple Events or contain no information that needs long-term extraction. In addition to content, each Event retains its source Block, source messages, and whatever temporal information can be established.

Two different time axes must be distinguished:

Time · Meaning Mention time · When the conversation referred to the event Occurrence time · When the event happened or is planned to happen

If a user says “Finish the prototype next week” on May 6, May 6 is the mention date, while “next week” describes the planned completion time. The record should retain its planned status and cannot serve as evidence that the prototype is already complete.

When a date cannot be established, the original wording and uncertainty remain available for later source verification.

New Events update memory through additions, supersession, or conflicts.

A project discussion might contain these statements over time:

“Use npm for this project.”

“Let's switch to pnpm.”

“Finish the prototype next week.”

They play different roles:

• Switching to pnpm updates the package-manager choice; the earlier npm Event remains in history.
• Finishing the prototype next week adds a plan without changing the package-manager decision.
• If statements cannot both be true and their validity cannot yet be resolved, a conflict relationship is retained for later verification.

New Events do not overwrite the content or provenance of earlier Events. Their validity status and relationships can change as new evidence arrives. This lets the system retrieve current information while also explaining what used to be true and what changed.

The knowledge graph organizes current information and relationships from Events.

People, projects, organizations, tools, and places become nodes. Connections such as “uses,” “participates in,” and “depends on” become directed edges. Both node attributes and relationships retain their source Events.

In the example, the graph can update the project's current package manager to pnpm while preserving npm as a historical state. Later:

• a question about what the project uses can start with the current graph;
• a question about when it changed can inspect the change Event;
• a question about why it changed can expand the Event and return to the original discussion.

Graph state must be supported by its sources. “Finish the prototype next week” directly supports a plan. The figure's “prototype in development” state and owner information require additional supporting Events.

Graph updates run as independent jobs with persisted progress. A failed update can be retried separately while the committed Events and source records remain available.