Skip to main content
Memory is the core of what Hyper does. When an agent finishes a session, Hyper doesn’t just log a transcript — it reads the conversation, extracts what matters, classifies it, and writes a synthesized entry into the right team document. The next agent that connects gets that knowledge automatically, without anyone copying notes into a wiki or summarizing Slack threads by hand.

​
How memory flows

Every memory starts as raw context — a decision made, a fact established, a status updated — and goes through a four-stage pipeline before it’s retrievable.
1

Capture

An agent calls remember(content) with a string describing what happened. This can be a decision, a rationale, a status change, a discovered constraint — anything worth preserving. The content doesn’t need to be formatted; Hyper handles the structure.
remember("Switched from REST to tRPC for the internal API — decision driven by
end-to-end type safety across the monorepo. Evaluated GraphQL but ruled it out
due to tooling complexity for a team this size.")
2

Classify

Hyper’s server reads the content and determines which document it belongs in. Is this about the organization’s identity? A past decision? A current goal? A person’s area of work? The classifier routes it accordingly without any manual tagging.
3

Synthesize

Rather than appending raw text, Hyper merges the new memory with existing content in the target document. An LLM rewrites the relevant section to incorporate the new information naturally — no duplicate entries, no contradictions left dangling.
4

Surface

When the next agent calls connect() or ask(), Hyper retrieves the relevant synthesized content and delivers it as part of the briefing or query response. The agent gets grounded, up-to-date context with no extra prompting from you.

​
The three core documents

Every workspace has three foundational documents that Hyper maintains automatically:

org/identity.md

Who you are as an organization: your product, your stack, your guiding principles. This is the first thing a new agent reads to get oriented.

org/decisions.md

A living log of significant technical and product decisions, each with its rationale and the alternatives that were considered.

org/goals.md

Current sprint goals, quarterly priorities, and anything the team is actively working toward.

people/{name}/*.md

Per-person notes about what each team member owns, is working on, and has context about.

​
How memory is stored and retrieved

Hyper stores everything you capture as searchable, structured knowledge. When you call remember(), the content is indexed so it can be found later by meaning — not just by keyword. That means asking “what auth library are we using?” will surface a memory written as “we chose Supabase because of its built-in RLS support,” even though the words don’t match exactly. Memories are also deduplicated and merged: if you record the same fact twice, Hyper combines them rather than storing two separate entries. If something changes, use correct() to update it everywhere at once.
Token costs are straightforward: recording a memory costs 2,000 tokens, and retrieving one costs 500 tokens. Write thoughtfully — a well-written memory that captures a decision and its rationale is worth far more than several shallow entries about the same topic.

​
What to capture — and what not to

Not everything that happens in a session is worth remembering. Apply this filter before calling remember():
Capture team-relevant context that future agents — or future you — will need to understand a decision or pick up a task:
  • Decisions with rationale — not just what you chose, but why, and what you ruled out
  • Architecture and stack choices — especially when they carry constraints others need to know
  • Blocking issues and resolutions — what was broken, what fixed it
  • Status changes — when something ships, stalls, or gets deprioritized
  • Discovered constraints — a third-party API rate limit, a DB schema limitation, a compliance requirement
remember("Decided to use Supabase for auth — need RLS for multi-tenant
isolation. Evaluated Firebase Auth (no RLS, would require app-layer tenant
checks) and custom JWT (too much maintenance). Supabase chosen for built-in
RLS + Postgres alignment with our existing DB.")
This memory is valuable because it captures the decision, the reason, and the alternatives — everything a future agent needs to understand the choice without re-litigating it.

​
Correcting wrong memories

When you discover that something in your workspace memory is incorrect or outdated, do not call remember() with the corrected version — that creates a contradiction Hyper has to resolve. Use correct() instead: 
correct("We are not using Supabase for auth. We migrated to Firebase Auth in
May 2025 after Supabase's RLS performance degraded at our write volume.")
The correct() tool finds every document that contains the outdated information and applies the correction to each one, so the truth is consistent everywhere in your workspace.
Using remember() to override a wrong memory instead of correct() can result in conflicting entries that confuse future agents. Always use correct() when something is factually wrong.

​
Incognito mode

Sometimes you’re exploring something sensitive — a speculative architecture, a personnel decision, a competitive analysis — and you don’t want the session written to shared memory. Call mute() to pause all memory writes for your current session: 
mute()
While muted, remember() and correct() calls are silently dropped. The ask() tool still works — you can query memory without writing to it. Call mute() again to toggle writes back on.
You can also enable incognito mode from the Hyper desktop app’s menu bar icon without touching your AI client at all.