A shared bot with individual conversations
xAI launched Team Bots on 28 September, turning Grok Bots into shared workplace agents that can be configured around a role or recurring workflow. A team gives the bot files, instructions, skills and application access, then makes that common capability available to multiple people. Individual conversations remain private, while the bot draws on knowledge and operating rules shared by the group.
The product brings together four elements: context, plugins, credentials and memories. Context supplies files and instructions; plugins connect business applications; credentials cover APIs without a plugin; and memories preserve what the bot learns about its role. Team Bots can also join Slack channels under their own handles, allowing a group to ask questions, contribute information and see responses in one place.
From briefings to engineering coordination
xAI says its account teams use dedicated bots to review company news, Gong calls, Notion documents and Slack threads overnight, then post morning briefings with role-specific next steps. The shared context can help account executives, customer-success managers and technical staff work from the same record, while memories retain decisions as people move into and out of an account.
For product and engineering, xAI describes a bot connected to Notion, Linear, Hex, Datadog and Cursor. It follows decisions, triages reports, creates tickets and launches cloud coding agents for bounded fixes. The company says a five-person group used this pattern to coordinate hundreds of agents and ship more than 100 pull requests a day while building Team Bots. That is a vendor case study, not a general productivity guarantee.
Marketing and analytics use different controls
The marketing example checks drafts against brand guidance and recent messaging, then moves approved website changes towards preview and sign-off. The data example uses shared read-only credentials to query approved Databricks tables and connects to analytics tools for investigation. These examples show why one security template cannot cover every Team Bot: publishing content and reading a warehouse present different permissions, review requirements and failure modes.
A shared bot may also accumulate institutional knowledge that outlives the people who supplied it. That can reduce repeated work, but it creates a need for ownership and retention rules. Teams should know who can edit instructions, which memories are global, how personal conversations are separated and how an incorrect correction can be removed before it influences everyone.
Public beta sets expectations
Team Bots is available in public beta on xAI’s Teams and Enterprise plans, with templates for sales, product management, marketing and data analytics. Public beta means organisations should expect product changes and should avoid treating early behaviour as a fixed operating contract. A limited pilot can clarify which workflows benefit from shared memory and which are safer as conventional automation.
The launch also extends the Grok product from an individual assistant towards an orchestration layer across workplace systems. Its value will depend less on a single chat answer than on whether it can maintain accurate context, respect each connector’s permissions and expose a reliable record of actions. Integrations with Slack and third-party applications make those governance questions central rather than optional.
A sensible rollout starts with boundaries
Before connecting a Team Bot, an organisation should define the exact task, approved sources, allowed write actions and the point at which a person must review the result. Read-only analytics or draft generation offer lower-risk starting points than autonomous changes to customer records or production systems. Credentials should be scoped to the minimum resources and rotated like any other service identity.
Teams should also measure the cost of supervision, not only work completed. Useful indicators include how often the bot requests clarification, creates a reversible draft, acts incorrectly or carries stale context into a new decision. Team Bots could make shared expertise easier to reuse, but their durable memory and broad connectors increase the consequences of a mistaken instruction. The public beta is the right stage to test those boundaries deliberately.
Exit and incident procedures are equally important. Administrators should be able to suspend a bot quickly, revoke every connected credential and export or delete shared memory according to policy. When a person leaves a team, their access should disappear without removing knowledge that the organisation legitimately owns or retaining private material that it does not. Audit logs need to distinguish a user request, a bot decision and an action performed by another agent. These controls are less visible than a morning briefing, but they determine whether a shared assistant can be governed like other workplace infrastructure. Public-beta testing should explicitly exercise them before the bot becomes part of a critical workflow.
A pilot should include people who did not configure the bot. Their experience will show whether its instructions and boundaries remain understandable to ordinary team members rather than only to the original builder or administrator during everyday work.