> ## Documentation Index
> Fetch the complete documentation index at: https://hmm.heyhyper.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# How Hyper Memory Works: Capture, Synthesize, Surface

> Learn how Hyper automatically classifies AI session context into structured facts, routes it to the right team doc, and makes it retrievable by every agent.

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.

<Steps>
  <Step title="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.

    ```text theme={null}
    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.")
    ```
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## The three core documents

Every workspace has three foundational documents that Hyper maintains automatically:

<CardGroup cols={2}>
  <Card title="org/identity.md" icon="building" href="/concepts/workspaces">
    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.
  </Card>

  <Card title="org/decisions.md" icon="scale-balanced" href="/concepts/memory">
    A living log of significant technical and product decisions, each with its rationale and the alternatives that were considered.
  </Card>

  <Card title="org/goals.md" icon="bullseye" href="/concepts/workspaces">
    Current sprint goals, quarterly priorities, and anything the team is actively working toward.
  </Card>

  <Card title="people/{name}/*.md" icon="user" href="/concepts/workspaces">
    Per-person notes about what each team member owns, is working on, and has context about.
  </Card>
</CardGroup>

## 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.

<Info>
  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.
</Info>

## What to capture — and what not to

Not everything that happens in a session is worth remembering. Apply this filter before calling `remember()`:

<Tabs>
  <Tab title="Worth capturing">
    **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

    <Accordion title="Example: high-value memory">
      ```text theme={null}
      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.
    </Accordion>
  </Tab>

  <Tab title="Not worth capturing">
    **Skip ephemeral or personal context** that doesn't help teammates or future agents:

    * Intermediate debugging steps that dead-ended
    * Personal preferences with no team impact
    * Information already available in version control, tickets, or linked docs
    * Repetition of something already in memory (use `correct()` instead if it's wrong)

    <Accordion title="Example: low-value memory">
      ```text theme={null}
      remember("Decided to use Supabase for auth")
      ```

      This is technically accurate but nearly useless. A future agent reading it has no idea why Supabase was chosen, what was rejected, or what constraints to keep in mind. It wastes 2,000 tokens to record almost no signal.
    </Accordion>
  </Tab>
</Tabs>

## 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:

```text theme={null}
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.

<Warning>
  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.
</Warning>

## 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:

```text theme={null}
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.

<Tip>
  You can also enable incognito mode from the Hyper desktop app's menu bar icon without touching your AI client at all.
</Tip>
