Grok Bot Team Bots: How to Set Up a Shared Bot Your Whole Team Can Use11 min read

Grok Bot can now be one Bot that your whole team uses. You build it once, give it apps, skills and files, share it, and every teammate gets a private chat with it in the app or in Slack. SpaceXSI, the company behind Grok Bot, called these Team Bots in its September 26, 2026 changelog and calls them Shared Bots in its docs and its October 27 sales post. They are the same thing.

The idea reached a wider audience on October 30, when Elon Musk wrote on X: “Hire Grok @Bot to be an employee.” This guide is for the team lead or ops owner who has to turn that sentence into a job description: what to hand a Bot, what it can see, who can approve what, and where its work ends up. For how Grok Bot builds a single report or dashboard, read our guide to Grok Bot Pages. This one is about roles, permissions and rollout.

What is a Shared Bot, and what happened to Team Bots?

A Shared Bot is a Bot that runs in the cloud and that several people use. The docs compare sharing it to sharing a doc: with everyone on the team, or only with certain people and groups. Sharing does not make a copy, and each person’s chat with it stays private. A Bot that runs on your own computer can’t be shared.

The naming moved over a month. The September 26 changelog said Team Bots. The October 27 changelog says the admin page now reads Shared Bots, with Manage Shared Bots and Create Bot, and the docs page is titled Shared Bots. They are the same feature. One more wrinkle: the September changelog described a Publish to Team step that makes a team copy, while the current docs say sharing does not duplicate the Bot. Follow the docs, and look at the Share menu in your version of the app.

What did SpaceXSI’s own sales team build?

The best description of a Shared Bot doing a job is the one SpaceXSI published about its own sales team on October 27. Individual reps had built their own Bots to research accounts and manage pipelines. The team then pulled the best of that into Shared Bots, each with one role, maintained by the people who know the job. Their pitch for it: improve a Bot once and everyone who uses it benefits without updating their own setup.

SpaceXSI also mentions a Competitive Intel Bot and a Sales Training Bot, and says people across Sales still build many individual Bots for their own work.

What I take from the post is less the list of Bots than the list of things the Bots are not allowed to do. SpaceXSI says Shared Bots “act with each user’s permissions, with additional restrictions on sensitive actions”, that they have rate limits to prevent unintended changes at scale, and that certain actions are reserved for specialist Shared Bots. Its example is the clearest rule in the post: “A sales rep, for example, cannot use Quote Bot to approve their own discount.” Human review is required whenever the criteria for a decision can’t be clearly defined, and whenever a Shared Bot prepares a customer-facing message. SpaceXSI says it expects to give the Bots more responsibility as it measures the quality of their work.

The post gives no numbers on time saved or error rates, so treat it as a design pattern, not a result.

What can a Shared Bot see and do?

The Shared Bots docs answer the questions an IT or security lead will ask first. This is the model as the docs state it today.

Two details are easy to miss. First, apps, secrets, skills and files you attach work in every teammate’s chat, so the docs tell you to add only keys and files you are happy for everyone with access to use. Second, when a Bot posts in Slack it records who asked for each message, and anyone in the thread can ask it who requested a post. That is the audit trail you want before a Bot writes in a channel on its own.

How do you set up a Shared Bot for one job?

1. Pick one narrow job. SpaceXSI’s Bots each own one step of the deal cycle. “Handle sales” is too wide. “Flag deals with no next step in 14 days” is a role.
2. Create the Bot. Choose + in the sidebar, then Create a Bot, name it, and tell it what it should help the team with. A sentence is enough to start.
3. Follow its setup cards for apps, secrets, skills and files. Put your business rules in a skill or a file so everyone works from one source and you can update it once.
4. Write down what it must not do. Put the limits in its instructions and enforce the important ones with permissions. Use the brief below as a starting point.
5. Share it narrowly first. Choose People you invite and add two or three teammates. Add Managers only for people who should change how it works.
6. Connect Slack once the Bot behaves. The owner or a Manager chooses Bring to your team’s Slack, then Connect. Each teammate links their Slack account before the Bot acts for them.
7. Widen access to the team after a week of real use. Admins can then auto-add it to everyone’s sidebar.

Name: Weekly Deal Review Bot
Job: Every Monday, read open opportunities in our CRM, flag deals with no next step in 14 days, and draft a summary for the sales lead.
Knows: our stage definitions and discount policy (files: stage-definitions.md, discount-policy.md).
Can do: read the CRM, post the summary in #sales-review, create a Page with the flagged-deals table.
Cannot do: change a deal, send anything to a customer, or approve a discount.
Asks first: before writing to the CRM, and before posting anywhere except #sales-review.
Hands off to a human when: the decision needs judgment the policy does not cover.

This brief is an example I wrote to show the shape, not a template from SpaceXSI. The point is that the last four lines are about limits and handoffs. A Bot with a clear “cannot do” list is easier to trust than one with a clever prompt.

Where does a Shared Bot’s work end up?

Inside Grok Bot, the output is a Page: a report, memo or dashboard the Bot builds and keeps up to date. For teams, the changelog adds that a team Page appears in the Library under every Bot that published it, Page owners can share a Page with the whole organization or another team, and admins can limit who may share Pages with everyone. A shared Page has a title bar with a PDF download and, for visitors, a Try Grok Bot button.

That covers a team that works entirely in Grok Bot. It gets thinner in three situations: the reviewer works in Claude or ChatGPT, you need a record of which Bot or person changed which line, or the result should be a page with its own URL. The changelog describes Page sharing and PDF download. It does not describe handing a Page to another vendor’s assistant to edit.

That is the gap AgentGrid.io fills. It is a shared workspace where people and AI assistants create, edit and share documents, apps and files. AgentGrid.io’s docs describe connecting Grok Bot from its command-capable environment with npx @animaapp/cli@latest login. A human confirms the code and approves the agent’s name, team and which of read, write, share and publish it gets. After that, the Bot’s work lands in the team’s workspace under its own identity, and History labels each change with that name. The Bot’s capabilities are fixed after approval, and publishing needs both the publish capability and an explicit human request.

In practice, the weekly summary from the example brief becomes a markdown artifact. The sales lead comments on a row, Claude rewrites the executive paragraph, and the Bot updates the table next Monday in the same artifact, with every change attributed. Our guide to publishing a website with Grok Bot walks through the publish step.

What should you watch out for?

• Naming. Team Bots, Shared Bots and the dashboard wording all appear in current material. Search for both.
• Plans and access. The docs say Shared Bots are for members of a team who have Grok Bot, and they tie team membership to a Cursor team and dashboard. Check what your plan includes before you promise a rollout.
• Usage lands on the asker. A popular Bot spends every teammate’s own allowance. Tell people before you make it the front door for the whole company.
• One owner can delete it for everyone. Only the owner can delete a Shared Bot, and deleting removes it, with teammates’ chats and routines on it, for the whole team. It can’t be undone.
• Evidence is the vendor’s own. The sales post describes SpaceXSI’s internal use and publishes no outside results.

When should you use a personal Bot, a Shared Bot, or AgentGrid.io?

• Personal Bot for work that is yours alone: your inbox, your calendar, your research.
• Shared Bot when several people need the same expertise and the same rules, and you want to update both once.
• AgentGrid.io when the Bot’s output has to be reviewed by people outside the chat, edited by other assistants, versioned, or published.

If you try this, start with the job nobody wants to do twice, such as the Monday pipeline summary or onboarding questions. Give the Bot one job and a short list of things it must not do, then see whether two teammates use it the following week.