Memory

Stacklink Memory keeps useful context for your application's users. Your app can save it directly, and supported connected accounts can contribute it from the resources you select. Both use the same Memory system.

Save and retrieve

Create a session from your backend after authenticating your user. Use your own customer and user IDs consistently; the same user ID in another customer remains separate.

import { Stacklink } from '@stacklink/sdk';

const stacklink = new Stacklink({ apiKey: process.env.STACKLINK_API_KEY! });
const session = await stacklink.create({
  tenantId: 'acme',
  userId: 'user_123',
});

await session.memory.add({
  content: 'This user prefers concise weekly summaries.',
  memoryType: 'preference',
});

const context = await session.memory.context({
  query: 'How should I write this user’s weekly update?',
});

Default SDK keys include memory:read and memory:write. Add these scopes to a custom key if needed. Keep project keys on your backend. The model or browser must not decide which customer or user a request belongs to.

Identified user sessions enable Memory by default. Anonymous sessions do not. Shared customer Memory requires an explicit session grant. The dashboard's project inventory does not mean every session can read every listed memory.

Learn from a connected account

In Toolkits, connect an account and choose Learn from this account where Memory is available. The connection flow shows its source scope and history. Choose exact labels or channels when required. Defaults vary by provider.

An application's user can connect through the hosted Connect Link without having a Stacklink dashboard account. Use session.authorize(connectionRef) with the signed reference returned by tool discovery and send the user to its redirectUrl. The session already identifies the customer and user. See Connections for the authorization flow.

The account's Memory settings shows:

• What it reads and whose Memory it saves to.
• Instructions for interpreted content, such as email and conversations. Structured sources show only their supported resource controls.
• Learning status, Pause or Resume, and View memories.

Instruction changes apply to new activity; they do not rewrite old memories or restart history. New accounts copy project defaults when their sources are created. Changing project defaults does not overwrite existing accounts.

Gmail excludes Spam, Trash, Draft, Promotions and Social by provider labels before fetching the full message. Inbox is the recommended selection. Sent mail is supported when the sender matches the verified connected mailbox. A separate check must confirm that each supporting sentence was written by that sender; quoted, forwarded and uncertain statements are not saved as their own words. Unverified sending aliases are not supported. Messages too large for that complete authorship check are skipped with a reason. Newsletter and notification content outside these categories is still judged for usefulness; a message being processed does not mean a memory will be saved.

GitHub delivery Memory records terminal workflow, check and deployment events from selected repositories. GitHub does not send a webhook when a deployment becomes inactive, so that change is not immediately reflected in Memory. Each saved event shows when it was observed; use GitHub for the live deployment status.

Pause keeps saved memories available. Resume checks missed activity within the source's history setting. Stop learning clears the account's Memory opt-in and stops its source families. Saved memories, selections, exclusions and progress are kept, so turning learning back on can reuse them. Disconnecting an account also stops learning while keeping previously saved memories.

Exact saves from your app or an agent are labelled as caller assertions. They do not imply that the person named in the memory confirmed them. Corrections keep the original source in history and use the correction as the current evidence.

See and correct what was learned

Memory opens as the project's saved-context inventory. Filter by source or person only when needed. Each entry says whom it is saved for and where it came from.

Open an entry to see evidence and history. Edit saves a corrected version. Remove from Memory immediately excludes the record from normal recall, including derived profiles. Removed lets you restore it later. If one record is saved for several subjects, editing or removing that record affects all of them.

Where exact sender evidence is available, Stop learning from this sender changes future capture for that account. Removing a record alone does not create a future exclusion rule.

To inspect what your application actually receives, open Sessions → a session → Recall → Preview Memory. Preview uses the session's actual access and can correctly return nothing relevant. The full assembled context is available there.

Recall keeps pinned instructions first, then prioritizes memories matching the question before broader profiles and recent activity. A session has a default 1,600-token Memory budget. If a complete record is larger than the remaining budget, it is omitted; it is not shortened silently. Increase the session's contextTokenBudget when your agent needs large records, such as a pull request with many comments. The response reports its used budget and omitted-item count.

Use Memory from Claude or another MCP client

The existing Stacklink authorization page asks for personal Memory access when the client requests it. Read access is explicit; permission to change Memory is off by default. Personal Memory uses the same identity as your dashboard connections in the selected project. Existing clients need reauthorization to receive new permissions.

The client sees Memory when it requests the relevant tools. Stacklink does not push changed Memory into a running conversation or automatically capture all of the client's conversations. SDK framework adapters can perform recall and capture when explicitly integrated into an application you own.

Automatic capture in your own agent

Install the SDK integration for your model or agent framework to retrieve context before a turn and submit the completed conversation afterward. Keep the same wrapped client through a tool loop. For OpenAI Responses continuations using previous_response_id, the wrapper carries the original user message through intermediate tool calls. If that process has restarted, supply the full turn input instead of relying on a response ID from a previous wrapper instance.

Call flushCaptures() before exiting. It waits for submissions and throws if any submission failed or the capture queue overflowed. A successful submission means Stacklink accepted the work; extraction may still be processing. Use the session's Recall view to inspect capture status. Your application should report or retry a failed submission rather than telling the user it was remembered.

Keep application caches fresh

Use the existing project Webhooks settings for Memory events. Creation, updates, removal and erasure can invalidate your application's cached context. A stacklink.memory.record.erased event covers permanent deletion of a record and reports whether related records were also erased. Fetch fresh context after invalidation. A notification does not alter a conversation already held by an external client.

Retention and permanent deletion

Project Settings contains defaults and retention. Learned memories and stored source content have separate retention periods. The default keeps learned Memory until erased and expires full original source content after 30 days. Supporting excerpts and their speaker, page or section references stay with the memory. Older entries whose evidence already expired cannot recover that evidence. Removing a memory stops recall; permanent deletion removes its retained supporting data.

Data management separates older quarantined entries from the active inventory. Recheck entries with retained source material, confirm or correct a useful entry, or remove unwanted entries. Restoring an entry does not bypass its existing quality, sensitivity or expiry rules.

Permanent deletion is separate from Remove. Its preview shows shared records and other records derived from the same indivisible source. Legal holds can block it. After confirmation, deletion runs asynchronously; the dashboard tracks completion or failure. It reports success only when the erasure worker finishes verification.