xAI Launches Team Bots: AI Coworkers That Fit Into Team Workflows and Learn the Business Through Use
Like a newly hired virtual coworker, a Team Bot receives a handbook, tools, restricted permissions, and working memory so it can move tasks across apps and carry team decisions and corrections into the next round of work.
xAI has released Team Bots, a type of Grok Bot that an entire team can share and bring into real workflows. Think of one as a newly hired “virtual coworker.” A regular chat assistant is more like a temporary consultant: you have to explain the project again every time you meet. A Team Bot comes with the team’s handbook, toolbox, restricted access badge, and work notebook. It knows where to find information, which rules to follow, and where the team left off last time.
The problem it addresses is not that “AI cannot answer questions.” It is that a company’s business context is scattered: customer updates live in Gong, project decisions in Slack, tasks in Linear, standards in Notion, and data in a warehouse. People have to move that context around for every question, and when someone changes roles, decisions already made can disappear with them. A team can create a Team Bot around a sales account, engineering project, brand review, or data-analysis workflow, then give it the relevant material, rules, app connections, API permissions, and long-term memories so it can keep following the same work.
Main features
- Create a shared Bot around one role or process: assign a continuously working role to a sales account, engineering project, marketing review, or data Q&A workflow instead of starting a new conversation each time.
- Bring context, plugins, credentials, and memories together: it knows how the team works, can enter work systems and use approved capabilities, and can retain later decisions and corrections.
- Connect Slack and business applications: it can read changes from systems such as Gong, Notion, GitHub, Linear, and Databricks, then return briefings, tickets, previews, or analysis to the place where the team collaborates.
- Share team capabilities while keeping individual conversations separate: team members use the same knowledge and skills, while each person’s direct conversations and personal context remain separate.
- Accumulate organizational knowledge through continued use: the Bot remembers decisions and corrections that the team has confirmed, so similar work does not have to restart from zero.
1. Use shared context to standardize how a role works
A Team Bot is built around a role or process shared by a team. The team can provide internal files, operating instructions, and skills so the Bot understands how the company handles customers, ships code, reviews brand content, or interprets data.
xAI divides this role knowledge into four parts:
- Context: files, instructions, and skills—such as brand guidelines, internal documents, and delivery processes—that tell the Bot how the company works.
- Plugins: connections to applications such as Salesforce, Notion, and GitHub, allowing the Bot to read or operate the systems where work actually happens.
- Credentials: access credentials for third-party APIs, used to connect team systems that lack a ready-made plugin and to limit what the Bot is authorized to call.
- Memories: decisions, corrections, and user context accumulated through work, allowing later tasks to continue from earlier judgments.
To continue the “virtual coworker” analogy: Context is the handbook it receives on joining; Plugins are the tools it uses, such as Salesforce, Notion, and GitHub; Credentials are an access badge that opens only designated systems; and Memories are the notebook it keeps updating as it works.
The four capabilities matter only when they work together. With only a handbook, the Bot can merely look things up. With only plugins and credentials, it can enter systems but does not know how the team wants the work done. Without memories, the team must repeat the same correction after every task. Together, they let the Bot move from “answering a question” to “following a piece of work over time”: understand the rules, retrieve information and take actions in the relevant systems, and carry new decisions and corrections into the next task. Context that individual employees once assembled on the fly can therefore become a reusable foundation for the whole team.
2. Connect apps and APIs to turn information into next actions
A Team Bot does more than read material. Through plugins and API credentials, it can track changes across systems and advance the next step according to a workflow set by the team.
Although the four examples involve different kinds of work, their basic chain is similar:
- Read the latest state from documents, calls, Slack, tickets, monitoring systems, or data tables;
- Interpret those changes using brand standards, delivery processes, metric definitions, or account strategy;
- Produce a draft, create a ticket, invoke an execution agent, update content, or start a read-only query;
- Bring the briefing, preview, evidence, and blockers back to Slack for the team to continue;
- Record new decisions and corrections for use in the next task.
Its role is therefore not merely to generate an answer, but to reconnect scattered information into a workflow that can keep moving.
3. Share team capabilities while keeping individual conversations private
What the team shares is the Bot itself, along with its role knowledge, skills, and team configuration. A Team Bot can also have its own Slack account. Once added to a channel, members can ask it questions, provide more information, and see its answers together.
Direct conversations between an individual and the Team Bot remain private. According to xAI, the Bot keeps separate context and memories for each user while drawing on skills owned by the team. Plugins can be connected by an individual or configured for the team as a whole.
The point of sharing, then, is to share a way of working—not to merge everyone’s chat history. Public channels support joint work, while individual conversations preserve each person’s work context.
4. Accumulate decisions and corrections through continued use
Memories allow a Team Bot to continue long-running work, but “learning more about the business the more it is used” is not a claim that it becomes smarter automatically. There is a concrete loop behind it: the Bot first reads material and rules the team has supplied, participates in tasks in Slack and business systems, and then retains decisions, corrections, and user context that the team has confirmed. When a similar task appears later, it reuses that information instead of guessing again from scratch.
xAI’s data team has built a skills library covering more than 45,000 tables to explain the right data sources, analysis methods, and charting conventions. After connecting to that existing knowledge, the Data Bot also remembers corrections users make to its queries. Here, “learning” does not mean automatically reading all company data, nor does it mean retraining the base model after every conversation. The original article specifically describes skills, memories, and query corrections being reused in later work. A Team Bot learns more about the business through continued use because organizational knowledge and feedback are retained—not because the model acquires business knowledge from nowhere.
Where does “learning the business through use” actually happen?
Knowledge is not loaded once; it forms a loop through real work
All four steps remain visible. Select any step to see what it does in practice.
Current step
Start with the team’s working foundation
The Bot first reads files, standards, and skills. It starts not from an empty chat box, but from the methods the team has already documented.
For example: brand guidelines, account information, PR completion criteria, and metric definitions.
This shows how skills, memories, and feedback are reused in later tasks. It does not mean the base model automatically reads or trains on all company data.
How Team Bots work in four scenarios
Sales and customer success: produce daily account briefings
xAI gives major sales accounts a dedicated Team Bot shared by the account executive (AE), customer success manager (CSM), solutions architect (SA), and sales leaders. Previously, each person held only part of the customer picture: one knew what was said on recent calls, another knew the technical blockers, and another knew the account strategy. The complete context was spread across tools and team members.
Every night, the Team Bot reviews company news, recent Gong calls, Notion documents, and relevant Slack discussions. The next morning, it posts a briefing in the account channel with suggested next steps and drafts for each role. During the day, the team checks its conclusions against account data and leaves new decisions behind. In that sense, it becomes a “living reference” for the account. The savings are not limited to the time required to write a morning report: the team also spends less time asking different colleagues for context, assembling the latest state by hand, and repeating verbal handoffs after people rotate.
Harper CEO Dakotah Rice said his team built a Team Bot in 24 hours to identify customers with lapsed policies across three platforms, check their balances, and send personalized emails. He said the workflow saved customers more than $120,000 across hundreds of policies. This is a customer-provided case metric.
Product and engineering: coordinate tickets, agents, and delivery evidence
xAI’s engineering Team Bot gathers information from project Slack channels and connects to Notion, Linear, Hex, Datadog, and Cursor. Engineering workflows can easily break between tools: product decisions stay in chat, someone still has to turn bugs into tickets, and after an execution agent changes the code, someone must verify the tests and delivery evidence.
The Team Bot connects that chain. It tracks decisions, triages defects, creates clear Linear tickets, and hands well-bounded fixes to Cloud Agents. Skills tell it how to review a PR, when it must escalate to a person, and what evidence a change needs before it counts as complete. When an execution agent returns a PR with passing checks and verification evidence, the Bot reports progress and blockers back in Slack. It replaces the coordination work of moving information between tools and monitoring progress; it does not remove engineers’ judgment on complex changes.
xAI says that, while developing this product, one Team Bot orchestrated hundreds of Cloud Agents and helped a five-person team ship it in a few weeks while submitting more than 100 PRs per day. This is xAI’s self-reported production data; the original article does not disclose PR size, rework rate, or a human-only baseline.
Marketing: review against shared rules and deliver a preview
Large marketing teams often wait in two places. Regional teams finish content but must wait across time zones for headquarters to check brand consistency; after website or SEO copy is approved, they must file an engineering ticket before it can be changed on the site. After the marketing Bot receives brand guidelines, blog posts, and social copy, someone can submit a draft in Slack and the Bot can first review it against the brand voice and latest information, helping different regions use the same standard.
Once content passes review, the Bot can continue by updating website and SEO content, generating a preview link, and returning to Slack for final confirmation. This shortens both “waiting for headquarters’ first review” and “waiting for an engineering slot.” The final human sign-off remains; the AI is not deciding on its own what goes live.
Amplitude marketing leader Angela Ferrante said the company is experimenting with Team Bots for market and customer intelligence, AI-search visibility, launch review, and performance assessment.
Data analysis: answer ad hoc questions with read-only access
xAI’s data team receives dozens of ad hoc analysis requests each day. In a traditional workflow, a business user first waits for an analyst, then the analyst confirms metric definitions, finds the correct tables, and writes a query. Even a one-off question can require several rounds of coordination.
The Data Bot uses shared read-only credentials to query approved Databricks tables and connects to Datadog, Hex, and Statsig for investigation, analysis, and presentation. Employees can therefore ask business questions directly without waiting for an analyst or applying for and configuring warehouse access themselves. A skills library the data team built over the previous two years for more than 45,000 tables helps it locate the right data, understand metrics, and chart results according to company standards. When someone corrects a query, that correction can also help later users avoid the same mistake. This depends on a constrained scope of access: the Bot uses read-only credentials and can query only approved tables.
What changes across all four scenarios
On the surface, the four Bots write morning reports, create tickets, review copy, and query data. The deeper shared change is that people no longer have to act as information couriers every time. The Bot brings information scattered across chats, documents, business software, and data warehouses back into one workflow, then advances the next step according to explicit team rules.
That creates three concrete forms of value. Information does not have to be repeatedly rediscovered because it lives in different tools. Decisions and working methods that have already been confirmed can remain useful after employees rotate or leave. And scarce roles—analysts, engineers, or headquarters reviewers—can spend less time looking up information, relaying tickets, and handling first-pass reviews, leaving their attention for exceptions and complex problems that genuinely require judgment.
Which team workflows are good starting points for a Team Bot?
Team Bots are currently in public beta for Teams and Enterprise plans. Users can share an existing Grok Bot with a team or start with xAI’s prebuilt Bots for sales, product management, marketing, and data analysis.
To decide whether a workflow is a good candidate for a system like Team Bots, check five things:
- Does the task recur, with context scattered across systems? A process that requires checking several systems and summarizing changes every day is a better candidate than a one-off question.
- Are the team’s rules explicit? The clearer the brand guidelines, PR completion criteria, metric definitions, and escalation conditions, the more consistently the Bot can operate.
- Can the work be done with minimum permissions? Start with read-only access where possible; when content must be changed, separate preview from final approval.
- Are the boundaries between shared and private information clear? Team skills, public channels, and individual conversations carry different information, so visibility and handoff rules should be defined in advance.
- Can the result be checked? Beyond output volume, examine waiting time, rework, errors, human escalations, and whether results still pass the existing quality bar.
The best starting point is a process with a clear role, controlled material, and verifiable results. The direction behind Team Bots is also clear: enterprise AI is moving from an individual Q&A tool toward team-configured roles that connect to systems and accumulate working memory over time.
Members can copy or download the full Markdown, and let their AI subscribe and ask.
Found this useful? Leave your email — every new explainer, the moment it's out. Unsubscribe anytime.
