FlareCodeflarecode

Memory

How FlareCode learns your repos and your preferences over time, and how to review, approve, and manage what your agents remember.

FlareCode agents get smarter the more they work. Each one keeps a private, per-account memory so the next task starts further ahead than the last — something a local tool with no durable cross-session store structurally can't do. Memory is an enhancement, never a gate: if it's empty or unavailable, agents fall back to reading the repo and proceed exactly as before.

What FlareCode remembers

KindScopeWhere it comes from
Prior workPer repoEvery completed goal — its task, outcome, and PR — is remembered so similar future tasks reuse the approach and avoid past mistakes.
Repo filesPer repoA bounded index of your codebase, so the planner can surface "the files that matter" for a request before it starts.
Your preferencesYour accountConventions, constraints, and workflow habits you import from local tools — then review and approve.

Prior work and the repo-file index build up automatically as agents run. Your preferences come in through a one-time import and are only used after you approve them.

How agents use it

When an agent plans a task, it recalls the most relevant memories for that repo and your account, and folds them into its plan:

  • similar goals you've shipped on this repo before,
  • the indexed files most likely to matter for the request,
  • your approved preferences and conventions.

Recall is best-effort and time-boxed — it never blocks or slows a task. A new repo with no history simply plans from the code, the same as any first run.

Manage your memory

Open Settings → Memory in the app. There you can:

  • Review the preferences extracted from an import — each is a short, plain-English statement.
  • Approve the ones you want agents to follow. Only approved items are used in planning.
  • Reject, edit, or delete anything that's wrong or out of date.

Nothing imported is used until you approve it, and you can change your mind at any time — reject or delete an item and agents stop using it.

Privacy and isolation

  • Per-account isolation. Every memory lives in a namespace keyed to your account. A query physically cannot return another customer's memory — it's a hard boundary, not a filter you have to trust.
  • Never used for training. Your memory exists only to make your agents better at your work. It's never used to train models or shared across accounts.
  • Yours to delete. Memory is kept for the life of your account and removed when you delete it. See Data and retention.

Bring in your local preferences

If you already use Claude Code, Codex, Cursor, or VS Code, you can seed your preferences from those tools in one command — see Import local agent memory.

On this page