Skip to main content
Pioneer has durable agent memory for facts and preferences that remain useful after the current turn. Examples include your name, long-lived preferences, recurring instructions, communication style, and project decisions. Memory is enabled by default. You can control it from Settings > Memory in the desktop app. Pioneer has two continuity layers:
  • Durable memory remembers long-lived facts and decisions that should survive across threads.
  • Thread context indexes visible conversation history so Pioneer can search older discussion snippets when the current turn needs them.
They work together, but they are not the same thing. Your name belongs in durable memory. A question like “what did you say earlier in this thread about the API design?” belongs to thread context.

What memory does

When memory is enabled, Pioneer can:
  • recall saved facts when they are relevant to the current request;
  • include a compact memory section in the model prompt;
  • register memory tools in agent mode when the selected model/provider supports tools, with actual visibility selected by preflight or request_tools;
  • proactively extract high-confidence durable facts after a successful turn;
  • search indexed thread context when a turn needs older conversation snippets;
  • forget memory when explicitly asked.
Memory does not preserve every past token. Durable memory stores selected facts. Thread context searches indexed conversation fragments within a bounded budget, so Pioneer can recover useful prior discussion without adding whole transcripts to every prompt.

Recall

Pioneer uses two recall paths: The recalled results are treated as context, not as instructions. Your current message wins if it conflicts with memory.

Thread context

Thread context is the part that helps with follow-up questions like “what did we decide earlier?” or “show me the API plan from yesterday.” Pioneer indexes visible user and assistant conversation items into a separate episodic store and can recall matching snippets later. This is deliberately separate from durable memory:
  • it can include old discussion snippets that are not worth saving as permanent facts;
  • it is searched only when the turn needs context;
  • it is bounded by ranking, prompt budgets, and workspace/thread filters;
  • it does not turn every chat message into permanent user memory.
If an old message had file attachments, recalled snippets can include compact artifact references next to the snippet. The model can request the artifact domain and call artifact_read only when it actually needs the file content. That avoids re-attaching old photos, PDFs, or logs to every future turn.

Embedding models and recovery

Thread context search uses an embedding model when vector search is enabled. Pioneer can use a configured remote embedding provider or a local model. In Settings > Memory, local model installation exposes download and preparation progress, so you can tell whether the model is ready before relying on semantic search. Indexing is resumable. If the gateway restarts, an embedding provider temporarily fails, or a refill is interrupted, Pioneer keeps completed work and resumes the unfinished jobs instead of rebuilding the entire index. Failed jobs and interrupted jobs are tracked separately, and recoverable provider or storage errors are retried according to the gateway’s retry policy.

Proactive writes

After a successful agent turn, Pioneer may run a post-turn extractor. The extractor can propose durable facts, but the memory service still decides what becomes active memory. High-confidence durable facts can be stored automatically. Extremely weak, transient, secret-like, or low-quality facts are rejected or suppressed. Medium-confidence facts are currently rejected or suppressed until a user review experience exists. Pioneer does not rely on fixed phrases or one language to decide what can become memory. The extractor and quality gate use structured semantic fields, local validation, scoring, dedupe, and policy checks.

What is not stored

Pioneer should not store:
  • passwords, API keys, tokens, credentials, or raw secrets;
  • one-off commands;
  • temporary debugging state;
  • raw logs;
  • guesses or uncertain claims;
  • facts that only belong to a single short-lived task;
  • sensitive regulated information unless explicitly allowed and policy permits it.

Opt out

You can disable memory from Settings > Memory. The main controls are: These are gateway settings. The desktop app reads and updates them through the gateway settings API, so the controls apply to the gateway you are currently connected to. If you switch to another gateway, the settings screen reloads that gateway’s values instead of reusing local desktop state. The Preflight model selector lives in Settings > General because preflight is system-wide. It is used by turn preflight, including active recall planning when memory asks preflight for a provider decision. You can also tell Pioneer not to use or save memory for a specific turn. Per-turn opt-out is handled by memory policy; it should disable inferred writes and recall use for that turn except when the request is explicitly to forget memory.

Limits

Memory helps with continuity, but it has limits:
  • not every useful fact is guaranteed to be saved;
  • not every saved fact is guaranteed to be recalled on every relevant turn;
  • thread-context recall is searchable and bounded, not a legal-grade full transcript replay;
  • candidate review APIs exist, but there is no default user-facing review queue yet.
Use memory for durable context, not as the only record of important work.

Further reading

  • Memory Architecture explains scopes, provenance, candidates, quality gates, and memvid-backed storage.
  • Thread Episodic Context explains searchable conversation-history recall.
  • Agent Loop explains where recall, tools, and post-turn extraction fit into a turn.