Grok Bot memory is kept per Bot: each Bot keeps its own memory (stable preferences, important facts, summaries of its work) and its own conversation, while all of your Bots share one cloud computer with its files, logins and one skills library. Sharing a Bot gives the other person a copy without your history or learned memory, and a Team Bot shares only the facts someone marks for the whole team. Grok Bots are our daily agents at Tokenrip, more than any other personal agent we've tried, so this post has the docs and how we actually run them. Docs checked 2026-10-21.
What does a Grok Bot remember, and is it permanent?
A Bot's memory lasts across sessions but isn't a full record. xAI says "A named Bot keeps its memory, files, browser sessions, and preferences across sessions instead of resetting on every task" (overview), and that it "can retain stable working preferences, important facts, and summaries from its work" (Bot docs). It keeps the gist, not a transcript. So if a Bot seems to have a bad memory for details, that matches what it's built to keep, and for consequential decisions xAI says to "ask the Bot to check the current source instead of relying on memory." The docs describe no control to view or reset one Bot's memory; you correct stale assumptions directly.
Grok Bot is x.ai's app for "your team of always-on agents" (x.ai), launched in beta on August 11, 2026 on desktop and mobile, with the Bots running on computers in Cursor's cloud.
Do Grok Bots share memory with each other?
No. Conversations and learned context stay separate per Bot, but every Bot on your account shares the same computer (computer and apps): files in /workspace, browser sessions and command-line credentials, account-wide connectors, and one skills library. Routines belong to one Bot. Bots pass context through direct messages, group chats and those shared files.
The catch is inside one Bot: its saved memories belong to the Bot, not to one chat. One user reported that "progress from one project shows up in the other bot/chat" (Cursor forum), and a Cursor staff member replied that memories belong to the Bot, advised one Bot per project, and said chat-scoped memory is in the works.
Why we run one Bot per job
That staff advice is how we'd set it up anyway, and it's the reason Grok Bot beat dots for us. We'd been impressed with dots first; being able to call it and just talk, and have it go research a thing and save the findings and follow-ups to our workspace, was the first time a personal agent felt like a colleague. Then the same voice worked in Grok Bot, and Grok Bot had the thing dots didn't: a Bot built for one job, with only the context that job needs. One Bot does research. One drafts posts. One reads the news. One does deployments. On the personal side there's one for finances and one that's been handling visa paperwork. None of them is carrying the others' memory around, so none of them bloats, and none of them applies something it learned on one project to another. That's the memory design we wanted and never got from auto memory in a coding tool, and it fell out of just making more Bots.
What happens to memory when you share a Bot or use Team Bots?
Sharing a personal Bot makes a copy. "Adding a shared Bot creates a copy on the recipient's account" and "does not give them your computer, logins, or conversation history" (Bot docs); copies "do not carry over live memory or conversation history" (Cursor forum). The share link exposes the Bot's description, skills and routines, so strip secrets first.
Team Bots, in public beta since September 28, 2026 on Teams and Enterprise (x.ai), are "one Bot that your whole team talks to" (Team Bots docs). Conversations are private in both directions, team memory is shared but the Bot saves a fact there only when someone says the whole team should have it, and a remote MCP server uses the Bot's own credential, or each person's sign-in under OAuth, with secrets encrypted and hidden from teammates.
How do you add a custom MCP server to Grok Bot?
Tell the Bot to add it. There's no settings form; a Cursor team member wrote "just tell your bot to add your MCP server" (Cursor forum). The server must be a public HTTPS URL using Streamable HTTP or SSE, because the Bot runs in the cloud. Two known problems: Grok Bot registers a cursor:// OAuth redirect that some providers reject, which Cursor staff said on September 25 was on their side and tracked, with no fix shown as of October 21 (forum); and staff said personal Bots have no safe way to set a custom HTTP header holding a secret, so personal-Bot connectors authenticate through OAuth only.
| What you need | What Grok Bot does natively | Gap |
|---|---|---|
| A Bot that remembers your preferences | Yes, per Bot | No documented view or reset of one Bot's memory |
| Separate context per project | One memory per Bot, across its chats | Projects on one Bot overlap; use one Bot per job |
| Files every Bot can use | /workspace on the shared computer |
Only your account's Bots see it |
| A teammate uses the same Bot | Team Bots (Teams and Enterprise) | Copies of personal Bots carry no memory |
| Claude, ChatGPT or Codex read its work | No native bridge | A custom MCP server |
If every agent you use is a Grok Bot on one account, the native tools go a long way: one Bot per project, lasting rules in the Bot description (which the docs reserve "for rules that should remain true"), project notes as files in /workspace that each Bot reads first and updates last, and a Team Bot on a Teams or Enterprise plan. It stops at the account boundary. A co-founder on their own subscription, a contractor, or your Claude and Codex agents can't read /workspace.
How our Bots talk to everything else
Every one of our Bots is connected to the same Tokenrip workspace our Claude Codes, ChatGPT and the rest load. That's the half of the setup the Bots don't give you on their own, and it's what turns a set of single-job Bots into a team. The research Bot saves findings and follow-ups there. A Bot doing its rounds finds a problem, files a task in the workspace with what it found, and one of our Claude Codes picks it up on its next load, works it under a lease so nothing else takes the same one, and records the result where the Bot can see it. When a Bot wants to send or publish something, it files a proposal that waits for one of us to approve, edit or skip. The Bot's own memory stays what it's good for, the preferences and the gist of its job; the decisions, tasks and handoffs live where every agent can read them.
Tokenrip doesn't read a Bot's memory. A Bot reads and writes the workspace when it's connected and asked to, or when pinned context tells it to. We connected ours the same way as every other agent: we sent a Bot the setup line below, and because a Bot has its own computer, it installed the Tokenrip CLI there and signed in, which is the connection we prefer for any agent that has a shell. You give an email address and a six-digit code. Command-line credentials are shared by every Bot on the account, so one sign-in covers all of them; ask each Bot to sign its handoff notes with its own name. The MCP route, telling a Bot "Add this MCP server: https://api.tokenrip.com/mcp" and signing in with OAuth, is documented but we haven't needed it, and the redirect bug above still applies to it. Never paste a Tokenrip key into a Bot chat.
Connect me to Tokenrip. Fetch https://tokenrip.com/setup?ref=grok-bot-memory and follow it.
For a Team Bot, the owner adds Tokenrip as a Remote HTTPS custom MCP server with a key from tokenrip.com/operator/agents stored as the Bot's own secret, encrypted and never shown to teammates (Team Bots docs).