Memory System
Give the AI full context of your game with a project knowledge graph.
The Memory system gives AI full context of your game. It scans your project and builds a knowledge graph for smarter, more relevant assistance.
How Memory Works Under the Hood
Memory is built on two layers that work together: a small, always-on orientation that every AI message starts with, and a larger investigation graph the AI queries only when it needs to dig deeper. This keeps routine context cheap while still giving the AI the full picture on demand.
Layer 1 — Always-on orientation
Every message you send to the AI is prepended with a compact (~2–3k token) orientation blob. It carries a project overview, the hierarchy skeleton, your confirmed "Systems," and an active-context line. The guiding principle is "memory is the map, not the territory" — it orients the AI but never quotes live source, so context stays cheap and never drifts out of sync with your actual code.
Layer 2 — On-demand investigation graph
Behind the orientation sits a relationship graph — events, module require edges, and function-call edges — that the AI queries through a fixed set of tools only when a task actually needs it:
- •
find_scripts_for— locate the scripts relevant to a given instance, system, or question - •
get_relations— return the relationships connected to a specific node - •
find_event_flow— trace how a RemoteEvent or BindableEvent flows through the game - •
search_memory— free-text search across everything that's been indexed - •
trace_function— follow a function through its definition, callers, and callees - •
get_callers— list everything that invokes a given function
Systems
During a scan the AI proposes groupings of related scripts and instances, called Systems. You confirm or reject these in the Memory tab, and the ones you keep feed back into the orientation blob — so every future message starts with an accurate picture of how your game is organized.
Per-session project gate
No project is assumed at startup. Each session you pick the active project in the Memory tab before working — feed nothing over feed wrong — so the AI never reasons against stale memory from a different project.
All of this lives locally under your project folder, and you stay in control: any time the AI wants to write to memory, it asks for your confirmation first.
How It Works
When you scan your project, HyperDevs analyzes:
What Gets Scanned
- • Entire game hierarchy
- • All scripts and their contents
- • Instance names and organization
- • Service dependencies
- • Asset references
What AI Learns
- • Your game's architecture
- • Coding patterns and style
- • Common scripts you use
- • How parts are organized
- • Your project's unique patterns
Quick Scan vs Deep Scan
Quick Scan
Scans in ~10 seconds. Good for getting basic project structure.
Use when: You want quick context or made minor changes.
Deep Scan
Scans in ~30-60 seconds. Analyzes all scripts in detail.
Use when: Starting a session, after major changes, or for complex tasks.
Tree, Graph & Context Views
The Memory tab lets you explore your project three ways. The index combines a relationship graph, the raw source blobs, and code structure (AST) so the AI has rich, accurate context for every task.
The Three Views
- • Tree: Your game's hierarchy — instances, scripts, and UI, organized like the Studio Explorer
- • Graph: An interconnected map of how scripts, objects, and systems reference each other
- • Context: The surrounding details the AI weighs for the task at hand
Tip: scanning requires an active Roblox Studio connection. Very large projects are gated to keep the views responsive.