Memory in Grok Build: xAI Adds Persistent Project Notes to Its Coding Agent

Grok Build now has memory. xAI announced that its coding agent keeps notes on the conventions, decisions, and project facts that come up during work, and that later sessions read those notes before touching related code — the stated effect being that "Grok Build gets better the more you use it."

What was announced

Grok Build's memory feature captures durable information from completed work turns and replays it into future sessions on the same project. Capture is automatic and runs in the background, so it does not interrupt or block an active session.

The feature ships with two new slash commands, /memory and /dream, and is available in Grok Build now.

Capture runs after the turn completes

Memory capture is triggered by turn completion, not by explicit user action. After a turn finishes, Grok reviews it in the background and records anything durable: conventions, decisions, and project facts. xAI states that capture runs on every completed turn and does not interrupt the session.

This design means the user does not have to decide what is worth remembering. The agent makes that judgment after the fact, off the critical path of the conversation.

What Grok Build remembers — and what it deliberately does not

Memory is scoped to the details xAI considers most likely to matter in a later session:

  • How the team writes and reviews code — coding conventions and review practices.
  • Decisions and the reasoning behind them — not just what was chosen, but why.
  • Durable facts about the project — for example, where a subsystem lives, or which command runs the test suite.

Equally important is the exclusion list. Grok Build leaves out:

  • Task state
  • Tentative conclusions
  • Secrets
  • Anything the repository or its documentation already covers

That last exclusion is a deliberate anti-duplication rule: memory is meant to hold what the codebase itself does not already state.

Memory is scoped per project, plus a global set

Notes are kept per project, with an additional global set for preferences that apply everywhere. This gives the feature two layers: project-specific knowledge that travels with a repository, and cross-project preferences that follow the user.

Notes are written in the background, then folded into topic files

Capture never blocks the session. Grok reviews the finished turn, writes anything worth keeping as a markdown note, and continues.

Over time, the /dream command folds those notes into topic files — one file per subject — so each project ends up with a small set of organized references rather than an ever-growing pile of raw notes. xAI gives topics/testing.md as an example of the resulting structure. Dream also runs on its own periodically in the background, so organization does not depend on the user invoking it.

Retrieval is scoped to the area being worked on

When a user returns to a project, Grok reads the topics that cover the area it is about to work in. Retrieval is therefore targeted rather than a full dump of everything remembered.

xAI specifies a precedence rule for conflicts: instructions in the current conversation take precedence over anything in a note. Memory is context, not an override of live user direction.

Browsing and editing memory

/memory opens a read-only browser of every memory file, grouped by scope, with a preview of the selected file. xAI describes it as the fastest way to see what a session produced and to locate the file to edit when a note is wrong — implying that memory files are editable markdown, even though the browser itself is read-only.

The two new commands

  • /memory — opens the read-only memory browser, grouped by scope, with a file preview.
  • /dream — organizes recent notes into topic files, for example topics/testing.md. Dream also runs periodically on its own in the background.

Availability

Memory is available in Grok Build now. It applies to new sessions: run /new or start a fresh grok, and notes begin after the first completed turn.

Why this matters

Grok Build's memory is a persistent, project-scoped knowledge layer for a coding agent, built around three design choices that distinguish it from simple conversation history:

  1. Capture is post-turn and asynchronous, so remembering never costs the user latency during a session.
  2. Storage is human-readable markdown organized into topic files, so the memory is inspectable and correctable rather than opaque.
  3. Retrieval is scoped to the relevant area and subordinate to live instructions, so stale notes cannot silently override what the user says in the current conversation.

The practical claim xAI makes is cumulative improvement: the more a project is worked on with Grok Build, the more context the agent carries into subsequent sessions on that project.

Sources