As we discussed previously in Learning from Anthropic on Building an AI-Native Organization and Should an AI-Native Organization Buy or Build?, companies should rely on existing platforms for general-purpose capabilities, buy off-the-shelf software suites for industry-specific needs, and only build in-house when capabilities must integrate tightly with their own data and internal workflows. Yet when it comes to building internal AI assistants in practice, many teams find themselves caught in a dilemma. When writing code carried a high barrier to entry, the division of labor between infrastructure teams and business teams was clear. Now that AI has lowered that barrier, companies often swing between two extremes of a spectrum. At one end, they open things up completely and let everyone build their own: anyone can spin up an assistant with a few lines of prompts, which leads to people feeding in different tables, defining metrics their own way, and creating internal chaos. At the other end, they pull permissions back and hand everything over to a central infrastructure team. But the infrastructure team only knows underlying systems and web development, not the ins and outs of specific business operations; the general-purpose tools they put so much effort into building are disconnected from real workflows and sit unused shortly after launch. If letting individuals build leads to chaos and centralizing under infrastructure leads to abandonment, how should a company strike the right balance between the two ends of this spectrum?
In early November, xAI’s Data Science team (whose internal team and workspace are collectively known as SpaceXSI) published the official Data Bot case study. Backend screenshots in the post revealed a telling set of internal operational metrics: during the measured week, the company had 280 active team bots, yet only 12 achieved both high activity and high retention. Ranked first among them was Data Bot, maintained by the Data Science team itself, which reached a 70% weekly retention rate. Looking at how they navigated the trade-offs between unmanaged individual building and centralized infrastructure control makes it clear how internal teams should draw the boundaries of who builds what.
In August, xAI launched Grok Bot for individuals, giving each employee a dedicated cloud computer with support for multi-bot collaboration. SpaceXSI initially adopted this model as well, letting employees query data through their own personal assistants, but problems surfaced quickly. When colleagues in marketing, sales, and operations wanted to measure the impact of a promotional campaign, they had to teach their personal bots where the data lived and which table served as the primary table. Because they were not familiar with the underlying data warehouse schema in their day-to-day work, they did not know which tables to join or how metric definitions for active users and revenue were aligned under the hood. Ten people would teach their bots ten different calculation methods, duplicating effort every day and arriving at conflicting numbers—only to turn back to the data team to recalculate everything by hand.
One might wonder whether simply uploading engineer-written database schema documentation or internal docs into a knowledge base would solve the problem. Many teams have tried exactly that, only to find it still falls short. An assistant that has only read table schemas can write syntactically valid database queries, but it easily misattributes the root cause when production metrics fluctuate. For instance, if daily active users (DAU) suddenly drop by 15% on a given day, a schema-only assistant will take the surface numbers at face value and blame a product redesign released the day before. Experienced human analysts know better. When top-line metrics move unexpectedly, they follow a fixed diagnostic sequence: first check whether it was a public holiday in an overseas market, next check whether event tracking logs suffered a pipeline drop, and only then look at the product redesign.
The next challenge is how memory is stored. If an assistant wipes its memory after every chat, employees across the company end up explaining the same business context dozens of times. Yet pooling memory directly across the entire company creates an even bigger problem. Suppose an employee, Zhang San, is running a back-of-the-envelope estimate for a temporary promotional campaign today and tells the assistant in chat to exclude a specific category of refunds when calculating revenue. If that instruction is written straight into the shared company-wide memory, then when a colleague, Li Si, comes in the next day to pull the official quarterly financial report, the assistant will quietly apply Zhang San’s ad hoc rule and get the official numbers wrong.
Because letting individuals build their own assistants gets so messy, many companies swing to the opposite extreme, tasking a central infrastructure team with building a unified, company-wide AI web portal. The infrastructure team designs a neat, structured interface that requires business users to open a dedicated URL, log into their accounts, and select a data source before asking a question. Yet the infrastructure team neither understands how business teams actually investigate problems day to day, nor places the entry point inside the communication tools people already live in. With everyone’s plates already full, those few extra steps add enough friction that most non-mandatory internal tools are barely opened two weeks after launch. When business colleagues have a question, they would much rather ping a data analyst directly in a group chat than open a separate webpage and fill out a form.
Once these concrete failure modes are clear, the way out of the dilemma between chaotic individual bots and unused central portals comes into focus. The key is to carve out a middle layer between individuals and the central infrastructure team: specialist domain teams. Assistants that handle tasks like data querying, contract review, or brand design all require specialized judgment under the hood. They should neither be left for each business unit to cobble together on its own, nor handed over to a central infrastructure group unfamiliar with the domain. Instead, the specialist teams that understand the business rules best should build them centrally and make them available across the company. At SpaceXSI, the Data Science team reclaimed configuration ownership for data-querying assistants and centrally maintains Data Bot for the entire organization. Business colleagues no longer configure tables themselves—they simply ask questions, while the data team has codified which underlying tables to query and what diagnostic sequence to follow into four standardized sets of shared skills.
The first set of skills governs core metric definitions and the diagnostic sequence for anomalies. In addition to specifying the source tables and calculation formulas for key metrics like active users and revenue, the data team locked in the step-by-step troubleshooting playbook used by veteran analysts. When a metric spikes or plunges, Data Bot first slices and compares the data by user segment and region; before attributing a swing to a product redesign, it is required to check the global holiday calendar and verify whether event tracking logs have changed. Even if daily active users in a particular country suddenly drop by half on a given day, the assistant will not immediately sound the alarm on a system outage—checking first whether that country is on a long holiday saves hours of pointless investigation.
The second set of skills covers the full lifecycle of online controlled experiments. Before an experiment launches, Data Bot calculates the required sample size and the number of days the test must run to detect a true effect with confidence. Once the experiment is live, it automatically checks whether traffic exposure is balanced between treatment and control groups and tests for sample bias. When results look counterintuitive, it automatically drills down into granular dimensions to uncover why, and once the target sample size is reached, it generates a final readout in a standardized format. Common pitfalls that business teams used to stumble into—such as calling an experiment early before running it for enough days or missing uneven traffic splits—are caught upfront by baking these checks directly into the workflow.
The third set of skills standardizes charting conventions and one-click conversion into permanent dashboards. Time trends are always plotted as line charts, categorical comparisons are always rendered as horizontal bar charts, and color palettes and typography strictly follow team standards. Whenever a colleague generates a one-off chart in chat and finds it useful, they can convert it with one click into a persistent dashboard saved inside their dashboarding tool—eliminating the redundant step of reviewing a chart in chat and then asking the data team to rebuild it from scratch as an official dashboard.
The fourth set of skills extends upstream into data engineering, stepping in before data is even generated. Data Bot helps engineers write and review underlying data warehouse transformation code and configure automated anomaly alerts for data pipelines. On day one of a new feature rollout, it also works alongside engineers to ensure event tracking instrumentation is complete—preventing the all-too-common scenario where a team goes to check performance two weeks after launch only to discover that critical tracking events were never instrumented.
Once the specialist team has authored those four skill sets, what should the central platform team responsible for the underlying Grok Bot foundation build? The platform team does not work directly with specific business tables and has no need to write domain rules on anyone’s behalf. Instead, their job is to build the underlying permission isolation and knowledge curation mechanisms that let specialist teams govern shared memory with minimal overhead. SpaceXSI introduced two practical design mechanisms here.
The first mechanism separates private conversations from shared public assets. Under the permission model described in the Grok Bot shared bots documentation, the entire company uses the same Data Bot, yet every individual’s chat history with the assistant is private by default—not even the bot’s creators or administrators can view what others have asked in the backend. This lets business colleagues ask questions freely in direct messages without worrying about looking uninformed, and gives newly hired operations and sales team members a safe space to verify baseline metrics.
The second mechanism places an approval gate—complete with contributor attribution—between private chats and shared public memory. Even though individual chats remain private, generalizable institutional knowledge that surfaces during those conversations can still be captured. Whenever a colleague corrects a metric definition in chat or shares a piece of day-to-day context—such as who owns a specific data pipeline or that a recent metric dip was caused by a regional holiday—the system automatically distills that lesson into a concise, single-sentence card and places it in the To review queue under the backend Knowledge panel. A screenshot of this review queue in the official case study reveals a critical design detail: alongside the distilled one-sentence rule, the bottom-left corner of each pending card automatically displays the name of the colleague who triggered it. One card, for instance, is attributed to product manager Kevin Niparko and notes that investigating unexpected metric drops should start with checking the global holiday calendar; right next to it, another card attributed to Allen Shi specifies that internal employee usage data should be excluded from metrics by default unless explicitly requested.
With that automatic attribution attached, a Data Science lead reviewing cards in the backend can weigh the rule against the contributor’s role and context to make a quick call: is this an ad hoc adjustment someone used for a one-time estimate, or a general standard that should apply company-wide? One-off adjustments can simply be passed over, whereas confirmed company-wide rules take a single click on the Approve button to enter everyone’s shared memory—taking effect automatically the next time anyone asks a related question. Because the platform team built the automated distillation and attribution pipeline, the data team only spends a few seconds a day clicking a button, steadily accumulating operational knowledge from everyday chats while keeping company-wide metric definitions consistent.
Once the platform team has built the foundation and the data team has configured the specialist skills, how do business teams actually use these assistants day to day? Across SpaceXSI, a single week saw 280 active team bots and more than 30,000 messages, yet only 12 bots achieved 25 or more weekly active users and over 50% retention—accounting for more than 40% of total message volume. Alongside Data Bot, which ranked first with over 80 weekly active users and 70% retention, the top three included Deal Bot for the sales team and Design Bot for the design team, each maintaining weekly retention between 50% and 70%.
Backend analytics screenshots from the official case study point to a clear dividing line: among those 12 high-retention bots, a median of 60% of messages came from Slack channels, compared to just 12% for low-retention bots. None of the assistants that gained real traction asked employees to open a standalone webpage. Instead, they were all embedded directly into the Slack channels teams already used every day—automatically posting weekly reports on schedule and jumping into message threads on demand.
In everyday channel conversations, a product manager can ask how a new feature’s response latency affects first-week retention and receive a bar chart with a takeaway headline within minutes, showing clearly that retention drops off sharply once latency exceeds 8 seconds. Marketing colleagues focused on user activation—who previously could only see email open and click-through rates inside their email platform—now just pass an email campaign ID to Data Bot to query across the data warehouse and see whether recipients actually upgraded to paid plans. Colleagues driving revenue growth likewise use it directly to track how offline events contribute to the sales funnel.
Another screenshot from the case study illustrates how assistants owned by different specialist teams collaborate automatically inside a group chat. At 11:30 PM, a colleague tagged @Data Bot in a channel, asking it to pull four website traffic and conversion metrics from the past three months, generate charts, and insert them onto a specific page of a Google Slides presentation. Just one minute later, @Data Bot proactively tagged the brand team’s @SpaceXSI Brand Tool Bot in the very same thread to ask for the official background color, standard color hex codes, fonts, and gridline specifications. Once it got the reply, Data Bot generated brand-compliant charts and wrote them directly into the slide deck. With the data bot governing metric definitions and the brand bot governing visual standards, a single-sentence request from a business colleague was handed off and completed automatically between the two specialist assistants.
By the data team’s estimate, Data Bot absorbs roughly 70 hours of work per week that would otherwise fall on data analysts. Still, two caveats are worth keeping in mind when reading that number. First, once querying data becomes frictionless, product and operations teams naturally ask many more exploratory questions that they previously would have dropped rather than wait on a ticket; a large share of those queries represents newly unlocked demand and cannot be equated directly to saved headcount. Second, demanding work such as complex causal inference, non-standard business logic analysis, and underlying data modeling still requires human data scientists—the bot primarily takes repetitive daily data pulls and routine reporting off their plates.
Even with those boundaries in mind, SpaceXSI’s approach offers a clear blueprint for balancing decentralization and centralization inside an organization. Now that AI has lowered the barrier to building tools, companies should not treat unmanaged individual bots and centralized infrastructure portals as a binary choice. Instead, they should establish a clear three-tier division of labor in the middle of the spectrum: the central platform team steps back to provide the foundational layer for private-chat isolation and attributed memory approval rather than building standalone portals divorced from real work; vertical specialist teams like data and brand step up to codify their domain diagnostic sequences into shared skills and curate shared memory; and business teams stop reinventing half-baked wheels on their own, calling specialist assistants directly inside everyday group chats so they can focus their energy on actual business problems.