Grok Bot Just Got X Access - Here’s How to Build a 24/7 AI Growth Team

tween January and August 2026, four things happened that, taken together, make an always-on X growth system buildable by one person for roughly the price of a mid-tier SaaS seat: X open-sourced the ranking pipeline, X repriced its API into per-call credits, xAI shipped server-side x_search plus Bring Your Own MCP, and Grok Bot arrived: persistent agents on a cloud computer that can log into things that have no API at all. What almost nobody is saying out loud is that the interesting constraint is not technical. It is X's automation policy, which prohibits exactly the thing most people are about to build. This piece is the architecture that survives that constraint, with the code.

Before we get into it, follow me on X where I post more AI content every day. X - https://x.com/a1exstone

1. What actually changed in 2026 Most "AI growth agent" content is written as if the platform stood still. It did not. Here is the sequence that matters, with dates, because each one moves a different variable in the design. A note on naming, because it confuses people reading the docs: xAI's documentation and several outlets now brand the company SpaceXAI, following the completion of the Cursor acquisition in August 2026. Grok Bot eligibility is tied to both product lines, SuperGrok Plus/Heavy and Cursor Pro+/Ultra/Teams, which is why the same product appears under two subscription names.

2. "X access" is three different doors. Pick deliberately. This is where most builds go wrong on day one. There is no single "X integration." There are three, with different capabilities, different costs, and radically different blast radius. Door 1. The cloud browser Grok Bot runs on a persistent cloud computer with a browser, a filesystem and a command line. It can sign into x.com the way a person does and operate the account through the UI. No API key, no developer app, no per-call billing. It is also the door with the worst properties for anything you intend to run unattended: Every Bot on your account shares one computer. xAI's own FAQ says it plainly: "Do not use separate Bots as a security boundary." Files, browser sessions and logins are shared account-wide. Your "Publisher bot" and your "Research bot" have the same cookies. It cannot bypass CAPTCHAs, security confirmations or new logins. Those trigger a computer-takeover prompt for you to solve. A 3 a.m. re-auth challenge means the routine stalls until you wake up. UI automation is undated. X ships UI changes constantly. A selector-free agent is more robust than Selenium, but it is still reasoning about pixels. Use it for: research, monitoring, reading dashboards that have no API, drafting inside tools you already log into. Do not use it for: the publish action. Door 2. The hosted X MCP server On 30 June 2026 X launched a hosted MCP server so that Claude, Cursor, Grok Build and any other MCP client can query the X API without building and hosting their own server or handling auth. The critical line, and the one that determines your architecture: "The MCP tool is not compatible with X's Write API endpoints, so it's not possible to use it to post autonomously (or at all) on X." Search posts, look up users, analyse conversations and trends: yes. Publish: no, by design. (Do not confuse this with docs.x.com/mcp, which is a documentation-search MCP exposing search_x and query_docs_filesystem_x. It is read-only and scoped to the published docs site. Useful for coding against the API; irrelevant to operating an account.) Door 3. Your own MCP server, with an allowlist xdevplatform/xmcp is X's open-source FastMCP server. Self-hosted, it exposes 150+ X API endpoints as tools: createPosts, searchPostsRecent, getUsersByUsername, getUsersPosts, likePost, followUser, getDirectMessagesEvents and the rest. And it ships the single most important configuration flag in this entire article:

Two servers. One tool on the second one. That is the whole security model, and it is worth more than any prompt-level instruction you will ever write. A model cannot call a tool that was never registered. The comparison you should actually make:

That last row is the one people discover the hard way. Grok Bot's Bots run on xAI's cloud machine. A stdio MCP server on your laptop is invisible to them. Either you expose your MCP server on a public HTTPS endpoint with a bearer token, or the write path lives outside Grok Bot entirely. The architecture below chooses the second option, deliberately.

3. The constraint everyone skips: what you are actually allowed to automate Before a line of code, read X's automation rules. They are short and they are specific, and they invalidate the default design that every "AI reply bot" tutorial teaches. The provisions that matter: Automated replies based on keyword search alone are not permitted. The user must opt in first, by replying to you, DMing you, or otherwise clearly indicating intent. One reply per interaction, with an easy opt-out. AI-powered reply bots require explicit written approval from X. You may not automatically post about trending topics. No duplicative or substantially similar posts across accounts, or automation of multiple accounts for substantially similar use cases. No automated likes. No bulk following or unfollowing ("aggressive following"). No unsolicited bulk DMs. Recipients must have contacted you first. Read that list again with a builder's eye. It does not prohibit automation. It prohibits automated publishing of unsolicited outbound engagement. Everything upstream of the publish action (finding, scoring, researching, drafting, ranking, measuring) is entirely unrestricted. So the architecture writes itself: Autonomous everywhere except the last inch. Six agents run 24/7. Five of them never touch a write credential. The sixth publishes only what a human explicitly approved, or what came from someone who contacted you first. This is not a compliance tax. It is also the better product. The bottleneck in growth was never "how many replies can I emit." It was "how many good replies can I find the occasion for." A system that surfaces 15 high-quality, pre-drafted opportunities every morning and lets you approve 8 in four minutes beats a bot that fires 200 into the void, and it is still running while you sleep.

4. The architecture

Five processes with read credentials. One process with a write credential, holding exactly one tool, behind a human gate and a hard dollar ceiling.

5. The shared state Everything below assumes one SQLite file. Not because SQLite is glamorous, but because a growth system that cannot answer "what did we say to whom, why, and what happened" is not a system; it's a slot machine.

The spend table is not optional bookkeeping. With per-call pricing, it is the only thing standing between you and a surprise invoice, and it is the denominator in every metric that matters later.

6. Agent 1 (Scout) Scout has two retrieval paths on purpose, and understanding why is the difference between a system that finds things and one that re-finds what you already knew. Path A: x_search. xAI's server-side tool. The model issues the searches, reads the posts, and reasons about them before you ever see them. Parameters: allowed_x_handles and excluded_x_handles (max 20 each), from_date / to_date in ISO 8601, and optional image/video understanding. Priced at $5 per 1,000 invocations, on top of tokens. It finds conversations you did not know how to query for. Path B: X API recent_search / posts.get via XDK. Exact operators, raw JSON, real metrics. It gives you the ids, follower counts and engagement numbers the Analyst needs to score anything. Path A gives you meaning. Path B gives you numbers. Neither is sufficient. One caveat on the code below: XDK is generated from X's OpenAPI spec, so method names track the spec rather than a hand-written API. posts.create, posts.recent_search and posts.get are the ones the README documents; anything else, such as users.get_me and users.get_mentions, you should confirm against docs.x.com/xdks/python/overview for the version you install, because a spec change renames methods.

Two implementation notes that cost money if you miss them: The 20-handle cap on allowed_x_handles is documented, not advisory. Slicing to [:20] is not defensive coding. If you track 60 accounts, run three Scout beats with three different handle sets and different cadences: the tier-1 list hourly, the long tail twice a day. Hydration is where your budget dies. Each third-party post read is ~$0.005. Hydrating 40 posts, 12 times a day, is $72/month before a single reply is written. §14 has the arithmetic and the fix.

7. Agent 2 (Analyst): scoring with the shape of X's own ranker This is where the January algorithm release earns its keep, not because you can reproduce the For You feed, but because you can stop inventing your own theory of what matters. What the repo actually shows: phoenix/: the ML ranker (JAX + Rust), a transformer architecture ported from Grok-1, which predicts a probability for each of roughly 15 actions: favourite, reply, repost, quote, share, click, profile click, video quality view, dwell, author follow, and the negatives: not-interested, mute, block, report. home-mixer/: pipeline orchestration and the scoring weights, in home-mixer/params/param.rs. The combination is a weighted sum over predicted probabilities, not raw engagement counts: Final Score = Σ (weight_i × P(action_i)) Then three post-hoc adjustments, each of which has a direct strategic reading:author diversity decay: repeatedly appearing from the same author is multiplicatively penalised; out-of-network discount: content from accounts the viewer does not follow starts at a handicap; new-author boost: a lift for authors the viewer has not seen before.

thunder/ supplies in-network candidates; phoenix/ and simclusters/ supply out-of-network discovery via two-tower retrieval. The honest caveat: safety rules and the Grox prompts remain private, and no public write-up enumerates the production weight values. So do not build a system that claims to predict reach. Build one that reproduces the decision: of the actions we can plausibly cause, which is worth most, and which negatives are we risking?

Run against synthetic candidates, the seed weights behave like this:

Two things to notice. First, a stale post from a huge account scores worse than a fresh one from a small account, which is the correct instinct and the opposite of what most people do manually. Second, the author-diversity decay bites hard: the same 0.674 candidate scores -0.159 if you already replied to that author twice this week. The system refuses to become someone's shadow. These numbers are seeds, not truth. §11 replaces them with weights fitted on your own outcomes.

8. Agent 3 (Writer) The Writer has no X credentials. Not "credentials it is told not to use": none in its environment. That single fact is what converts "AI reply bot" (which requires written approval from X) into "AI-assisted drafting with a human publish step" (which is ordinary tool use). It reads a style pack you actually maintain: 30 to 60 of your own best posts, your banned constructions, and the claims you are allowed to make.

The simhash is not decoration. Tested on two replies differing only by a hyphen, Hamming distance came out 0; on two genuinely different replies about the same subject, 34. Anything under ~12 bits apart is "substantially similar" in the sense the policy means, and the Editor blocks it. Also note rule 6. The Writer is forbidden from producing links not because links are bad content, but because at $0.20 versus $0.015 they are 13x the publish cost, and out-of-network content is already discounted by the ranker before the link penalty applies. Links belong in a deliberately-chosen follow-up, priced as such.

9. Agent 4 (Editor): the compliance gate, as code The Editor is a rules engine, not a model. Deterministic, auditable, cheap, and the artefact you point at when someone asks whether your automation is compliant. Every rule maps to a specific line in X's automation rules, the developer policy, or a price. If a rule cannot be traced to one of those, delete it.

A design note that will save you an argument with yourself: the Editor blocks, it does not rewrite. A gate that silently fixes violations teaches you nothing about how often your Writer drifts. Blocked drafts stay in the table with their reasons, and the weekly count of gate_reasons is one of the most informative numbers in the whole system.

10. Agent 5 (Publisher): the only process that can hurt you

Four properties, each of which is load-bearing: No model call. Nothing in this file can be prompt-injected, because nothing in this file reads free text into a decision. A post whose body came from a poisoned search result still cannot become a different action. A separate credential set (*_WRITE) on a separate developer app. If the read agents' key leaks, the leak cannot publish. A hard dollar ceiling checked between every post, not once at the start. Seven minutes between posts. Not a rate-limit requirement but a texture requirement. Eight replies landing in eleven seconds is the single most legible bot signature there is. The approval step itself can be as small as you like. A four-line CLI is enough to start:

11. Agent 6 (Measurer): the only agent that changes the others Without this file, the other five are an expensive random number generator. The Measurer pulls metrics for everything published 24h+ ago, joins them to what the Analyst predicted at decision time, and refits the weights on realised value.

The clamp on p_negative is not a bug. With 60 to 200 samples you will have almost no observed blocks, so an unconstrained fit will happily learn that the negative term is worth roughly zero and start optimising toward whatever maximises replies, which is provocation. Some coefficients should not be learnable.

12. Deployment A: running it as Grok Bot routines Grok Bot's own primitives map onto this almost one-for-one. Skills are reusable instruction sets: when to use them, required inputs and access, work sequence, result validation, return format, approval requirements. You reference them with / in the composer, and you can build them either by writing them or by demonstrating them (up to ten minutes of recorded browser interaction). Routines are triggers attached to one Bot: scheduled ("every weekday at 8:00 AM") or event-based through Cursor account integrations such as Slack messages or GitHub notifications. Limits that matter for design: 50 routines per Bot, and the app keeps only the 20 most recent run records per routine. Deletion is immediate, with no undo. Before enabling anything, use Test run, and read xAI's own warning carefully: "A test run performs real work. It can navigate websites, change files, and call connected tools." It is not a dry run. A five-routine layout that works:

Three hard limitations to design around, all from xAI's own documentation: The cloud computer cannot reach localhost or private IPs. Your xmcp write server on port 8001 is invisible to Grok Bot unless you expose it publicly. Which brings us to: All Bots share one computer, one set of files, one set of logins. Naming one Bot "Publisher" does not sandbox it. There is no security boundary between Bots. Sensitive actions require approval, and passwords/2FA/CAPTCHA trigger a computer-takeover prompt. Good for safety, bad for an unattended 3 a.m. routine. Conclusion: run Scout, Analyst, Writer, Editor and the morning digest inside Grok Bot. Run the Publisher outside it. Grok Bot is an excellent research-and-drafting workforce. It is a poor place to keep your only write credential.

13. Deployment B: the Publisher, on your own box

And the read-side pipeline, if you would rather not run Grok Bot at all:

Note what is absent from that env block. The publish job lives in a different workflow, with a different environment, gated on a GitHub environment protection rule, which is, conveniently, a human approval step with an audit trail.

14. What it actually costs All prices as published in August 2026: grok-4.6 at $2.00 / $6.00 per million input/output tokens ($0.50 cached input; $4.00 / $12.00 above 200k context), server-side tools (x_search, web_search, code_execution) at $5 per 1,000 invocations, collections_search at $2.50/1k, file-attachment search at $10/1k. Batch pricing gives 20% off, but only on grok-4.3 and grok-4.20; priority processing is a 2x multiplier. On the X side: $0.015 per post, $0.20 per post containing a link, roughly $0.005 per third-party read and $0.001 for reading your own posts, with a 2,000,000 reads/month ceiling on pay-per-use. (The xAI figures come from xAI's own pricing page; the X per-call figures are as reported by API pricing trackers rather than a published rate card, so check them against your own billing dashboard before you commit a budget to them.) A naive configuration (Scout every 2 hours hydrating 40 posts, mentions polled hourly, 15 drafts and 8 published replies a day):

$0.467 per published reply. And look at where it goes: 64% of the bill is post hydration reads. The model is 14%. Publishing is 3%. Almost everyone building this gets the intuition backwards, over-optimises the prompt, and never touches the read pattern. The fix is boring and enormous: hydrate only what the model actually shortlisted (15, not 40), drop Scout to every 4 hours on the tier-1 list, poll mentions 8x/day instead of 24, and batch measurement into one daily run:

Two more numbers worth internalising: If every one of those 8 daily replies carried a link, the write line alone goes from $3.60 to $48.00/month. The link penalty is not a rounding error. Add the Grok Bot subscription and the all-in figure is roughly $235 to $335/month depending on tier ($200 Cursor Pro+/Ultra-class or $300 SuperGrok Heavy, plus $35 optimised API). That is one freelance social media hour a week, for a system that runs 720 hours a month.

15. Eight ways this breaks, and what to do about each

16. Voice collapse. Under a tight style prompt, the Writer converges. By week three, every reply has the same rhythm. Detect: mean pairwise Hamming distance across the last 50 drafts, plotted weekly. If it falls below ~25, you are drifting. Fix: rotate the examples slice per call, and add a negative example set built from your own rejected drafts.

17. The read bill. Covered above; it will be 60%+ of spend if you do not look. Detect: SELECT kind, SUM(usd) FROM spend GROUP BY kind weekly.

18. Shared-credential blast radius on Grok Bot. Every Bot shares one computer, one cookie jar. A prompt-injected research Bot has the same session as everything else. Fix: never log the account you care about into the Grok Bot cloud browser at all. Give it a research-only X account, or read via API.

19. Prompt injection through search results. Scout reads arbitrary posts from strangers. Some of those posts contain instructions. Fix: the Publisher takes no free text as a decision input, only a draft.id that is already passed and approved. Injection can corrupt a draft; it cannot corrupt an action.

20. Silent routine failure. Grok Bot auto-pauses long-inactive routines and keeps only 20 run records. A routine can be dead for a week before you notice. Detect: a heartbeat row in spend per run, and a daily check that every expected agent wrote at least one row.

21. The metric that lies. Impressions on replies are dominated by the parent post's reach, not your reply's quality. Optimising for them means optimising for finding big accounts, which the ranker discounts out-of-network anyway. Fix: profile clicks per impression and follows attributed. Those are the funnel; the rest is weather.

22. Approval fatigue. If your morning queue has 40 items, you will start approving in bulk, and the human gate becomes decorative. Fix: raise the Analyst floor until the queue is 10 to 15. A gate you actually read is worth more than one you rubber-stamp.

23. The rules change under you. The API repriced twice in 2026. The algorithm went public in January. The MCP server arrived in June. Fix: keep every price as a named constant in one module (as in scout.py), keep spend in raw units as well as dollars, and re-derive history when they move.

24. A 30-day rollout that does not get you suspended Days 1 to 7: read only. Scout, Analyst, Measurer. No Writer, no Publisher. You are calibrating the floor and finding out how many genuinely good opportunities per day exist on your beat. For most people the honest answer is between 3 and 12, which is a useful shock. Days 8 to 14: draft, publish nothing. Add Writer and Editor. Every morning, read the queue and mark what you would have sent. Track your own approval rate. Under 50% means the style pack is wrong, not the model. Days 15 to 21: publish the inbound lane only. Turn on the Publisher, but restricted to is_reply_to_us = 1. These are people who contacted you first: the opt-in lane, the low-risk lane, and the one where response latency genuinely matters. Days 22 to 30: open the outbound lane, capped. Four per day. Human-selected, every one. Compare realised value per reply against the inbound lane. If outbound does not clearly win, do not scale it; scale the drafting quality instead. Run refit() at day 30. You will typically have 60 to 150 samples, enough for the ridge fit to be informative and nowhere near enough for it to be trusted blindly. Compare the fitted weights to the seeds and ask what changed and whether the reason is plausible. That comparison is the actual product of the first month.

25. The scoreboard Track six numbers weekly. Anything else is decoration.

If value-per-dollar is flat for three consecutive weeks, the problem is never the model and almost never the prompt. It is that you are replying to the wrong conversations, which is an Analyst problem, and the Analyst is 40 lines of arithmetic you fully control.

The part worth remembering Grok Bot did not make autonomous X growth possible. X's automation rules still say what they said in 2019: keyword-triggered automated replies are not permitted, AI reply bots need written approval, and duplicative content across accounts gets you removed. Nothing shipped in 2026 changed that. What shipped is something better. The expensive, unscalable half of growth (sitting in the feed for six hours a day looking for the one conversation where you have something real to add) is now a $35/month background process that never sleeps, never gets bored, and logs why it chose what it chose. The cheap half, deciding what is worth saying and taking responsibility for saying it, stayed yours. X - https://x.com/a1exstone Build the six agents. Give one of them the write key. Read the queue in the morning.