SpaceXAI announced Grok Team Bots on September 28, 2026, offering shared agents built around an organizational role or workflow. A shared Bot can reuse team expertise while people maintain individual conversations. Teams should evaluate that separation before treating a Bot as a trusted company knowledge layer.
Shared expertise and personal context serve different purposes
The announcement describes context files, skills, plugins, credentials, and memories. It says personal conversations and memories remain separate even when users access the same Bot, and it supports collaboration through Slack.
For an account team, shared instructions can encode a briefing format and approved product information. Individual context may include a person’s unfinished draft or a tentative decision. Those are different classes of information. A useful acceptance test asks the same Bot to summarize work for two users with different permissions and checks that private context does not become shared output.
Publishing a Bot is a meaningful access change
The official changelog records Team Bots in September 26 version 0.61.0, before the public launch post. It describes a publish-to-team choice, management controls, per-user usage, and permission prompts for connected plugins. Later entries add managers and Slack approvals.
Inspect what a team copy carries over before publishing an existing personal Bot. If it includes memories or connected resources, remove material that belongs only to its creator. Give the Bot a clear owner and a review date for shared instructions; an agent with outdated knowledge can repeat an old decision at organizational scale.
Slack creates a visible collaboration boundary
A Bot joining a channel should have a clear purpose and access scope. Separate the ability to read a conversation from the ability to post, send email, create tickets, or launch coding work. An agent’s presence in a channel is not blanket approval for every action available through its tools.
Test how the workflow behaves when approval is unavailable, a connector expires, or a teammate leaves. Consequential work should remain pending or visibly fail rather than silently switch to another identity. Use draft outputs for early trials, then expand write permissions only for actions whose consequences can be reviewed.
Start with a workflow the whole team understands
A bounded daily briefing is a useful initial trial because the source inputs and expected output can be compared. Record omissions, incorrect references, review time, and usage separately. Shared context can reduce repeated setup, but reliability comes from owned information and controlled actions, not from calling the agent a teammate.