Skip to main content
Memory must be enabled for your organization. Memory generation and memory recall are controlled separately. Contact your Gradial team to confirm availability and setup.
Every thread your team completes produces knowledge: the decision you made about a component, the workaround for a stubborn template, the tone your legal team signed off on. Normally that knowledge stays locked inside the thread that produced it — and the next person to do similar work starts from scratch. Memory changes that. Completed work in a workspace contributes to a structured memory bank that Grady can draw on in later threads, so teams don’t have to re-explain the same context every time.

​
What Memory does

When Memory is enabled, Grady receives relevant workspace knowledge as part of its context on a new request. In practice that means:
  • You can point at past work — “the approach we used on the launch page QA” — instead of re-describing it.
  • Decisions and workarounds established in earlier threads carry forward rather than being rediscovered.
  • Grady’s starting point on a new request reflects how your workspace actually works, not just the prompt in front of it.
Memory is workspace-scoped. Knowledge from one workspace does not leak into another.

​
How Memory is built

Memory is not raw chat history. Gradial synthesizes each completed thread into a summary, then consolidates those per-thread summaries into a workspace-level memory bank. Grady reads from that consolidated bank rather than replaying old conversations. Memory records can preserve the name of the person whose work produced the remembered context, so teams can see whose decision is being carried forward — not just what was decided.
Memory generation (synthesis) and memory recall are separate controls. A workspace can be building memory before recall is switched on, which means recall requires an existing, non-empty workspace memory before it has anything to draw from.

​
Seeing where a memory came from

When Grady uses a memory from another thread, you’ll see it in the References panel on the right side of the thread. References shows a flat, deduplicated list of the source threads behind memory citations, and each entry is a clickable link back to the thread that generated the finding. That means you can always check the original source yourself rather than taking a recalled claim on faith. Source threads appear only when you’re allowed to see them. If a memory traces back to a thread outside your visibility, the link isn’t surfaced — Memory never becomes a side channel into work you don’t have access to.

​
Reliability

If memory hydration is unavailable when a turn starts, the turn continues without memory rather than failing the thread. You may get a result that lacks earlier context, but the work itself still runs.

​
Current limitations

  • Memory generation and recall are enabled separately.
  • Recall requires existing workspace memory — a brand-new workspace has nothing to recall yet.
  • There is no customer-facing memory editor in this release. You can’t directly browse, edit, or delete individual memory records.
  • No aggregate memory analytics ship in this release.
  • Source-thread links appear only when a visible source thread can be resolved.
  • Memory shapes how Grady approaches a request. It informs behavior — it does not guarantee a specific answer.