Skip to main content
The remember tool saves something meaningful to your team’s shared memory — a decision that was made, a status change, a key observation, or an event worth preserving. It accepts a single sentence of content and immediately acknowledges the write. Memory synthesis runs in the background, so remember returns instantly without blocking your workflow. Anything saved here becomes queryable by your whole team through ask and ask-with-history.

​
Parameters

​
Returns

​
string
Returns "Remembered." on success. Memory synthesis and indexing run in the background after this acknowledgement — the content becomes queryable within a few seconds.

​
How It Works

When you call remember, Hyper immediately acknowledges the write and returns "Remembered.". In the background, the synthesis pipeline processes the content — breaking it into indexable chunks, generating embeddings, and storing them in your workspace’s vector store. The write is non-blocking by design so it never interrupts a conversation.
remember respects your mute state. If incognito mode is active (toggled via mute), calls to remember are silently acknowledged — the tool still returns "Remembered." but no data is actually written to shared memory.

​
Example Calls

​
Technical decision with reasoning

​
Team event

​
Status change

​
Blockers

​
When to Call remember

When a HYPER BRIEFING block is present in your session context, memory capture happens automatically via the Stop lifecycle hook. You only need to call remember explicitly when the user asks you to save something specific.
Call remember when:
  • The user explicitly asks to save or record something ("remember that we decided...", "make a note that...")
  • You want to capture a decision that isn’t in the natural flow of conversation
  • Running in a client that doesn’t support lifecycle hooks
Do not call remember on your own initiative during a normal conversation with hooks configured — the Stop hook handles passive memory capture automatically.

​
Writing Good Memories

The quality of your team’s memory depends on what gets saved. A few principles: Poor: "Changed the database" Better: "Migrated the sessions table from Postgres to Redis — Postgres write latency was spiking under concurrent login load; Redis gives us sub-millisecond writes with TTL-based expiry"

​
Relationship to correct

If something already in Hyper is wrong, don’t use remember to try to overwrite it — the old memory will persist alongside the new one. Use correct instead, which finds every document containing the wrong information and applies the correction across all of them.