A roadmap: all five guides turn chat into a persistent work system

Eric Zakariasson originally kept Coder, Writer, and Researcher in separate chats. That worked for one project. With several projects moving at once, signal and noise blended together, and the Bots struggled to know how far one another had progressed. He copied a structure familiar from human teams: one channel per project, a fixed roster, a project record, and a task board that preserves state.

The other four guides keep moving in the same direction. The mobile studio divides responsibility across analytics, creative, engineering, deployment, and repair. The design team assigns exploration, motion, Figma production, and engineering interpretation to different Bots. The GTM team defines roles for meetings, email, prospecting, accounts, and slides. The PM team adds a Chief of Staff, an engineering manager, engineering Agents, data analysis, and recruiting.

Taken together, the implementation sequence can be compressed into seven steps:

1. Define each Agent's role and explicit refusals.
2. Separate responsibility and context with Managers, Specialists, and project channels.
3. Connect the real accounts, data, computers, and production assets needed to complete the work.
4. Record repeated actions as skills, and give routines a schedule and input sources.
5. Have Agents hand off verifiable deliverables directly, creating a feedback loop.
6. Keep external sends, spending, deletion, deployment, and highly ambiguous judgments with people.
7. Prove one loop first, then add roles only when responsibility truly expands.

These seven steps are an editorial synthesis of the five practices. xAI has not formally named them as a framework.

Step One: write every Agent as a bounded role

The mobile development guide offers the most complete definition. A persistent Bot has six components: role instructions determine “who it is”; connections determine “what it can access”; a dedicated computer determines “where it works”; routines determine “when it acts on its own”; skills determine “how it repeats a task”; and handoffs determine “who receives the result.”

The easiest elements to overlook are refusals and handoffs. The Analytics Agent is the only role allowed to declare a data finding. It cannot write ads or touch application code. The Creatives Agent turns findings into ad specifications and variants, but cannot buy media. The engineering Agent receives specifications, not vague suggestions. The GCS Agent owns certificates, deployment, and rollback; no change reaches players without passing through it.

The Analytics configuration is unusually specific about timing, sources, and outputs: every day at 19:10 it summarizes Meta and AppLovin spend, installs, and CPI; every day at 6:30 it checks room size and the Partner Challenge funnel in PostHog; and every Monday at 9:00 it summarizes 7-day and 30-day CPI plus Apple and Google Play revenue. Ad winners and losers go to Creatives, product findings become specifications for Engineer, and any action that spends money must first ask a person.

Step Two: organize with Managers, Specialists, and project channels

The role names vary across the five guides, but the organizational shape stays stable: keep one general entry point for daily coordination; let a Manager decompose tasks, assign work, and review results; give each Specialist clearly bounded data, tools, and responsibilities; and use project channels to isolate context for different goals.

Ryan Perry's breakdown of mobile development explains why responsibilities must be separated. He estimates that building the game itself is about 15% of the work. The remaining roughly 85% is acquisition, creative, client-side development, backend and live ops, store release, QA, and incident response. The six corresponding seats are Orchestrator, Analytics, Creatives, Rank’em Engineer, GCS, and Bug Fix, each with explicit exclusions. The design guide uses Figma Bro, Motion God, Experiments, and Devbot for the same role isolation. Related cards on the GTM page point back to the same project control plane of channels, rosters, and Notion boards.

The original roster places all six roles and their work surfaces in one view.

The multi-project guide expresses this structure most simply. Notion contains Projects and Tasks databases. Projects Manager uses the Project Ops skill to create a project, open a channel, and propose a roster. Staffing reuses the existing Coder, Researcher, and Writer first. It proposes at most five Bots in addition to the PM. A new role is created only when no suitable one exists, and a person must approve it. The six-Bot limit here is only the author's experimental setting.

The project channel contains the person, the PM, and a fixed roster, making it the context boundary.

The task board turns Backlog, Planning, In progress, Blocked, and Done into shared state.

Once a project begins, the person and the roster break work down in the channel. The PM mostly watches progress and keeps the databases current. When a Bot gets stuck, it marks the task Blocked and asks a person in the channel. This simple move solves a common multi-Agent failure mode: the system no longer hides failure behind silence, and people do not have to interrogate each chat for status.

The PM guide shows a deeper hierarchy. Chief of Staff is the only generalist, responsible for calendar, Slack, inbox, and the Attention List. Engineering Manager does not code; it decomposes technical work, delegates to five engineering Agents, and reviews against the objective. An engineering Agent can in turn manage multiple Cloud Agents. The author gives three reasons for multiple Agents: addressable responsibility, parallel work, and scoped memory. Chief of Staff should not debug a computer-use evaluation, and an evaluation Agent should not organize the inbox.

Kevin Niparko's complete PM roster also includes Ashley for data analysis, PM Pete as a product counterpart, and Recruiter. Chief of Staff can learn a writing style and maintain the Attention List, but external sends, purchases, and deletions still stop with the person. In the layered engineering organization, the engineering manager reviews objectives while five engineering Agents delegate to Cloud Agents. A “team” is therefore more than a list of roles: it includes two levels of delegation and review.

Step Three: connect real systems, dedicated computers, and production assets

Even a well-written role can only give advice without a working environment. Across the five guides, Agents repeatedly connect to real systems. The mobile team uses Meta Ads, AppLovin, Adjust, PostHog, Google Cloud, app stores, and Sentry. The GTM team uses Salesforce, Gmail, Calendar, Sheets, Drive, Slack, Notion, Granola, Figma, X, LinkedIn, and the data warehouse. PM research adds Gong, customer Slack, Databricks, and Plain or Intercom.

A GTM Bot's computer runs 24/7 and keeps working after the laptop is closed. It learns writing style from historical Gmail and Slack, while Krista Letz can assign work through the mobile app and voice when away from the computer. The product research Bot searches interviews, customer Slack, the user-research repository, Databricks, support tickets, and Notion decisions together, so it does not answer a cross-source question from only one system.

The Cloud Agent in the PM guide is not a blank virtual machine either. Its environment already contains the codebase, project dependencies, Secrets, and the conditions needed for testing. Only then can an engineering Agent delegate implementation, run verification, and retrieve the result. The later claim that a “Bot decomposes high-level objectives and participates in merging PRs” depends on the model, engineering environment, layered delegation, and review working together; it cannot be attributed to the model alone.

A dedicated cloud computer handles browser and terminal operations, so routines continue even when the user's computer is off. It also offers a practical fallback. Ryan Perry could not use the Meta Ads API because of a verification issue, so he pressed record and demonstrated the web flow for uploading creative on the Bot's computer. The Bot remembered the click path and could then upload and test at least one new creative through the web UI every day.

The design guide takes “real environment” even further. Motion God did not approximate the Grok Bot character from screenshots. It used the actual animation specification file from the product to build a playground on localhost. The designer could directly tune timing, spring, distance, scale, and easing, or say “look down-left a little longer” and “the bounce is too exaggerated,” then immediately replay the complete sequence.

Keyframes turn abstract motion feedback into a production asset that can be compared frame by frame.

Figma Bro does not rely on visual estimation either. Through Figma MCP it reads the actual file's x/y coordinates, dimensions, spacing, typography, fills, strokes, and component structure, then generates 20 starter Bot character cards from one Auto Layout component. For a new-user tool picker, it also finds the correct versions of common tool logos and orders them by likely usage. The existing Figma file is the source of truth. The Agent supplies replication accuracy and scale; a person decides which version deserves to remain. Automation also prevents small inconsistencies—wrong logos, outdated components, mixed avatar sources, or different spacing on the tenth card—from accumulating at scale.

The batch of character cards shows structured Figma production, not screenshot approximation.

Project state

Design roles

Real attention

Software delivery

Step Four: build closed loops with routines, skills, and handoffs

Routines start work on schedule, skills make execution repeatable, and handoffs let the next role receive the result. Together they turn an Agent from an on-demand assistant into a continuously operating workflow.

The project PM's operating protocol belongs here too: it primarily watches progress and maintains Projects and Tasks. When any Bot is stuck or lacks input, it changes the task to Blocked and alerts a person in the channel. Explicit state turns failure into a handoff someone can take over, instead of letting a stalled task silently disappear.

The mobile team also shows how routines can grow out of work. Each of six Bots owns one overnight task and delivers the result in the morning. After one overnight request, a Bot concluded that the responsibility should recur and added it to its standing duties. Routines therefore need not come only from a schedule prewritten by a person; an Agent may infer them from repeated responsibility. When copying this pattern, treat “adding a persistent routine” as a role change and inspect which permissions, resources, and notification channels it will keep using.

The mobile studio provides the clearest loop. Analytics reads advertising and product data and produces the only judgments qualified as “findings.” Creatives or Engineer turns a finding into a testable change. GCS controls deployment. New behavioral data returns to Analytics. The author reports that this cycle changed one ad from a party scene to a partner scene, reducing cost per install from $15 to $1. In another round, analysis found a relationship between high scores and retention. The team added a bonus hint and moved D7 retention from about 2.5% to 10%, roughly 4 times the original level.

The original conversation shows an Analytics finding entering the next role directly instead of stopping in a report.

AnalyticsAds + product behavior → sourced finding

→

Creatives / EngineerAd variant or product specification

→

GCS / ReleaseDeployment, certificates, rollback

→

Measure againCPI · score distribution · D7 retention

CPI: $15 → $1D7: about 2.5% → 10%Self-reported, not a controlled experiment

The numbers are striking, but the evidence is a single team's self-report. The source provides no sample size, control group, attribution window, concurrent changes, or evidence of long-term persistence. What can be copied is the loop structure and its responsibility boundaries—not a promise that deploying six Bots will reproduce the reported 15-fold improvement in CPI.

The GTM guide specifies routines as stricter operating protocols:

• The inbox filters only customer, prospect, renewal, quote, introduction, and direct-question messages. It skips newsletters, automated notifications, receipts, calendar RSVPs, and internal noise. It delivers a summary and proposed reply but never sends automatically; when nothing needs a reply, it stays silent.
• Post-meeting follow-up processes only external meetings that just ended, using Granola or Gong as the source of truth. It drafts recipients, subject, body, and concrete next steps.
• The first prospecting run confirms the CRM, email, spreadsheet, usage data, intent tools, account ownership, buyer function, and seniority. It learns style from 15–30 real outbound emails and refreshes that style reference after about 30 days.
• Every prospecting run reconfirms the target-role filters and batch size, and first discovers the CRM's actual fields and stages. It filters strictly by function, deduplicates people, and explicitly says when no recent public content can be found.
• Once product data is connected, every row identifies active users in the account and people who have reached plan limits, treating capacity ceilings as expansion signals. Intent signals prioritize direct product mentions rather than generic AI discussion.
• Every row displays the current opportunity stage, amount, and last CRM activity, so a warm pipeline is not recycled as a cold list. It delivers a live spreadsheet link rather than CSV, and LinkedIn messages cannot claim that an email has already been sent.
• Before drafting, it checks the previous 90 days of sent mail, the spreadsheet's Emailed column, and CRM activity. Previously contacted people are marked Skip Draft; they remain in the sheet but receive no duplicate pitch.
• It first shows 2–3 email and LinkedIn samples for human approval, then generates the full batch. After actual sends, it writes the date back so the next run can deduplicate again.
• The account expert maintains a state file of “what has already been processed” and reports only new material. For podcasts, videos, and talks, it obtains a transcript or reviews the source content itself, retaining 3–6 points, competitor mentions, sentiment, timestamped quotes, and buying signals. It also extracts feature requests from calls, tracks support tickets, and matches relevant new features to customers. If it cannot obtain the text, it says so instead of pretending to have reviewed it.

The value of prompts like these lies not in their length but in a complete operating specification: how the first run initializes, which parameters each run reconfirms, which systems are authoritative, how duplicates are prevented, where approval is required, and which state is written back after completion.

PM software delivery follows the same path. A person supplies a high-level objective; in a Cloud Agent environment already equipped with the repository, dependencies, Secrets, and test conditions, the Bot decomposes, delegates, reviews, and integrates the output. Kevin reports that Grok Bot accounted for a double-digit percentage of internal merged PRs at the time. The claim lacks a time window, denominator, and rework definition. It proves that this path entered real code delivery, not its quality or net efficiency.

Step Five: how project, mobile, design, GTM, and PM teams implement the model

The five domains need different roles; one universal Bot roster cannot cover them all. They share roles, connections, routines, skills, handoffs, and human gates, but their concrete units of work still come from the business.

Multiple projects: a project channel is the context boundary

Each project gets one channel, one roster, and one Notion project record. Projects Manager handles meta-work, Specialists claim tasks, the PM maintains state, and Blocked explicitly hands work that cannot continue back to a person. Temporary roles can be removed when the project ends. When responsibility reappears, existing roles are reused first.

Mobile development: expand “finish the app” into a complete studio

Ryan Perry uses six Bots to operate the mobile game Rank’em. At publication, he reported more than 1,000 downloads across iOS and Android during the previous week. The mobile case covers acquisition, creative, client-side development, backend and live ops, release, QA, and incident response. The author treats the game itself at roughly 15% and the surrounding work at roughly 85% as an experiential estimate. The team also planned to add a revenue Bot and more ad networks, while other roles would be created only as new responsibilities emerged. The guide directory likewise summarizes the practice as “six Bots, one mobile game studio.”

Design: increase the number of versions that can be judged

John Bai does not replace Figma or existing design tools with persistent Agents. He uses them to produce things worth reacting to earlier and to explore more directions. Experiments created three ambient-access prototypes: one living in the Mac notch, one peeking from a desktop corner, and one following the cursor. It handed character motion to Motion God and desktop behavior and engineering questions to Devbot, then combined the work into versions that could be experienced during a real day. None of the three concepts shipped unchanged. Their value was letting the designer judge when they were helpful and when they were intrusive. The guide directory describes the piece in the same terms: always-on Agents, real production assets, and retained human judgment.

GTM: give every customer and deliverable its own maintainer

Krista Letz first documented her own usage in an internal Notion page for Enterprise GTM dogfooding. She published the practice only after internal adoption expanded. Chief of Staff manages meetings, email, and orchestration of other Agents, and daily materials must be short, scannable, and usable on a phone during a commute. Prospecting maintains outreach state. Each strategic account can have a Customer Expert that reports only new material its state file shows has not yet been processed. Data Agent tracks customer usage. Product Expert connects to the codebase to give customers readable technical answers during calls, or can use an internal knowledge source such as Glean when repository access is unavailable. A 1:1 Agent prepares manager syncs. Forecasting Bot updates Salesforce opportunity notes from Granola, Gong, Slack, and email. Slides Bot maintains Figma masters according to supplied design rules and can translate customer decks. Sales Coach reviews Gong calls.

The Slides Bot boundary is directly reusable. Stop the recording 5–10 minutes before the end of the call; the Bot can then use the customer’s latest comments to update the “What we heard” slide. If no call has taken place, it may use first-party materials such as the company’s blog and earnings reports, but the slide must be titled “What they are prioritizing” and clearly cite those research sources. It cannot present public material as a customer quote.

PM: turn real attention into the new work list

Kevin Niparko starts from the fact that PMs often manage products without having direct reports. Persistent Agents gave PMs a team that could take objectives directly and help deliver them for the first time. He also says this way of working has a learning curve. Every hour, the Attention List reads Slack, email, Granola, and calendar activity to generate projects currently receiving attention, their status, and next steps. It derives from actual behavior rather than manually maintained weekly goals. An Agent can use it to filter the day’s message volume and archive emails unrelated to current priorities. The PM can compare stated priorities with where their attention actually went, review a week’s distribution of attention, and identify work that should later be delegated to an Agent.

One calendar example from Chief of Staff makes the autonomy boundary concrete. It first creates a tentative calendar hold and asks the person to choose a start time. Only after Kevin specifies a 10:00 start does it move the hold. The Agent completes information gathering and mechanical actions; the person decides the parameter that affects the schedule.

The data Agent relies on an existing consolidated chart for refreshes and slices; highly ambiguous interpretation remains with people.

The PM team also includes Ashley for data analysis, PM Pete as a product counterpart, and Recruiter. During onboarding, Engineering Manager first reads the Slack history of a respected human EM to learn how a strong engineering manager decomposes work, follows up, and reviews it. Training material for a Specialist therefore includes not just role instructions but the real work traces left by excellent practitioners. The data Agent mainly uses consolidated charts to revisit previously answered questions with refreshed data or a different tactical slice; analysis requiring substantial judgment or taste remains with people. PM Pete can turn scattered feature disagreements from channels, threads, or DMs into an RFC with direct quotes and P0–P2 priorities. It has also researched and purchased missing Raspberry Pi parts, then guided wiring. The author reports that Grok Bot accounted for a double-digit percentage of internal merged PRs at the time, but provides no time window, denominator, or rework data.

Step Six: keep sending, spending, deletion, and high-ambiguity judgments under human control

All five guides let Agents act, and all five place human gates at consequential points. They do not hide behind the phrase “human in the loop”; they specify where each class of action stops.

External emails are draft-only; ad spend requires prior approval; new Agents require approval; application changes pass through the deployment role; PMs still send most messages and edit important documents; and purchases and deletions require human confirmation. Highly ambiguous data questions stay with the human analytics team. Designers decide whether a motion should last 280 or 340 milliseconds instead of asking an Agent to self-assess whether it “feels right.”

Another equally important gate is silence. Chief of Staff sends nothing when there is no change. The inbox routine sends no report when nothing needs a reply. When an account’s weekly update has no new material, the Bot sends only one sentence. A Bot's workload can be large, but its notification volume to people must stay small. It escalates only when attention, approval, or unblocking is required.

Design and data judgment expose another boundary. An Agent can accelerate “make—react—revise,” but cannot decide which version feels right for a person. A data Agent is suited to refreshing consolidated charts and changing tactical slices; highly ambiguous questions that require strong judgment or taste remain with the human data team. Kevin ends with four rules: name the roles, separate their memories, let them learn in the role, and stay quiet unless something important needs a person.

None of Experiments' three ambient-access concepts shipped unchanged. It delegated motion to Motion God and desktop behavior and engineering questions to Devbot, assembled an experiential version, and then left the person to decide whether it was helpful, intrusive, or somewhere in between.

Step Seven: start with one verifiable loop and expand only when needed

The five guides do not recommend creating dozens of Agents at the outset. The mobile team starts with its most time-consuming data and product-feedback loop. The multi-project team starts with channels and task state. The designer starts with one experiential prototype. GTM starts by turning daily meeting preparation and inbox work into routines. PM starts with Chief of Staff maintaining the Attention List.

The mobile team also planned to add a revenue Bot and more ad networks, while other roles would wait until new problems formed persistent responsibilities. That expansion order is closer to the five practices than drawing a large organization chart in advance.

Good starting tasks usually have four properties: they recur; their input sources are clear; their outputs can be checked; and failure can stop and ask a person. After one human demonstration, record the task as a skill. Once repeated runs are stable, hand the output to the next Specialist. Add a role only when a new responsibility persists.

GTM's scaling experience adds detail to this path: generate a skill from one screen demonstration, learn style from the real sent mailbox, and continually write human edits back into the rules. As tasks multiply, let Agents work in parallel, have Chief of Staff audit them, and use group chat so multiple roles share the same objective and state. An audit looks not only for work that can be automated or parallelized, but also removes routines that no longer need to exist, preventing an automation system from only growing. What expands is a traceable chain of responsibility, not the number of isolated chats.

The minimal role card below is an editorial template synthesized from the five sources, not xAI's original text. Its six core fields come from the mobile development guide. Refusals, approval points, deliverables, and success criteria incorporate control practices from the other four guides.

name: analytics-agent
mission: Read real behavior and advertising data to produce verifiable findings
refuses:
  - Does not write ad creative
  - Does not modify product code
connections: [ads, attribution, product-analytics, revenue, errors]
environment: Dedicated cloud computer; ask when a connection is missing, never work around it independently
routines:
  - Summarize spend, installs, and cost every day
  - Check daily whether the product funnel matches the ad promise
skills: [export-ad-reports, fetch-creative-breakdowns]
handoffs:
  findings: creatives-agent
  product-specs: product-engineer
approvals: [any action that spends money, unexplained data conflicts]
deliverable: A report with sources, definitions, winners, losers, and next steps
success: The next role can act without guessing, and a person can audit every consequential judgment

At acceptance, ask only five questions: does it stay within its role; are its sources of truth correct; can failure explicitly enter Blocked; is the downstream handoff executable; and do consequential actions actually stop at approval points? If any answer is unclear, do not expand the team.

The five official guides: Multi-project teams, Mobile app development, Designing Grok Bot with Grok Bot, Enterprise GTM, and Product manager teams.