Grok can finally remember what you're building
Observational Memory gives your agents one shared, local memory, and its monthly installs have climbed from a couple hundred to around 1,600 this year. Now Grok Build gets it too — a one-line plugin and plain-Markdown memory, so Grok wakes up knowing what Claude Code and Codex already learned.
Every new Grok session used to start the same way: from nothing. You re-explain the repo, the constraint you settled on yesterday, the line you already decided not to cross. The agent is sharp, but it wakes up with amnesia, and you pay the re-briefing tax every single time.
That tax is exactly what Observational Memory removes. As of this week, it removes it for Grok Build too.
What your agent gets
Observational Memory — om for short — is one shared memory that lives on your machine as plain Markdown you can open, read, grep, and back up. It watches what your agents do, distills it into a compact notebook, and hands every new session a short briefing: who you are, how you work, and what you were in the middle of. The decision Claude Code made this morning is in the notebook when Grok opens this afternoon.
That notebook is already shared across Claude Code, Codex, Claude Cowork, and Hermes — switch tools without re-explaining yourself. om's monthly installs have climbed from a couple hundred at the start of the year to around 1,600, and the line keeps going up. Until this week, Grok users got only half the picture: Grok sessions could write into the shared notebook, but they couldn't read from it. grok-observational-memory closes that gap. Same notebook, same continuity, one line to install.
Try it in one line
grok plugin install intertwine/grok-observational-memory --trust
You'll need the om CLI on your machine too — uv tool install observational-memory (or pipx install observational-memory). Then run /om-setup inside Grok. It explains every file it will touch and stops for your confirmation before writing anything; it never installs om behind your back.
From then on your Grok sessions carry context, and four slash commands put the notebook at your fingertips:
/recallsearches your memory from inside a Grok session./memory-statusshows what Grok currently knows and when it last refreshed./om-setupand/om-teardowninstall the plugin or remove every trace of it, zero residue.
It is MIT-licensed. The memory is plain Markdown you own — never an opaque store, never silently uploaded. Hook scripts always exit 0, so a memory hiccup never blocks a session, and they never print memory content, so nothing private leaks into a log. One environment variable, OM_GROK_PLUGIN_DISABLE=1, stands the whole thing down. Behind it sit 88 tests and shellcheck-clean POSIX shell.
The honest part
Getting here took a detour worth one section. When we first wired om into Grok back in May, we did it the obvious way: a session-start hook that prints the briefing. Then we probed Grok 0.2.50 live and found the briefing was going nowhere. Grok runs hooks but discards their output on this build, so the read side was a silent no-op — and nobody could tell from the outside, which is exactly the failure a memory system is supposed to refuse.
So the plugin routes around it. Grok does reliably inject one file into every session — ~/.grok/AGENTS.md — so om writes its briefing there, inside a clearly-marked managed block that never touches anything you wrote yourself, and regenerates it fail-closed: if om context can't produce a brief, the block is left alone rather than replaced with a stale guess. The one honest catch is timing. Grok reads that file before hooks run, so the freshest block is the one the previous session wrote — a one-session lag. For memory shared across agents and across hours, that is fine; the decision from this morning is there this afternoon. The plugin refreshes from three sides to keep it converging, including a throttled per-prompt refresh for headless sessions that never fire a clean session-end.
The plugin also already ships the hooks it will use the day Grok runs plugin hooks directly; until then it leans on the channel that works, and the forward-compatible path suppresses itself so the same work never runs twice. The marketplace submission is in and validator-clean — submitted, not yet accepted; xAI has not reviewed it. You do not have to wait for that, because Grok Build installs straight from GitHub today.
Now Grok can read the notebook
The line I keep drawing in this series is the same one: local continuity first, product-specific bridges second, reviewable memory everywhere. The notebook was already on your machine, shared by Claude Code, Codex, Cowork, and Hermes. Now Grok can read it too — and if xAI ships it in the marketplace, that is icing on a plugin that already works.
The plugin is here: grok-observational-memory. Install it today with grok plugin install intertwine/grok-observational-memory --trust.