Bot memory and context

Playbook: Grok Bot Playbook · PDF

A Grok Bot keeps its memory, files, browser sessions, and preferences between sessions. That's a big part of why it beats a chat tab: you don't re-explain your business every morning. Memory also cuts the other way. A Bot that "remembers" last month's price list will confidently use last month's prices.

In DAM — digital asset management — work I live with master vs derivative. The master is the source of truth; derivatives are useful copies that go stale. Bot memory is a derivative unless you treat it carefully. And for anything safety-adjacent — send, spend, publish — I use the same rule I use for signed artwork and shop inventory: don't trust a sticky note for the consequential number. Re-check the live system.

Good memory hygiene comes down to one question: is this fact stable, or does it change?

What belongs in memory

Use memory for stable preferences and role context — the how we work, not the current number:

• The Bot's job, name, title, and what it produces.
• Its approval boundaries ("draft replies but never send them").
• Your formatting preferences: tables with links, a short prioritized list, brief status updates.
• Tone and voice notes for drafts.
• Which sources to use for which question.

To make something last, say "remember this." For one-off instructions, just ask. The Bot doesn't need to keep those.

What does not belong in memory

Keep changing facts (prices, balances, inventory, order status) in the source system. For consequential decisions, ask the Bot to reopen the current source.

The playbook's store-ops example builds this in:

If you can't reach the store, tell me instead of using yesterday's data.

A Bot that falls back on a remembered number when a source fails is worse than one that tells you the source is down — like shipping from last week's inventory export because today's admin wouldn't load.

Correct stale assumptions directly

When something changes, tell the Bot plainly. The playbook suggests starting with "From now on…":

• "From now on, our return window is the one in the current policy doc. Check it every time."
• "From now on, route wholesale inquiries to me instead of drafting a reply."

Short, direct corrections stick better than hoping the Bot works out what changed — the way a clear process update beats a vague "things feel different."

Don't put safety rules in memory alone

Memory is a convenience, not a control. A "never send without approval" instruction in memory is good. A matching approval rule behind it is better. The sticky note is not the gate; the approval gate is.

The playbook's guidance:

• Write the boundary into the request itself. The docs call this the strongest boundary.
• Add narrow Auto Review rules, for example "ask first before sending any external email."
• Back memory-based rules with approvals rather than trusting recall alone.

Context per task: tell it what things are

Memory covers the long term. Each request still needs a little context:

• Tell the Bot what each attachment is and how to use it.
• Paste only the slice of context it needs. Whole threads "just in case" waste usage and blur the task.
• Point to the live source once instead of re-pasting data.

Skills: memory for methods

When a process works, save it as a skill: a reusable set of steps, decision rules, expected output, and safety boundaries. Skills are available across your Bots. That keeps "how we do this" out of individual chat histories and in one place you can review — more like a written SOP than a hallway rumor.

Split Bots to keep context clean

A focused Bot builds more useful context than a catch-all helper. If instructions for one job keep confusing another, that's a signal from the playbook to split them into separate Bots, each with a clean, reviewable history. Don't let the master and every derivative live in one unlabeled folder.

Go deeper

Memory hygiene is Best Practice #5 in Section 06 of the playbook. Briefing and skills are in Section 07.

• Grok Bot Playbook (web)
• Download the PDF
• Questions: jack@nextlinq.com · Nextlinq

Independent educational content by Nextlinq Solutions Inc. Not official Cursor or xAI documentation. Product details change — verify in official docs. Questions: jack@nextlinq.com

Part 4 of 10 · All notes · Usage-conscious bot design · Multi-bot teams