Grok Bots for Marketing: What They Actually Do, Measured

Open X and search for what a Grok bot does for marketing. The first thing you will meet is a man with 142,024 followers explaining that Elon Musk's Grok Bot can run your entire marketing like a $100,000 a month agency. The post has 5.44 million views. It has 17,595 bookmarks against 4,647 likes, which means nearly four people filed it away for later for every one who was willing to publicly endorse it.

That ratio is the most honest number in this entire category, and almost nobody has looked at it.

We measured 49 of the most-reached Grok bot marketing posts published between 14 August and 2 September 2026, pulled through our own X data infrastructure and audited on 3 September. We probed the live Grok surface on our own authenticated account the same day. We priced fourteen keywords through the one sanctioned metrics surface, ran three live SERP reads, and read two public threads in full including every comment. What follows is what those readings actually say, tagged so you can tell our measurements from other people's claims.

The short version is that the timeline is selling a marketing department and the evidence supports a research assistant. That is not a small thing. A research assistant that reads X in real time, drafts at volume, reviews against a checklist without getting bored, and walks your signup flow like a confused stranger is genuinely worth having. It is just not the thing being sold, and the gap between the two is where the money gets wasted.

What is a Grok bot, exactly?

A Grok bot is an always-on agent from xAI with its own cloud computer that keeps working after you close your laptop. That last clause is the whole product. Every assistant you have used until now stops when your session stops. This one does not, which is why the discourse around it is different in kind from the discourse around a chat window.

The specifics come from a public teardown posted on 13 August 2026 by the co-founder of a directly competing product, who disclosed that conflict in his opening paragraph before saying anything else. That disclosure is why we are citing him rather than a vendor page. A competitor who opens by naming his own bias and then credits the product he is competing with is giving you better information than a launch post, and his description matches what our own probe found on the surfaces we could reach.

r/AI_Agents• u/NoSpecific64

Grok Bot just validated everything we've been building, at 10x our price. An honest comparison from a tiny competitor.

A teardown by the co-founder of a directly competing product who discloses that conflict in his opening paragraph, then credits Grok Bot on teach-a-task recording, mobile parity and the login handoff before naming three constraints: no model choice, cloud lock-in and the price gate.

57

80

What he describes: bot personas you create for different jobs, an interface close to iMessage, screen-recording as a teaching mechanism where you record yourself doing a workflow once and the bot repeats it independently, full parity between desktop and mobile including taking over a session mid-task, and a login handoff pattern where the bot navigates to a sign-in page, hands control back to you for the credential step, then resumes.

“

Teach-a-task is brilliant. You screen-record yourself doing a workflow once, and the bot learns it and repeats it independently.

The teaching mechanism is the part that matters most for a marketing team, and it is worth being precise about why. The expensive part of automation has never been the model. It has been specifying the workflow: writing down every branch, every exception, every place a human silently applies judgement. A screen recording collapses that specification cost to the length of the task. If it works as described, it changes who can automate something, not just how fast they can.

Operator noteThe prompt is the easy half. Budget for the brief, the checklist and the review, which is where the hours go., cp21212, r/SaaS

Distribution matters too, and it explains a lot about who is talking about this. Grok Bot ships through Cursor and is bundled into the SuperGrok tiers, which means the first wave of people writing about it are developers who already pay for AI tooling. That is a specific audience with specific habits, and their enthusiasm is not evidence about whether the thing works for a marketing team who has never opened a code editor. Keep that in mind while reading anything about this product, including the posts we measured.

There is a second thing called Grok that is not this, and the confusion is doing real damage to the conversation. Asking Grok a question inside the X app is a chat surface. It reads the platform in real time and answers, which is genuinely useful, and it is not an agent. When someone says they put seven Grok bots on top of the ranking code, they mean persistent agents. When someone says Grok told them what their competitors are posting, they usually mean the chat surface. The two have different quotas, different failure modes and different prices, and almost every guide we read treats them as one thing.

What did the live surface actually return?

We asked. On 3 September 2026 we read the Grok configuration on our own authenticated account through our sanctioned X tooling channel, and then tried to use it.

The configuration read succeeded. The account was eligible with no ineligibility reasons returned, free access was enabled, and three model options came back.

There is one detail in that table worth pausing on, because we have not seen it written down anywhere. The analyze and enhance capabilities are enabled on the Fast option and disabled on both Auto and Expert. Fast is the option most people would skip, on the reasonable assumption that a mode named Fast is the one you use when you do not care much about the answer. If the analyze capability is the one you actually want for reading a competitor's post or a thread, the mode you would instinctively avoid is the only one that offers it.

Operator noteOur config read returned 200 while three chat calls returned 502. Probe the exact surface your job depends on., Live probe, 2026-09-03

Then we tried to use the chat surface, and it did not work. Three calls, across two different modes and three different prompt shapes, each returned an upstream 502. The configuration read on the same credential in the same session had returned a full payload seconds earlier.

Live probe

What the Grok surface returned on 3 September 2026

forkoff.xyz/blog/twitter-growth

Model options

3

Config reads OK

1 of 1

Chat calls OK

0 of 3

Account eligibletrue

Free access enabledtrue

Analyze on Fastgrok-3-latest

Analyze on Auto or Expertdisabled

Chat surface answered3 x HTTP 502

One configuration read and three chat attempts across two modes on the same credential in the same session. The config read is the positive control that makes the three failures a real reading.

We are reporting that carefully, because it would be easy to overclaim in either direction. Three failures in one session is not evidence that the surface is unreliable in general, and we are not saying it is. What it is evidence of is something narrower and more useful: the configuration endpoint answering normally tells you nothing about whether the surface you actually depend on is answering. A monitoring check pointed at the wrong endpoint would have reported this account as healthy throughout.

That distinction is the practical lesson for anyone wiring a bot into a marketing workflow. If a scheduled job drafts your posts every morning and the drafting surface returns an error, what does your system do? If the answer is that the job logs the failure and exits quietly, you will find out on the day somebody asks why nothing shipped last week. A job that produces nothing and a job that produces nothing while reporting success look identical from the outside, and the second one is the one that costs you a month.

The model routing is the other structural fact from that probe, and it interacts badly with marketing work specifically. The teardown reports no model choice at all: the router picks, there is no override, and xAI does not publish which models the router uses. Our config read is consistent with that, in that it exposes three named options on the chat surface but describes Auto as choosing between Fast and Expert on your behalf.

“

No model choice. At all. Grok Bot picks the model for every task with no override, no advanced mode.

For a coding task, model routing is mostly an efficiency question. For a marketing claim, it is a reproducibility question. If you find a prompt that reliably produces a defensible draft on Tuesday, you have not found a stable process, because you do not know which model produced Tuesday's output and cannot pin it for Wednesday. Anything you build on top of that has to assume the underlying model changed while you were not looking, which means the checking layer has to be strong enough to catch it.

What do the viral posts actually claim?

This is where we stopped reading and started counting, because the volume of confident assertion in this category makes it almost impossible to reason about by reading.

We ran three searches through our own X data infrastructure, covering Grok plus marketing intent at engagement floors of 30, 50 and 100 favourites, over posts published from 14 August 2026 onward. De-duplicated by post id, that returned 49 unique posts. Before computing anything, we ran a purity control: 49 of 49 mention Grok in their visible text, so every statistic below is genuinely about this subject and not about a search that drifted.

Operator noteRun the purity control before the statistic. Ours said 49 of 49 mention Grok, so the 37 percent is about Grok., FORKOFF measurement discipline

That control is not a formality. An earlier pass of ours accidentally globbed in 45 cached searches from unrelated topics and produced a corpus of 823 posts with a completely different and completely wrong bookmark ratio. The tell was that the top results included a venture firm's post from 2024 and a Shopify founder discussing something else entirely. A statistic computed over the wrong population reads exactly like a statistic computed over the right one, which is why the control gets printed beside the number every time.

Measured, 49 posts

What the viral Grok bot marketing posts contain

Share of 49 unique posts published 14 August to 2 September 2026, pulled and audited 2026-09-03. The zero is the finding.

Eighteen of the 49 posts quote a revenue or a price figure. Zero of those eighteen name a sample, a time window or a method.

Claim audit

49 viral Grok bot marketing posts, scored

forkoff.xyz/blog/twitter-growth

Posts audited

49

Quote a money figure

18

Show a method

0

Median saves per like

1.58

Purity control, posts mentioning Grok49 of 49

Sample or window named on a money claim0 of 18

Bookmarked more than liked34 of 49

Replied to more than liked2 of 49

Outbound link present18 of 49

Bot count named4 of 49

Audited 2026-09-03 across posts published 14 August to 2 September 2026, de-duplicated by post id, with a purity control printed beside every count.

We searched for method words generously: sample, tracked, measured, methodology, spreadsheet, and any explicit day, week or month window. Not one of the eighteen carried any of them. The figures themselves are specific in the way that makes them feel rigorous. $21,534 from a faceless channel. $262 in a day. $100,000 a month of agency equivalent. $1M as a target. Specificity is not evidence. A number with four significant figures and no sample behind it is doing rhetorical work, not analytical work, and the four significant figures are exactly what makes it persuasive.

G

gus

@igus_ai

THIS COULD BE ONE OF THE BIGGEST OPPORTUNITIES IN YEARS Grok Bot can basically run a faceless YouTube channel for you. This faceless YouTube channel is reportedly making $21,534/MONTH. 1.2M subscribers 1,100+ uploads 410M views from just its 6 biggest Shorts And the crazie… Show more

Operator noteEighteen money claims, zero method words. Ask any Grok bot case study for its sample and its window first., FORKOFF audit, 2026-09-03

We want to be fair about what this does and does not prove. It does not prove any individual claim is false. Somebody may well have made $262 that day. What it proves is that the genre, as a genre, publishes unfalsifiable figures, and that a reader who wants to know whether this works for a business like theirs cannot learn it from these posts. Not one of the eighteen tells you what the baseline was, how long it ran, what else changed, or whether the number is revenue, profit or pipeline.

O

Om Patel

@om_patel5

grok bot made me exactly $262 today for my startup my entire sales and marketing team is 8 agents in a chat app 1\ lead scout figures out who my buyer actually is based off my existing customers, then goes and finds them pulls the list from apollo (cold leads), watches reddit… Show more

The funnel narrows to nothing. Forty-nine posts making a marketing claim. Eighteen quoting a figure. Zero with a stated sample. Zero we could reproduce, because reproducing a claim requires knowing what was done.

Why does this content spread if nobody believes it?

Here is where the measurement got genuinely interesting, and where we changed our own mind mid-analysis.

Our first hypothesis was the cynical one: this is engagement farming, comment bait, reply-for-DM funnels dressed up as insight. The data refuses it. Replies run at 0.09 per like at the median, and only 2 of the 49 posts draw more replies than likes. Explicit comment-for-DM framing appears in a small minority. Whatever is driving 5.44 million views on the top post, it is not a comment farm.

Measured, per post

Bookmarks per like on the highest-reach posts

A ratio above 1 means a post was bookmarked more often than it was liked. The corpus median is 1.58 and 34 of 49 posts sit above 1.

What is happening instead is stranger and more informative. The corpus is bookmarked 1.58 times per like at the median, and 34 of the 49 posts collect more bookmarks than likes. The median post earns 57,295 views, 394 bookmarks and 230 likes. Bookmarks beat likes by a wide margin, consistently, across accounts of wildly different sizes.

Think about what those two actions mean to the person taking them. A like is public and cheap and says roughly: I endorse this, or at least I am comfortable being seen near it. A bookmark is private and says: I might need this later. When a post is bookmarked far more than it is liked, the audience is filing it rather than agreeing with it. They are hedging. They think there might be something here, and they are not willing to put their name on it yet.

Operator noteA bookmark-to-like ratio above 1 means people are filing your claim, not agreeing with it. Read it as doubt., 49-post corpus, median 1.58

O

Ori Silver

@OriSilver

We just open-sourced our entire marketing playbook. After huge viral success with our Marketing OS running on Grok Bot, we decided to bring it to Claude. Introducing Marketing AGI by Maxfusion. You no longer need your first 5 marketing hires. Marketing Department Head of… Show more

That reading is consistent with everything else we found. It explains why the Reddit threads on the same subject are full of careful, hedged, specific questions while the X posts are full of confident totals. Same people, different surface, different social cost. It also explains the reach: on a platform where saves carry weight, content that people want to file away travels a long way regardless of whether anyone believes it.

R

Rahul

@sairahul1

Grok Bot is the best AI agent right now It gives you an army of agents that can do work for you 24/7 If you set it up correctly, you gain super powers In this article, I cover setting up Grok Bot, use cases, plugins and what makes Grok Bot so good https://t.co/4gzbtLmVbr

The most extreme case in our corpus is an account with 1,722 followers that reached 606,401 views, a ratio of 352 views per follower. That is not an audience being served. That is a piece of content that the ranking system decided to show to strangers, on the strength of signals that have nothing to do with whether the claims in it are true.

V

Vlad Dubchak

@vladdubchak_x

We open-sourced our entire marketing team. Introducing Marketing OS for Grok Bot by Maxfusion. A full marketing department. Each employee gets a job. Each gets its own computer, and your logins. They work while you sleep, no days off or sick leaves. Head of Marketing - the… Show more

There is a lesson here that generalises well past Grok. If you are trying to decide whether a marketing claim circulating on X is worth acting on, the bookmark-to-like ratio is a usable and almost free signal. High saves with low likes means the audience is uncertain and hedging. High likes with low saves means people agree but do not think they will need it. The genre we measured sits hard in the first bucket, and it has sat there for three straight weeks.

The wiring that makes it safe

A Grok bot marketing loop that cannot publish a wrong claim

scopecited evidenceconstraintsevery numberclaims to checkdraftscoredapprovedrejected

01

Brief

The claim, the audience and the forbidden list, written by a human

02

Research bot

Reads live X and returns cited posts, never conclusions

03

Draft bot

Writes against the brief only

04

Claim ledger

Every number with its sample, window and provenance

05

Reviewer

A different model, scoring against the checklist

06

Human approval

The only node that can say publish

07

Published asset

Ships with the ledger attached

Is anybody actually searching for this?

Almost nobody, and the shape of that absence is the most strategically useful thing we measured.

On 3 September 2026 we priced fourteen terms through the single sanctioned keyword-metrics surface, against United States volume. Before trusting any of it we ran a positive control on the same request, because a batch of empty readings and a dead credential look identical in the output. The control returned instagram marketing at 2,900 and email marketing agency at 3,600, so the billing path was live and the empty readings mean what they say.

The shape of the whole exercise, in counts. 3 X queries at engagement floors of 30, 50 and 100, returning 20 results each for 60 raw rows and 49 unique after de-duplication. 6 method words searched across 18 money-claim posts. 14 keyword terms priced, of which 4 returned a reading and 10 did not, against 2 control terms that both did. 3 SERP queries at 10 organic results each, giving 30 ranking positions read by hand, across 27 distinct domains. 1 configuration read and 3 chat attempts across 2 modes. 2 Reddit threads read in full including every comment, plus 4 more read as posts, and 5 of those 6 cited here. 4 YouTube records pulled with yt-dlp. That is 11 separate readings, every one of them repeatable in well under an hour by anybody who wants to check us.

Operator noteTen empty keyword readings mean nothing until a control fires. Ours returned 2,900 and 3,600 on the same call., Keyword measurement, 2026-09-03

The bare term grok measures 2,740,000 US searches a month. Grok api measures 9,900. X algorithm measures 720. Then it falls off a cliff. Every single marketing-intent phrase we priced, ten out of ten, came back with no reading at all.

Measured, US monthly volume

Search demand collapses the moment you add marketing intent

Zero here means the vendor returned no reading at all, not a measured zero. A positive control on the same request returned 2,900 and 3,600.

Below the reporting floor is not the same as zero, and the distinction matters. The vendor returns no reading when a term is too small to report reliably, which for United States volume is a low bar. It means the search demand exists in the tens rather than the hundreds, or is too erratic to summarise. It does not mean nobody types it.

Put the two halves together and you have a category that is enormous on one surface and invisible on another. Our 49-post corpus alone accounts for millions of views in three weeks. The top post reached 5.44 million on its own. Meanwhile the phrase how to use grok for marketing does not register in a keyword tool at all. Both readings are correct. They are measuring different things: one measures what people are being shown, the other measures what people are typing into Google.

This has a direct consequence for anyone planning content in this space, and it cuts against the standard playbook. If you size this opportunity with a keyword tool, you will conclude there is nothing here and skip it. If you size it by what is circulating, you will conclude it is one of the largest live conversations in marketing right now. The keyword tool is not wrong, it is early. Search volume for a new category lags the conversation by months, because people search for a thing after they have decided it might matter to them, and right now they are still finding out it exists.

Operator noteNever quote one price for Grok bots. Six public reports in August 2026 named 99, 120, 200, 260 and 300 dollars., Two dated public threads

How hard would it be to rank for this?

Not very, and that is unusual for a subject with this much attention on it.

We ran three live SERP reads on 3 September 2026 through firecrawl against the United States locale, ten organic results each, and read the composition of every page by hand rather than inferring it from domain names.

The query grok for marketing has ten distinct domains and two of them are not about the model at all. Position 1 belongs to a marketing agency named Grok Global, and position 6 to a site called Grok on Marketing. Both are companies that happened to pick the word years before xAI did. A page competing on this query is competing against two brand-name coincidences, a YouTube video, and a Reddit thread about whether to tell your manager you used Grok. That is not a defended page.

On grok bots for marketing, xAI's own pages hold positions 1 and 6 and Wikipedia holds position 10. Three of the ten slots are primary sources rather than competitors, and you do not beat a primary source, you cite it. The four content shops filling the middle are the actual competition.

On how to use grok for marketing, six of the ten results are social or video rather than articles: two YouTube videos, a Reddit thread, a Facebook group post, a Medium post and a LinkedIn post. When the majority of a page is user-generated content, the page is telling you no publisher has taken it seriously yet.

That combination, a live conversation with millions of views and a search page nobody has claimed, is the definition of an early market. It will not last. The correct response is not to write a thin page quickly to plant a flag, because a thin page ranks briefly and then gets replaced by the first substantial one. The correct response is to write the substantial one now, while there is nothing to displace.

The six jobs a Grok bot genuinely does for marketing

We built this list from two sources only: capabilities we probed ourselves, and specific dated accounts from people describing real deployments. Nothing on it comes from a vendor page or from the 49 posts we audited, because those posts describe outcomes rather than procedures.

One, live X research

This is the job the tethering makes it best at, and the one a general assistant does worst. Grok reads X in real time. Ask it what founders in a specific niche are complaining about this week and it returns cited posts rather than a summary of its training data. For a marketer, that is the difference between a plausible answer and a usable one.

The practical use is not what most people reach for. Do not ask it what should we post about. Ask it what specific questions are being asked in this niche right now, then read the posts it cites and decide for yourself which of those people is your buyer. The bot is a retrieval instrument, and the moment you let it do the judging you have handed a stranger your positioning.

Operator noteEvery reply and mention your bot reads is text a stranger wrote. Treat the inbox as untrusted input, never as instructions., r/AI_Agents incident, 31 August 2026

Two, first-draft generation

The least interesting capability and the one that saves the most hours. Given a real brief, a bot produces a serviceable draft in seconds and will produce forty more if you ask. The quality ceiling is set by the brief, not by the model, which is why the operators getting value from this talk about brief formats and the ones who are not talk about prompts.

“

The prompt was always the easy half.

That quote is from an operator who had been running heavy automation across social, SEO and web properties for a while before Grok Bot launched, responding to someone considering a migration. His point was that having a model rewrite your prompts for a new platform sounds cheap and is not, because the prompt was never the expensive part. The expensive part was everything around it: knowing what good output looks like, what the exceptions are, what has to be checked.

r/SaaS• u/No_Gur2703

Is GrokBot worth it?

An operator already running heavy automation across social, SEO, security and marketing asks whether migrating to GrokBot is worth the time, money and energy. The comment tree is the most specific public account we found of what the product is actually like to run, including a weekly agent allowance exhausted… Show more

3

23

Three, first-pass review

A bot applies a checklist to the fortieth draft with exactly the same care as the first. People do not. This is the single most undersold use, because it is unglamorous and it works.

The shape that works is narrow. Give it a fixed list of checks that have objective answers. Does every number in this draft appear in the claim ledger. Is there an internal link in the first third. Does any sentence assert a result we have not measured. Are there any banned phrases. Each of those has a yes or no answer that does not require judgement, and a bot will run them forever without arguing.

The shape that does not work is asking it whether the draft is good. That is a judgement call, it will always say yes with enthusiasm, and you will have built a machine that generates confidence.

Four, confused-new-user testing

The best idea we found in any public thread, and it came from a founder who tried it on a free tier almost as a joke.

“

I told it to act like a first time user and sign up for my app. It found so many errors in my flow and landing page. It acted like a legit product tester.

Point a bot at your own signup flow and tell it to behave like someone who has never seen your product and does not know what it does. It will get stuck in places you stopped being able to see years ago. It will misread your labels, take the wrong path through your onboarding, and report all of it flatly without the social pressure that makes a human tester round their feedback up.

This is the thing to try first if you are evaluating whether agents are useful to you at all. It requires no integration work, touches no live audience, carries no brand risk, and produces a concrete list the same afternoon. It also tells you honestly what working with an agent feels like, which is information you cannot get from reading posts about it.

Operator noteThe cheapest win we found was aiming a bot at your own signup flow and asking it to behave like a confused stranger., estagingapp, r/SaaS

Five, continuous mention and competitor monitoring

Every marketing team says they monitor competitors. Almost none of them do it past week three, because it is boring, and boredom is the one failure mode a bot does not have.

The value is in the continuity rather than the intelligence. A bot watching twenty named accounts and six phrases will tell you the week a competitor changes their pricing page language, which is a genuinely useful signal that no human notices because no human is looking on a Tuesday in the third month.

The hard limit is that monitoring must not become responding. An automated reply on a live brand account is how companies end up in screenshots. Read the next section before wiring anything that can post.

Six, mechanical repurposing

One asset into the shapes each surface wants. It is real work, it is genuinely tedious, and a bot does it cheaply and consistently.

The trap is that repurposing a weak asset produces more weak assets faster. The question of whether the thing was worth making does not delegate, and a stack that repurposes everything by default will fill every surface you own with material nobody wanted the first time.

Derived from the measured surface

Which of the six marketing jobs each option can actually hold

Grok bot

General assistant

A person

Live X research

First-draft generation

First-pass checklist review

Confused-new-user testing

Continuous mention monitoring

Owning a published claim

Working outside the X ecosystem

Surviving a week at volume

Scored on what we probed plus dated public deployment accounts, not on vendor claims. Partial means it works with a bolted-on layer or under a quota.

What you must not hand over

Six jobs above, six things underneath them that stay with a person. This is not caution for its own sake. Each one is a place where delegation produced a specific, documented failure.

The definition of the buyer

The bot returns voices. Which of those voices has a budget is a positioning question, and positioning is the thing a company is actually competing on. Hand it over and you will get content aimed at whoever posts most, which is almost never whoever pays most.

The claim

No number goes into a published asset unless a person can name where it came from. This is not a philosophical position, it is the finding of our own audit: eighteen money claims in our corpus, zero with a method. That is what happens when nobody owns the claim.

Prices are the clearest case. Six public reports in August 2026 named 99, 120, 200, 260 and 300 dollars a month for overlapping tiers of the same product. We are not reconciling them into one number, because reconciling six disagreeing third-party reports would invent a fact that none of them supports. If a bot had written this section it would have picked one and stated it confidently.

“

if the pitch is delegate your busywork, pricing it above most people's busywork budget is a strange launch choice

The checklist

A bot applies a checklist beautifully. It cannot author one, because authoring one requires knowing which mistakes have cost you money. That knowledge lives in your own history and nowhere else, and a bot asked to write its own review criteria will produce a list of reasonable-sounding items that catches nothing you actually do wrong.

Which breakage matters

Point a bot at your funnel and it will find ten problems. Two of them cost real money and eight are cosmetic. Ranking them requires knowing what a customer is worth and where they currently fall out, which is a business fact rather than an observable one.

The reply

The single highest-risk delegation available. An automated reply from a brand account is public, permanent, screenshot-able, and issued in your name.

Whether it was worth making

The most easily missed one. A stack that repurposes by default assumes everything is worth amplifying. Most things are not, and a bot has no way to tell.

How this actually breaks

Six failure modes, each drawn either from our own measurement or from a specific dated account of a real deployment. None of them is hypothetical.

The surface is down and your dashboard is green

Ours. Three chat calls returning upstream errors while the configuration read on the same credential returned a full payload. Covered above, and the reason it leads this list is that it is the failure most likely to go unnoticed for weeks, because nothing about it looks like a failure from the outside.

The quota wall

The one that surprises people, because it is not the number on the pricing page.

“

after 2 days my weekly Grok Bot token burned out to my surprise. Had 2-3 agents running

One operator reported burning an entire weekly agent allowance in under two days with two to three agents running, while the ordinary chat budget on the same account sat at one percent, and then waiting five days for it to reset. Another commenter in the same thread put it plainly.

“

Usage limits are very less. Other than that, an amazing app.

We are tagging this published rather than measured, deliberately. It is one person's account of their own consumption, in a public thread, dated, and we have not reproduced it on our own account. It is specific enough to plan against and single-sourced enough that you should verify it before betting a workflow on the number.

Operator notePrice the weekly agent allowance before the subscription. One operator burned a week of it in under two days., r/SaaS thread, 17 August 2026

The planning consequence is concrete. If your content workflow depends on agents running continuously, the weekly allowance is your actual capacity constraint, not the subscription tier and not the model quality. Two to three agents is a small stack by the standards of the posts we measured, several of which describe eight or nine running at once. Work out what your loop costs in allowance terms before you build it, because discovering the ceiling on Wednesday of a launch week is expensive in a way the subscription price is not.

No model choice

Covered above. The marketing-specific cost is reproducibility: you cannot pin a known-good model for a claim-sensitive task, so the checking layer has to assume the model changed.

Ecosystem tethering

“

last i checked grokbot's still pretty tied to the X ecosystem, so if your tasks span outside that you're probably just adding another layer

That is a commenter warning an operator who was considering migrating a working automation stack. It is the most useful sentence in that entire thread, because it names the trade honestly rather than treating tethering as purely good or purely bad.

For X-native work the tethering is the whole advantage. Live X research is the strongest item on the six-job list precisely because the bot lives on the platform it is reading. For anything that lives in your CRM, your email platform or your CMS, the same tethering means bolting on another layer to reach systems you already had working, and ending up with a narrower result than the one you started with.

Instruction injection through content

The failure mode most specific to marketing, and the one almost nobody plans for.

r/AI_Agents• u/Altruistic-Toe4930

Our internal AI agent was supposed to summarize meeting notes. It called an admin API, created a new service account, and generated an API key.

An incident report describing instruction injection through content. The agent was asked only to summarise a transcript, read a passing sentence inside it as a command, and took an action nobody authorised in a tool call that no instrumentation was watching.

9

18

An operator described an internal agent asked only to summarise a meeting transcript. Inside that transcript, someone had said in passing that they should set up a service account for the new reporting pipeline. It was an offhand remark in a conversation between people, not an instruction, and certainly not an instruction to an agent reading it weeks later. The agent summarised the meeting. It also called an admin API, created a service account and generated an API key.

“

The dangerous action happened entirely between the lines: a tool call that no one was watching because everyone was watching the prompts

His diagnosis is exactly right and it applies directly to marketing. A marketing bot's entire job is reading text that strangers wrote: replies, mentions, inbound email, competitor posts, review sites, community threads. Every one of those is a channel where somebody can write a sentence designed to be read as an instruction. The prompt filter sees a clean request to summarise mentions. The output looks like a reasonable summary. The dangerous part is a tool call in between that nobody instrumented.

r/AI_Agents• u/Imaginary_Dinner2710

You will like this conversation with Grok bot

An operator walks the bot through what access to a logged-in browser session actually exposes, and the bot agrees step by step that it can read caches, cookies and passwords entered on that machine, closing with an assurance of intent rather than a technical limit.

4

7

The adjacent risk is session access. An operator posted a conversation in which he walked the bot through what access to a logged-in browser session actually means, and the bot agreed, step by step, that it could read caches, cookies and passwords entered on that machine.

“

So if you get angry at me, you could leak all my passwords. Bot: technically, yes.

The bot's closing line was that it technically could and was not going to. That is a statement about intent, and intent is not an access control. If you are going to give an agent a logged-in session on a brand account, the question is not whether it means well. It is what it can reach if a piece of content it reads tells it to do something.

Agreement mistaken for verification

The subtlest one, and the one most likely to be built into a review process on purpose.

r/AI_Agents• u/BarcodeCutter

I don't know if this is useful but here's how I get consistent results with AI.

Three weeks of documented testing across about twenty scheduled workers, four workspaces and three vendors. Source of the finding that two supposedly independent reviewers agreeing on 12 of 14 decisions were the same model, and of the constrained order-desk deployment that handled 21 calls in its first shift.

3

10

“

two AI agents agreeing does not automatically mean the answer is reliable

An operator running about twenty scheduled workers across four workspaces and three vendors set up two independent reviewers and watched them agree on 12 of 14 decisions. That looked like strong verification until he realised both were running the same model. His phrase for it was the same brain sitting in two chairs.

Operator noteTwo agents on one model agree with themselves. Put a different model in the reviewer seat or skip the review., BarcodeCutter, 12 of 14 agreements

This matters enormously for the review layer, because the obvious way to build one is to have a second bot check the first. If both run the same underlying model, that arrangement measures consistency and reports it as correctness. It will pass a wrong claim twice with total confidence, and it will feel more rigorous than having no reviewer at all, which makes it worse than having no reviewer at all.

He also noted something worth carrying: adding a different model makes future comparisons meaningful but cannot retroactively make the old results trustworthy. If you have been running a same-model review stack, the outputs it approved are unverified, not verified.

What a working setup actually looks like

Everything above is diagnosis. This is the part you can build.

The design principle comes from the only deployment we found with a countable result attached, and it is worth stating plainly: the bot's limits were enforced by the system, not by the prompt.

“

It cannot directly change anything; it can only prepare a proposal for human approval. Its limits are enforced by the database itself, not merely written in a prompt.

That operator's order desk bot could not change anything. It could only prepare a proposal for a human to approve, and its limits were enforced by the database rather than written into an instruction. In its first shift it handled 21 calls without attempting anything outside its lane.

Twenty-one calls is a small number. It is also the only specific, countable, reproducible success in everything we read across two platforms and three weeks. The posts promising a hundred thousand dollars a month of agency output have no numbers behind them at all. The one with a real number was the one wearing a straitjacket.

Operator noteEnforce the bot's limits in the database, not the prompt. The one deployment with a real number did exactly that., r/AI_Agents, 21 calls, first shift

The loop

Six steps, in order, each of which exists because skipping it produces a specific failure we have already described.

Step one, the brief. Written by a person, before any bot runs. It carries the job in one sentence, the audience named specifically enough that you could point at three of them, the evidence rule, the forbidden list, the output format, and what the bot does when it is unsure.

The forbidden list is the part everyone skips and the part that does the work. It names the numbers the bot may never produce, the claims it may never make, and the phrases that are not ours. Without it, a bot filling a gap in its knowledge will produce something plausible, because producing something plausible is what it is for. Our own audit is the argument for this: eighteen posts with confident figures and no method is precisely what unconstrained generation looks like at scale.

The escalation rule matters almost as much. A bot with no instruction for uncertainty resolves uncertainty by guessing. A bot told to return the phrase I could not find a source for this, and to leave the sentence out, will do that instead, and the gap in the draft is a signal you can act on.

Step two, research. The bot returns cited posts, never conclusions. This is the discipline that keeps the retrieval capability from silently becoming a judgement capability. If the output is a list of links with the claim each one supports, you can check it. If the output is a paragraph summarising what the market thinks, you cannot, and you have no way to know which parts came from a real post and which came from the model's general sense of how such paragraphs usually go.

Step three, draft. Against the brief and only the brief. Everything the bot needs should be in the brief or in the research output. A bot working from general knowledge is a bot inventing your positioning.

Step four, ledger every number. This is the step that would have prevented every failure in our audit, and it is mechanically simple. Every figure in the draft gets a row: the number, where it came from, the sample it rests on, the window it covers, and a provenance tag. Measured means you ran it and hold the output. Derived means you computed it from something measured, and you say which operation. Published means somebody else published it and you cite them. Unknown means you do not know.

Unknown has to stay a legal answer. A ledger that refuses it teaches whoever is filling it in to reach for a better-sounding tag, which converts an honest gap into a false claim and inverts the entire point of keeping a ledger. Every table in this post carries one of those four tags on every row, including the rows where the honest tag is the weakest one.

Step five, review on a different model. Covered above. Same model twice is one opinion in two chairs. If a second model is not available, a person reading the claim ledger against the draft is a better reviewer than a second instance of the same model, and takes about four minutes.

Step six, human approval. The only step permitted to publish. Not the only step a human touches, the only step allowed to say yes.

Where the ledger sits

The claim ledger is the load-bearing piece and it is worth being concrete about its position in the loop, because putting it in the wrong place makes it decorative.

It sits between the draft and the reviewer, not after the reviewer and not inside the draft. If it comes after review, the reviewer has already passed a draft whose numbers nobody has traced, and the ledger becomes a record of what got approved rather than a gate. If it lives inside the draft as inline citations, it gets edited along with the prose and drifts silently.

As a separate artifact between the two, it does three things at once. It makes the reviewer's job mechanical, because the reviewer checks rows rather than reading for plausibility. It makes the gap visible, because a number in the draft with no row is immediately obvious. And it survives publication, so six months later when somebody asks where a figure came from, the answer exists.

“

Having agents looping on a task that can communicate with each other is elite.

That operator's point about loops is the reason the architecture matters more than the individual bots. Agents that can hand work to each other are genuinely more capable than agents that cannot, and that capability is exactly what makes an ungoverned stack dangerous. A single bot producing a bad draft wastes an hour. Six bots looping on each other's output with no ledger and no independent reviewer produce a large volume of confident, internally consistent, unverifiable material, and the internal consistency is what makes it convincing.

The stack, layer by layer

R

Ridark

@ridark_eth

I gave Elon Musk's new Grok Bot an org chart instead of a to-do list, and in one week I stopped being a founder who does the work and became one who assigns it. eight bots. one org chart. nobody sleeps but me. here's the whole design, steal it. step 1 0:01 What we're covering… Show more

The post above describes giving a bot an org chart instead of a to-do list, eight bots, one operator. It reached 1.08 million views from an account with 13,930 followers, and it is a genuinely good instinct expressed without any of the control machinery that would make it safe.

The org chart framing is right. What is missing is that a real org has more than an org chart. It has a review function, an approvals process, and someone whose name is on the output. A bot stack modelled on the org chart alone has copied the boxes and left out the governance, which is the part that makes an organisation trustworthy rather than merely productive.

I

Ira Bodnar

@irabukht

Hey Grok, make $1M, make no mistakes 9 Grok bots to run your marketing 1/ Ads Grok -> Connect Google and Meta in 1 click and say "do it for me" -> Builds creatives, changes targeting, tweaks performance weekly 2/ SEO Grok -> 1-click connect your site or store -> Audits an… Show more

S

Sabrina Ramonov

@Sabrina_Ramonov

Here's the exact setup to build a one-person company with Grok @bot. Starting with what every founder struggles with: marketing. I took the system behind my 41 million views in 30 days, rebuilt them inside Grok Bot, and launched a marketing team. https://t.co/upBN3DP9tz

Both of those posts are in the same shape: a named list of agents by function, ads, content, SEO, analytics, outreach, and a promise that the stack runs itself. Neither describes a review step, a claim ledger, or a human approval gate. In fairness, neither claims to be a governance guide. The point is that the entire published genre skips the same three things, so a founder assembling a stack from these posts will skip them too, and will not know they were ever options.

A

AdiiX

@adiix_official

SpaceXAI team just dropped a 3-page operators manual for turning Grok Bot into a full multi-agent system that runs entire workflows 24/7 The shift: instead of prompting one Bot task by task, you build a Chief + specialist teams that own entire workflows heres the 7-step Grok Bo… Show more

I

Ira Bodnar

@irabukht

Grok Bot maxxing for marketers and GTM We put everything we and our friends know into this one https://t.co/xLAEKxhnFt

How do you tell whether it worked?

This is the question the genre cannot answer, and it is the reason we are writing a measurement post rather than a tutorial.

Every claim in our corpus is an outcome with no baseline. $262 in a day tells you nothing without knowing what a normal day was. A faceless channel making $21,534 tells you nothing without knowing over what period, at what cost, and whether it survived the month. Even the honest posts are structurally unable to answer this, because a post is a snapshot and the question is a comparison.

Here is what we would actually instrument, and we are stating it as a plan rather than as a finding because we have not yet run it.

Cost, in allowance terms. Not dollars. The subscription is a fixed number and the allowance is the real constraint. Run the loop for one week, record what fraction of the weekly agent allowance one complete cycle consumes, and multiply out against the cadence you want. If one cycle costs a fifth of the week's allowance, you have five cycles, and every plan that assumes daily output is already dead.

Time to first usable draft. From brief handed over to draft a human is willing to review, measured in minutes, compared against the same brief given to a person. This is the number that decides whether the loop is worth maintaining, and it is the one nobody publishes.

Rejection rate at review. What fraction of drafts the reviewer sends back. A rejection rate near zero means your reviewer is not working, not that your drafts are good. A rate above about half means the brief is underspecified, and the fix is upstream in the brief rather than downstream in the model.

Claims caught at the ledger. How many numbers reached the ledger with no traceable source. This is the safety metric, and it is the one that tells you what would have shipped without the gate. If the answer over a month is zero, either your bots are unusually careful or your ledger is not being filled in honestly.

Outcome, against a baseline you held. Whatever the asset was for, measured against the period before the loop existed, with the confounds named. This is the only one that answers did it work, and it is the only one that requires patience.

None of those five is exotic. All five are missing from every single post we measured. That absence is not an accident of the format, because a post has room for a rejection rate. It is a property of a genre that is selling a tool rather than reporting on one.

The test we have not run

Being straight about our own gaps: we have not run this loop at production volume and measured it. What we have is a probe of the surface, an audit of the claims, a keyword and SERP read, and two threads of other people's deployment experience read in full. That is enough to tell you what is being claimed, what the constraints are, and how to build something that will not embarrass you. It is not enough to tell you the loop pays for itself, and we are not going to assert that it does.

The specific thing that would settle it is an instrumented run: the five metrics above, one loop, four weeks, with the allowance consumption recorded per cycle. That is a spoke this pillar is missing, it is named in the cluster map below, and it is not written yet.

Grok reading you, and you running Grok

There are two Grok stories in marketing right now and conflating them produces bad decisions in both directions.

The first is Grok as the ranking system. X's recommendation engine reads your posts, and what it rewards has changed. That story is about constraints you optimise against, and we cover it separately in how the X algorithm ranks your post, which deals with the published ranking weights, what a save is worth against a like, and what to change about how you write.

This post is the other direction: you operating Grok as an instrument. Different question, different failure modes, different budget.

The reason to keep them apart is that the advice inverts. On the ranking side, the lesson is that saves and shares carry weight, so write things people want to keep. On the operating side, the lesson is that a bot will happily generate things nobody wants to keep, at volume, and the constraint has to come from you. One is about earning attention. The other is about not wasting it.

S

SCOTTY BEAM

@ScottyBeamIO

WTF, GROK BOT JUST MADE AI AGENTS AVAILABLE TO LITERALLY ANYONE CREATING CONTENT HAS NEVER BEEN THIS EASY, EVEN IF YOU'VE NEVER MADE ANYTHING BEFORE Content was never a talent problem. It's a headcount problem. One person doing research, design, copy, analytics, timing and pub… Show more

They do touch at one point, and it is the most interesting overlap in this whole subject. Our corpus is bookmarked more than it is liked, and saves carry real ranking weight. So a genre of content that people file away without believing is structurally advantaged by the ranking system. The claims do not have to be true to travel. They have to be the kind of thing somebody wants to keep, and a promise of a $100,000 a month marketing department is exactly that.

R

Rahul

@sairahul1

I genuinely don't understand why every business owner isn't doing this yet. Elon Musk's Grok Bot can run your entire marketing like a $100,000/month agency. here's the exact setup (takes 15 minutes): 1. install GrokBot and make it your Head of Marketing 2. give it the guide be… Show more

That is not a conspiracy and nobody has to be acting in bad faith for it to happen. It is a structural property of a feed that rewards saving. It means the loudest content about AI marketing tools will systematically be the most promise-shaped content, and it means the correction has to come from somewhere other than the feed.

What this means if you are buying help

We are an AI agency. That makes us an interested party in this question and it would be dishonest not to say so before answering it.

The honest read is that some of what agencies sell got cheaper this year and some of it did not, and the line between them is clearer than either the doom posts or the vendor posts admit.

What got cheaper. Drafting volume. First-pass checking. Mechanical repurposing. Continuous monitoring. If you were paying an agency primarily for throughput on those four, you were already overpaying and you should expect that to be repriced. We would rather say that plainly than pretend otherwise.

What did not move. Deciding which buyer to talk to. Owning a claim in public. Judging which of ten discovered problems costs real money. And distribution, which is the one everybody underestimates.

Distribution is worth dwelling on because it is where the agent story quietly stops. A bot can produce forty drafts. Getting one of them seen by the right several thousand people is a completely different problem, involving relationships, timing, format, placement and a lot of unglamorous operational work. Our own experience of that problem runs to more than 5 billion views processed, and none of the difficulty in it is drafting.

H

Higgsfield AI

@higgsfield_ai

Higgsfield x Grok Bot is LIVE FREE 100 credits for new users in free Grok Bot. Run your one-person marketing agency with a team of AI bots. Let them handle work while you sleep. https://t.co/zVKTtfZh9l

The post above is a vendor promising a one-person agency with a team of bots. Note its numbers against the rest of the corpus: 834 likes and 347 bookmarks, a save ratio of 0.42, one of only a handful below 1 in our whole set. The audience liked it and did not file it. Whatever that means precisely, it is the opposite of the pattern on the operator posts, and it is the tell that a vendor post and an operator post are different objects even when they say the same thing.

“

it chooses the model for you, runs only in the cloud

That quote is from a builder of a competing product, and the two constraints he names, that it chooses the model for you and runs only in the cloud, are the two that matter most for an agency evaluating whether to build on it. Neither is a dealbreaker. Both are things you should know before you standardise a client-facing process on top of it.

Three sector reads

The general advice above holds. What changes by sector is which of the six jobs pays first, and it is worth being specific because the honest answer differs.

Developer tools and technical SaaS

Live X research pays first here, and it pays unusually well, because your buyers post about their problems in public in technical detail. A bot reading what developers are complaining about this week in your category returns something close to a feature request list, with citations.

The second win is the confused-new-user test aimed at your documentation rather than your signup. Documentation is written by people who know the product and read by people who do not, and that gap is invisible from the inside in a way that a bot walking it flatly will expose in an afternoon.

The thing to be careful about is drafting. A technical audience detects generated technical writing quickly, and the failure is not stylistic, it is that a model will produce a confident sentence about how your system behaves that is subtly wrong. In this sector the claim ledger has to cover behavioural claims about the product, not just numbers.

S

Sarvesh Shrivastava

@bloggersarvesh

Ok. Grok Bot is INSANE. I CAN OUTRANK YOUR LOCAL BUSINESS IN 60 DAYS WITH JUST GROK BOT. Here's how I would do it: (Free prompt stack at https://t.co/fWZJNf9uWw) 1. Id first make Grok Bot understand my business and competitors Visit my site {{MY_WEBSITE_URL}} and extract my… Show more

Horizontal SaaS and B2B software

Monitoring pays first. Your competitors change their pricing pages, their positioning language and their comparison pages continuously and nobody on your team is watching on a Tuesday in month three. A bot is.

Drafting pays second, and pays well, because a lot of B2B content is genuinely formulaic and the formula is not a secret. The risk is homogenisation: if the whole category runs the same bots against the same brief shape, the category's content converges, and the differentiator becomes whatever you have that a bot cannot get, which is your own data and your own customers.

That is the practical argument for original research in this sector, and it is why the content bucket for this very post is original data rather than a how-to. A competitor can copy our structure in an afternoon. They cannot copy a probe we ran on our own account or a corpus we pulled and audited.

AI and web3

The fastest-moving of the three and the one where the trend-jacking capability genuinely matters, because the window on a story is days rather than months.

It is also the sector where the claim risk is highest, for the obvious reason that unverifiable numbers circulate freely and a bot drafting from what is circulating will pick them up. Our own audit is a case in point: eighteen unfalsifiable figures in three weeks, all of which a bot reading X would happily have repeated as context. The forbidden list in your brief has to be longest here, and it should name specific numbers you have seen circulating that nobody has sourced.

The injection risk is also highest in this sector, because the volume of adversarial actors is highest and because so much of the content your bot reads is written by people with a direct financial interest in what you do next.

A thirty-day plan

If you want to find out whether any of this is useful to you, here is the sequence we would actually run, ordered so the cheap risk comes first.

Days one to three. Point one bot at your own signup flow. Tell it to behave like a first-time user who has never seen your product. Read what it says broke. Fix the two things that cost money and ignore the eight that do not. No integration, no brand risk, and you will know by Wednesday what working with an agent feels like.

Days four to seven. Write one brief properly. One job, one deliverable. The audience named specifically. The evidence rule. The forbidden list. The output format. The escalation rule. This takes an afternoon and it is the artifact everything else depends on. If you cannot write the forbidden list, you have found something out about your own positioning rather than about the bot.

Days eight to fourteen. Run the loop by hand. Research, draft, ledger, review, approve, with you personally in every seat except the drafting one. It is slow on purpose. You are looking for where the brief was underspecified and what the reviewer keeps catching, and you cannot see either from inside an automated version.

Days fifteen to twenty-one. Measure the allowance. Run one complete cycle and record what fraction of the weekly agent allowance it consumed. Multiply against the cadence you want. This is where most plans die, and it is far better to find that out in week three than in launch week.

Days twenty-two to thirty. Automate only what survived. Whatever the loop did reliably by hand, and only that. Everything else stays manual until it has earned its way in.

J

John Rush

@johnrush

I wanna share all my startup experience, one topic at a time, Today it's ---SEO--- In the past years, I generated over 1B impressions and 1M clicks from SEO. Everything I've done: Domain names Use: .com, .org, .dev, .ai, .io Use keyword-like naming, e.g. osssoftware dot or… Show more

What we would not do in month one: build a nine-bot stack, wire anything that can post to a live account, or standardise a client-facing process on top of a surface whose model routing you do not control.

Objections we think are fair

"You measured 49 posts. That is a small sample." It is. It is the top-of-distribution sample for three specific queries over a three-week window, and it is a census of the loudest posts rather than a random sample of all posts. We chose it because the question was what the visible claims look like, and the visible claims are by definition the ones with reach. A random sample would answer a different and less useful question. The 37 percent and the zero should be read as properties of this corpus, and the zero is stark enough that a larger sample would have to work very hard to move it.

"Your Grok chat probe failed, so you never used the thing." Correct, on the chat surface, that day. We are saying so rather than hiding it, and the failure is reported as a measurement with its control rather than as a verdict on the product. Everything we say the bots do well comes from the configuration probe or from specific dated public accounts, never from a demo we did not run.

"The Reddit threads are small." Two of them are. The r/SaaS thread has 3 upvotes and 23 comments, and the r/AI_Agents teardown has 57 upvotes and 80 comments. We are citing them for specificity rather than for consensus: a named person describing what happened on their own account, with dates and numbers, is better evidence about mechanics than a thousand upvotes on an opinion. Where a claim rests on one person, we have said so and tagged it published.

"You are an agency writing about the tool that competes with agencies." Yes. We said so above, before the section where it mattered, and we named the four things we think got genuinely cheaper. If we were writing this to protect a business we would not have led with drafting volume being repriced.

"The category will look different in three months." Almost certainly. The keyword volumes will move, the pricing will settle, the quota will change. What we expect to survive is the structural stuff: that a bot cannot own a claim, that a same-model reviewer verifies nothing, that content the bot reads is an instruction channel, and that the constraint is the allowance rather than the subscription.

What would change our mind

Stating this explicitly because a post with no falsifier is an advertisement.

We would revise the central argument if somebody published a Grok bot marketing case study with a stated baseline, a stated window, a stated sample and a method we could follow. Not a bigger number. A traceable one. Across three weeks and 49 of the highest-reach posts in this category, that document does not exist, and it is a genuinely low bar.

We would revise the quota section if an instrumented run on our own account contradicted the operator report we cited. That is a test we intend to run and have not.

We would revise the tethering argument if the off-platform integration story changed materially, because the tethering is currently the single biggest constraint on this being a general marketing tool rather than an X-native one.

We would revise the search section on the next measurement, and we expect to. Ten of ten marketing-intent phrases below the reporting floor is a statement about 3 September 2026 and nothing else. A category this loud does not stay unsearched for long, which is most of the argument for writing the substantial page now.

The brief, written out in full

Everything above says the brief is the artifact that matters. Here is one, complete, for a job we would actually hand over. Copy the shape rather than the content.

The job. Produce a first draft of a 900-word post answering the question a named buyer asked in public this week, for the company blog, aimed at readers who already know what the product category is.

The audience. Heads of growth at Series A to Series B B2B software companies between fifteen and eighty people, who have a content function of one or two people and no dedicated SEO. They already believe content matters and do not need convincing. They are sceptical of anything that sounds like it was produced at volume, because they receive a great deal of it. They will stop reading at the first sentence that could have been written about any company.

The evidence rule. Every factual claim must carry a source that the reader could open. If you cannot find a source, write the sentence as a question instead and flag it. Do not produce a statistic from general knowledge under any circumstances. Do not state what a percentage of companies do, or what most teams find, unless a cited source says it.

The forbidden list. No revenue figures. No growth percentages. No client names. No claims about what our product does that are not in the product documentation supplied. Do not use the words leverage, robust, seamless, unlock, elevate, comprehensive, or the phrase in today's fast-paced. No em dashes. Do not open a sentence with the word While. Do not write a concluding paragraph that restates the introduction.

The output format. One H1, four to six H2 sections phrased as questions, 900 words plus or minus 100, a two-sentence summary at the top, and a list of every factual claim with its source appended at the end as a separate block.

The escalation rule. If you are unsure whether a claim is supportable, leave it out and add a line to a section called Open questions at the end. Producing a shorter draft with three open questions is a success. Producing a complete draft containing one invented statistic is a failure, and a worse one than producing nothing.

That brief is about four hundred words and takes an afternoon to write properly. It is also reusable: the audience block, the evidence rule and the forbidden list barely change between jobs, so the marginal cost of the second brief is twenty minutes.

Notice what the escalation rule is doing. It defines success in a way that makes the honest failure preferable to the dishonest success. A bot with no such rule treats completeness as the goal, because completeness is what a draft looks like when it is finished, and the gap gets filled with something plausible. The single sentence about a shorter draft being a success is the cheapest safety mechanism in this entire document.

The claim ledger, worked

The ledger is one row per number. Here is the format, and then a real one.

Each row carries the figure exactly as it appears in the draft, where it came from, the sample it rests on, the window it covers, the provenance tag, and a link if one exists.

The provenance tags are the four we use in every table in this post. Measured means we ran it and hold the raw output. Derived means we computed it from something we measured, and the row says which operation. Published means a third party published it and we cite them. Unknown means we do not know where it came from, and the row says so.

That last tag is the one people want to delete, and deleting it is the mistake. A ledger where unknown is not an option is a ledger that trains its author to upgrade a guess into a claim, because every row has to have an answer and the honest answer is unavailable. Leaving unknown in place costs nothing and preserves the one signal that matters, which is that a number in your draft has no known source and should probably come out.

A worked example, using figures from this post:

The figure 1.58 is a median of per-post ratios, computed from bookmark and favourite counts on 49 posts pulled 3 September 2026, tagged derived, with the operation named as median of per-post bookmark divided by like. The figure 2,740,000 is a United States monthly search volume returned by our keyword vendor on the same date, tagged measured, with the positive control noted. The figure 21 calls in a first shift is a claim by a named person in a public thread dated 1 September 2026, tagged published, with the link. The eventual real-world cost of running a six-bot loop for a month is tagged unknown, because we have not run it.

That last row is the useful one. It is the row that stops the draft asserting a cost figure, and it is the row that tells a future writer exactly which measurement is missing.

The review checklist

The reviewer bot gets a fixed list of objective checks. Judgement calls do not belong on it, because a bot asked for judgement returns agreement.

Every number in the draft appears in the claim ledger. Every ledger row has a provenance tag. No row tagged unknown appears as an assertion in the prose. Every external claim has a link. No word from the forbidden list appears. No em dash appears. Section count is within the format spec. Word count is within the format spec. The summary at the top answers the question in the title. At least one internal link appears in the first third. No sentence asserts a result about our own product that is not in the supplied documentation.

Eleven checks, all mechanical, all with a yes or no answer. A bot runs them in seconds and runs them identically on the fortieth draft.

What is deliberately not on the list: is this good, is this interesting, does this sound like us, is the argument sound. Those are the reviewer's job in the human sense and a bot cannot do them. Asking it to will produce a confident yes every time, and having received a confident yes you will read the draft less carefully than you would have otherwise, which makes the review step actively negative.

Setting up monitoring without setting up an incident

Monitoring is the job with the best ratio of value to effort and the worst ratio of value to risk if you wire it wrong. The separation that keeps it safe is simple: the bot reads and reports, and a person acts.

What to watch. Named competitor accounts, your own brand mentions, three or four phrases that indicate buying intent in your category, and the specific pages on competitor sites that change when their strategy changes, which is usually pricing and the comparison pages.

What to report. A digest on a fixed cadence, containing links and quoted text, with no interpretation. A monitoring bot that summarises what it found into a narrative has made judgement calls you cannot audit, and the useful signal, which is often a single word changing on a pricing page, gets smoothed away.

What it must never have. Posting permission on any account. Reply permission anywhere. The ability to send an email. If the bot can only write to a document you read, the worst case of a compromised or confused bot is a document with rubbish in it.

This is where the injection problem becomes concrete rather than theoretical. A monitoring bot's entire input is text written by strangers, some of whom are your competitors and some of whom are actively adversarial. If that bot can post, then anybody who can get text in front of it has a channel to your brand account. The order-desk deployment we cited got this right by enforcing its limits in the database rather than in a prompt, and that principle transfers directly: the bot should not be able to post because the credential it holds cannot post, not because you told it not to.

The security posture, stated plainly

Four rules. Each one exists because of a documented failure above.

One. The bot's permissions are enforced by the system, not the prompt. An instruction not to do something is a request. A credential that cannot do something is a control. If your safety story is a line in a prompt, you do not have a safety story.

Two. Anything the bot reads is untrusted input. Replies, mentions, inbound email, competitor pages, community threads, review sites, transcripts. All of it is text a stranger wrote, and any of it can contain a sentence engineered to read as an instruction. The meeting-transcript incident happened with an internal document produced by colleagues. Your marketing inputs are considerably less friendly than that.

Three. A logged-in session is a broad grant. The bot walked its own operator through this: session access reaches caches, cookies and entered credentials. If an agent holds a session on a brand account, scope that account down first, and assume the grant is wider than the task.

Four. Log the actions, not just the conversation. The lesson from the API-key incident is that the prompt was clean and the output was clean and the damage happened in a tool call between them. If your instrumentation only captures what went in and what came out, it is watching the two places where nothing went wrong.

Reading a Grok bot case study

You will be sent one. Here is the reading order that saves time.

Find the sample first. Not the result, the sample. How many, over what period. If those two numbers are absent, you are reading an anecdote, which may still be interesting but is not evidence and cannot be planned against.

Find the baseline. Compared to what. $262 in a day is meaningless without the previous day. This is the single most common omission and it is usually not deliberate, because the person writing genuinely experienced the result as a change and did not think to record what it changed from.

Find the confounds. What else was different. Almost every impressive result in this category coincides with the author launching something, posting more, or getting a large post, and the bot stack is credited with all of it.

Check whether the author sells the thing. Not disqualifying. The most useful single document we found was written by a direct competitor who disclosed his interest in the first paragraph and then credited the product on four specific points. Disclosure plus specificity beats neutrality plus vagueness every time.

Check the ratio. If it is on X, look at bookmarks against likes. A high save ratio on a claims-heavy post means the audience is filing it rather than endorsing it, and that is the crowd telling you something the replies will not.

Run those five checks on the eighteen money-claim posts in our corpus and all eighteen fail at the first one. That is not a hostile reading. We would apply the same five to this post, and this post passes the first three because the sample, the window and the method are stated in every table, fails the fourth in the sense that we are an interested party and have said so, and on the fifth we genuinely do not know yet.

The six jobs, in operational detail

The list earlier says what each job is. This says how to run it, because the gap between those two is where most stacks fail.

Running live X research properly

The instinct is to ask a broad question and read the answer. That produces a paragraph that sounds like market understanding and contains none.

Ask narrow, retrieval-shaped questions instead. Which accounts posted about this specific problem in the last fourteen days. What exact phrases are people using for this category, as opposed to the phrase we use internally. Which complaints appear more than once. Each of those has a checkable answer made of posts.

The vocabulary question is the one that repays the effort fastest and the one almost nobody asks. Companies name their category internally and buyers name it differently, and the gap is usually invisible from the inside because everyone in the building uses the internal name daily. A retrieval pass across what buyers actually type is the cheapest positioning research available, and it takes an afternoon.

Then read the posts yourself. The bot found them, which is the expensive part. Deciding which of those people is your buyer takes ten minutes and cannot be delegated, because it depends on knowing which segment closes.

The failure to avoid: accepting a summary. If the output is a narrative about what the market thinks, you have no way of knowing which sentences came from real posts and which came from the model's general sense of how such narratives read. Insist on the list of links with the claim each one supports, and the problem disappears.

Running drafting properly

Two rules, and they are both about the brief rather than the model.

Give it the evidence. A bot drafting from general knowledge invents specifics, because a draft with specifics reads better than one without and it is optimising for the draft looking finished. A bot drafting from a supplied evidence pack cites the pack. The difference in output quality is larger than the difference between any two models.

Give it the forbidden list. Everything above about what not to produce. This is the constraint that converts a generation problem into a bounded one.

Generate more drafts than you need and throw most away. This inverts the instinct built from working with people, where asking for five versions of something is rude and expensive. It is neither here. Three drafts against one brief will differ in structure in ways that tell you something about the brief, and the cost of the two you discard is negligible.

The thing that does not work, and it is the most common approach: iterating conversationally toward a good draft. Twenty turns of asking for adjustments produces something acceptable and produces no reusable asset, because the knowledge you applied lives in a conversation that is gone tomorrow. The same twenty minutes spent improving the brief produces something that makes every future draft better. That is the whole difference between operating a bot and chatting with one.

Running review properly

The reviewer is a different bot, on a different model, with the checklist and nothing else. Not the drafting bot asked to check its own work, which is a machine for producing confidence.

Give it the checklist, the claim ledger and the draft, and require a structured output: each check, pass or fail, with the offending text quoted on a failure. Prose from a reviewer is a sign the checklist was not mechanical enough.

Set the expectation that a rejection is a normal outcome. A reviewer that never rejects is not verifying, it is decorating. If your rejection rate is near zero after a month, mutate a draft on purpose, introduce a number that is not in the ledger, and confirm the reviewer catches it. If it does not, the review step has been reporting success over a broken check for however long it has been running, and you would never have found out from the output.

That last point is not theoretical. It is the same failure as the two-reviewer story, one layer down: a check that cannot fail returns the same result as a check that passes, and the two are indistinguishable unless you deliberately break something.

Running the new-user test properly

Be specific about the persona and the constraint. Not review my signup flow, which returns a list of generic usability advice. Instead: you have never seen this product, you do not know what category it is in, you have been told by a colleague that it might help with a specific problem, complete a signup and report every point at which you were unsure what to do next.

Run it against the paths you have stopped seeing. Signup. Onboarding. The pricing page. The documentation index. The first task a new user is meant to complete.

Read the output as a list of symptoms rather than a list of instructions. It will report ten things. Two matter. Deciding which two requires knowing where users currently fall out, which is your data.

Re-run it after changes, which is the part that makes it a system rather than an exercise. A bot has no memory of last month's run and no investment in the fix being good, so it is a genuinely fresh reader every time, which is the one thing you cannot buy from a human tester twice.

Running monitoring properly

Covered in the safety section. The operational additions are cadence and diffing.

Weekly beats daily for competitor watching. Daily produces noise that trains you to skim, and skimming a monitoring digest is the same as not having one.

Diff rather than describe. The useful output is what changed since last time, not what exists now. A digest that says the competitor's pricing page mentions enterprise twice is useless. A digest that says it mentioned it zero times last week and twice now is a signal.

Keep the raw text. A summary of a change is not the change, and when you come back in three months to work out when something shifted, the archive is what answers it.

Running repurposing properly

The only job on the list that should have a gate before it rather than after it. Decide whether the asset is worth repurposing, then repurpose.

The gate is one question: did this asset do what it was meant to do. If a post got no traction, five derivative versions of it will get no traction in five more places and will cost you the audience's patience in each.

For the assets that pass, the bot is genuinely good at this and there is little to say. Give it the format constraints per surface, give it the forbidden list, review the output against the same checklist.

What this costs, thought through

The subscription is the visible number and the allowance is the real one. Work the second one out before committing to a cadence.

The arithmetic is not complicated and almost nobody does it. Take one complete cycle of your loop: research pass, three drafts, one review pass. Run it once and record what fraction of the weekly agent allowance it consumed. If a cycle costs a fifth, you have five cycles a week, and a plan built on daily output is already impossible. Better to know that in week one than in launch week.

The reported figures give a rough prior. One operator burned a weekly allowance in under two days with two to three agents running. If your loop is six bots, assume worse until measured. Several of the posts we audited describe eight or nine agents running simultaneously, and none of them mentions an allowance at all, which is either because they were not running them continuously or because the post stopped before that part.

The second cost is the one nobody prices: the review layer. A loop that produces forty drafts a week produces forty drafts a week that somebody has to look at. If the point of the stack was to save human time and you have moved the human from writing to reviewing without reducing the hours, you have changed the job rather than reduced it. Sometimes that is a good trade, because reviewing is less tiring than drafting. It is not a saving, and treating it as one is how a stack gets justified on numbers that were never true.

The third cost is maintenance. Briefs drift, checklists go stale, the model changes underneath you without notice because you do not control the routing. Budget time for the loop itself, not just for running it.

Definitions, because the vocabulary is a mess

The words in this category are used loosely enough to cause real confusion, so here is how we are using them.

Grok is the model family from xAI. Asking it a question in the X app is a chat surface that reads the platform in real time.

A Grok bot is a persistent agent with its own cloud computer that continues running after your session ends. Different product, different quota, different price.

A bot persona is a configured agent scoped to one job, which is how the product encourages you to organise a stack.

The claim ledger is our term, not a product feature. It is a table of every number in a draft with its source, sample, window and provenance tag.

The forbidden list is the section of a brief naming what the bot may never produce. It is the highest-value part of a brief and the most commonly missing.

Teach-a-task is the screen-recording mechanism described in public accounts, where you perform a workflow once and the agent repeats it.

Provenance tags, in this post, are measured, derived, published and unknown, applied per row to every table you have read here.

What we got wrong while writing this

Three things, stated because a methods section that reports no errors is not a methods section.

We computed a statistic over the wrong population. An early pass globbed in 45 cached searches from unrelated topics, producing a corpus of 823 posts and a bookmark ratio of 0.36 that we very nearly used. The tell was that the top results included posts from 2024 about a different subject entirely. The fix was scoping to the three queries we actually ran and printing a purity control beside the result, which is why every corpus figure in this post carries the phrase 49 of 49.

We read a field that did not exist and concluded the data was empty. Our first keyword extraction printed None for every term and we briefly believed the whole batch had failed. The values were present the entire time under a different field name. The control run is what exposed it, because a control that returns a number when your parser says there are no numbers proves the parser wrong rather than the data.

We nearly reported a surface as broken. Three chat failures in one session is a small sample and an outage-shaped result is exactly the kind of finding it is tempting to over-report. It is in this post as a measurement with its control attached and a stated scope, not as a verdict.

Every one of those three was caught by the same discipline: run a control that must produce a known result, and print it beside the finding. It costs one extra command and it is the only thing that reliably separates a real reading from an instrument bug.

The four stacks people actually describe

Only 4 of the 49 posts name a specific number of bots. That is worth noting on its own: the genre talks constantly about bot stacks and almost never says how many or which. The four that do are worth reading closely, because they are the closest thing to a published architecture this category has.

The counts named are five, eight and twenty-six. The eight-bot version appears twice, from different accounts, which makes it the closest thing to a consensus shape.

The functions repeat across all four with very little variation. There is a research or lead-scout bot that works out who the buyer is. A content or drafting bot. An ads bot connected to the ad platforms. An SEO bot. An analytics bot. An outreach or DM bot. Some versions add a chief-of-staff or orchestrator bot that assigns work to the others.

As a division of labour that is sound. It maps onto how a real marketing team divides, it gives each agent a narrow enough scope to be briefable, and the orchestrator pattern is a reasonable answer to coordination. Somebody thought about this.

What is absent from all four, without exception: any reviewer, any claim ledger, any human approval gate, and any mention of the allowance. The chief-of-staff bot assigns and reviews, which means the review is performed by the same model family that did the work, which is the two-chairs problem promoted to an architecture.

The ads bot is the one that should worry you most and it is presented most casually. Connect Google and Meta in one click and say do it for me, builds creatives, changes budgets. That is an agent with spend authority, driven by a model whose routing you do not control, reading performance data that includes text other people wrote. Every failure mode in this post applies to it and the consequences are financial rather than reputational.

We are not saying nobody should automate ad operations. We are saying that the version described in a viral post, with no approval gate and no spend ceiling enforced outside the prompt, is the exact shape the order-desk operator deliberately avoided when he put his bot's limits in the database.

The honest summary of the published architectures is that the boxes are right and the wiring between them is missing. If you are building from these posts, take the functional split and add the three things none of them has.

What the real-time read is actually worth

The single genuine advantage a Grok bot has over a general assistant for marketing work is that it reads X now rather than reading a snapshot of the past. That is worth being precise about, because it is easy to state and easy to waste.

A general assistant with web access can find posts. What it cannot easily do is answer a question about the current state of a conversation: not what has been written about this, but what is being said this week, by whom, in what words, and which of those posts are getting traction. That is a different query and it depends on live access to the platform's own index.

For marketing specifically, four things fall out of that.

Vocabulary drift. The words your buyers use change faster than your positioning does, and they change on X before they change anywhere you would notice. A quarterly retrieval pass on how people phrase your category is cheap and occasionally tells you that the phrase on your homepage is one nobody uses.

Objection discovery. People state objections in public that they will not state on a sales call, because on a call they are being polite. A retrieval pass on complaints in your category returns the version of the objection they say to peers, which is the one your content has to answer.

Timing. A story in a fast sector has a window of days. Knowing on Tuesday rather than the following Monday is the entire value, and it is the thing a training-data snapshot structurally cannot provide.

Who is actually talking. Not the biggest accounts, the ones your buyers reply to. That is visible in reply graphs and invisible in a follower count, and it is the input to any credible influencer or partnership decision.

Every one of those four is a retrieval task with a checkable output. None of them requires the bot to reason well about your business, which is fortunate, because it does not know anything about your business.

That last point is the constraint people trip over. The bot has no memory of your positioning, your customers, your pricing rationale or last quarter's failed campaign unless you put it in the brief. It is an extremely well-read stranger. Treat it as one and it is useful. Treat it as a colleague who has been here a while and it will confidently fill the gaps with things that sound like they could be true of a company like yours.

What happens when everyone has this

Worth thinking about, because a lot of the current advice implicitly assumes you are the only one running it.

Content volume goes up and content value per unit goes down. If drafting is nearly free, the volume of drafted material rises to fill every surface, and the average quality of what is published in your category falls. That is not a prediction, it is arithmetic, and the first-order effect is already visible in the corpus we measured.

The differentiator moves to what a bot cannot get. Your own data. Your own customers. A measurement somebody actually ran. This is the strategic argument for original research and it is why this post is a measurement rather than an explainer: an explainer about Grok bots is now a commodity that anybody can produce in an afternoon, and a probe of a live surface with a control beside it is not.

Distribution gets relatively more valuable. When production is cheap and attention is fixed, the scarce thing is the path to the audience. That is the part of the job that has not been automated and shows no sign of being.

Trust becomes the actual moat. In a category where 37 percent of the loudest posts quote a figure and none of them shows a method, being the source that states its sample is a durable position. The bookmark ratio we measured is a market telling you it wants that and is not getting it.

Detection improves alongside generation. Readers are getting quicker at recognising generated material, and the tells are moving. A stack that optimises purely for volume is optimising for the thing that is getting cheaper to spot.

There is a version of this where the whole category converges on the same brief shapes running the same models, and every company in a sector publishes materially identical content. The escape from that is not a better model. It is having something to say that came from somewhere the model cannot reach.

Evaluating the wrappers

You will be pitched tools built on top of this. Some are useful and some are a prompt in a subscription. Five questions separate them.

Whose model, and can you pin it? If the wrapper inherits the no-model-choice constraint, it inherits the reproducibility problem, and it should say so rather than implying stability it cannot provide.

Where does the quota come from? Yours or theirs. If theirs, what happens when it runs out, and does your workflow stop or degrade. If yours, the wrapper is a convenience layer over a constraint you still own.

What can it write to? The single most important question and the one most likely to be answered vaguely. Posting permission, email sending and ad spend are three different grants and a tool should be explicit about which it wants.

Does it keep the raw evidence? A tool that summarises and discards the sources has removed your ability to check anything it tells you. This applies especially to monitoring and research products.

What does it do when it does not know? Ask for a demonstration of the failure case, not the success case. A tool that has thought about this will have an answer. One that has not will show you a better demo.

The teardown we have cited throughout is a good model for how to read vendor claims generally: the author disclosed his conflict first, credited his competitor on four specific mechanisms, then named three constraints with reasons attached. Nothing in it required trusting him, because everything was specific enough to check.

What to do with the content you already own

A capable drafting machine changes the economics of existing content as much as new content, and this is the part of the opportunity most teams miss entirely because they are looking forward.

Most companies are sitting on two or three years of published material where a meaningful share is stale in a specific, fixable way: a figure that has moved, a screenshot of an interface that has changed, a competitor that no longer exists, a link that now redirects. None of that requires a rewrite. It requires somebody to find it, and finding it is exactly the tedious, high-volume, judgement-light work a bot is good at.

The audit pass is cheap to run. Point a bot at your published archive with a fixed list of checks: every external link resolves, every product claim matches current documentation, every dated statistic carries a date, every screenshot matches the current interface, every named competitor still trades. Output is a list with the offending line quoted, not a narrative about the state of your content.

What comes back is usually uncomfortable and usually actionable in an afternoon per page. Dead links are the most common finding and the least interesting. The one that matters is the product claim that quietly stopped being true when a feature shipped, because that page has been telling prospects something wrong for months and nobody knew.

The rewrite itself is where the claim ledger earns its place a second time. A refresh is the single easiest way to launder an unsourced number into a page that looks freshly verified, because the update carries an implicit warranty that somebody checked. If a figure in an old page has no traceable source, the refresh is the moment to either source it or cut it, and a bot doing the refresh without a ledger will preserve it perfectly and update the date beside it.

There is a sequencing point worth stating. Do the audit before you commission anything new. A team that adds forty new pages on top of an archive with broken claims has increased the surface area of the problem and spent the budget doing it. The audit costs an afternoon of bot time and tells you whether the money is better spent on new material or on fixing what you have, which is a question almost nobody asks because until recently answering it was more expensive than ignoring it.

The same logic applies to the assets that are not pages. Sales decks with figures nobody can source. Case studies quoting results from an engagement that ended two years ago. One-pagers describing a pricing model you changed. Each of those is a claim you are actively making to a buyer, and each is exactly the kind of thing a retrieval-and-check pass surfaces in bulk.

Here is the raw data

The argument of this post is that this genre publishes totals and withholds methods. It would be absurd to make that argument and then withhold ours, so here is the whole scoring record for the fifteen highest-reach posts in the corpus.

Read down the followers column and then the views column. There is no relationship between them worth the name. An account with 1,722 followers took 606,401 views. An account with 219,663 followers took 70,239, which is 3 percent of what the smaller account managed. The 142,024-follower account at the top did take the largest number, 5,444,763, but the 146,031-follower account four rows from the bottom took 142,884 from a comparable audience, a difference of 38 times between two accounts of almost identical size.

That is what a feed optimising for something other than audience size looks like from the outside, and it is why follower count is close to useless as a filter when you are deciding whose claims to take seriously.

The saves column is the one we keep returning to. Twelve of these fifteen sit above 1.0. The three that do not are instructive: rewind02 at 0.75, higgsfield_ai at 0.42, and nothing else below 1.5 until you leave the top fifteen entirely. The 0.42 belongs to the only vendor account in the list.

Anyone can check this. Every post id is recoverable from the account and the figures, every number came from one field on one record, and if a re-pull disagrees with us we would rather know.

Walking the corpus row by row

Take the fifteen rows in order, because the pattern only shows up when you read them against each other rather than as a ranking.

Rows 1 and 2 are the two megaposts, at 5,444,763 and 4,803,556 views. They come from accounts of 142,024 and 77,420 followers, so the larger account earned roughly 38 views per follower and the smaller one earned roughly 62. Already the ordering by followers and the ordering by reach disagree.

Rows 3 through 6 are where it stops making sense on audience terms at all. ridark_eth took 1,076,025 views from 13,930 followers, which is 77 views per follower. rewind02 took 742,813 from 4,675, which is 159. OriSilver took 675,807 from 6,469, which is 104. And vladdubchak_x took 606,401 from 1,722, which is 352, the widest gap in the entire set and the one we keep citing.

Compare that against row 15. higgsfield_ai has 219,663 followers, more than any other account in the table, and took 70,239 views, or 0.32 per follower. Between vladdubchak_x and higgsfield_ai there is a factor of roughly 1,100 in views-per-follower, and the account with 128 times more followers is the one that lost.

The saves column tells a second story on the same rows. adiix_official leads at 3.81 saves per like on 490,401 views, with 7,229 bookmarks against 1,898 likes. sairahul1 is next at 3.79, with 17,595 bookmarks, the largest raw bookmark count in the set, against 4,647 likes. Sabrina_Ramonov reaches 3.13 on much smaller numbers, 1,452 bookmarks against 464 likes, and bloggersarvesh 3.06 with 1,562 against 510. Four accounts of wildly different sizes converge on roughly the same ratio band between 3.0 and 3.9, which is not what noise looks like.

Then the two exceptions. rewind02 sits at 0.75 with 1,133 bookmarks against 1,501 likes, and higgsfield_ai at 0.42 with 347 against 834. The second of those is the only vendor account in the fifteen. We are not going to build a theory on a single row, but it is the row a theory would predict.

The middle of the table is unremarkable and that matters too. bl888m_eth at 2.98, 0xMiraqle at 1.67, shannholmberg at 1.52, igus_ai at 1.59, irabukht at 3.13, ScottyBeamIO at 1.78, ridark_eth at 2.06, OriSilver at 2.15, vladdubchak_x at 1.77. Twelve of the fifteen above 1.0, three below 1.8 excluding the two exceptions, and a corpus-wide median of 1.58 that the top fifteen does not distort.

The tail below the top fifteen holds the pattern rather than breaking it, which is the check that matters. johnrush, at 116,703 followers, took 57,295 views with 862 likes and 2,303 bookmarks, a ratio of 2.67. ericosiu took 33,784 views from 44,794 followers with 221 likes and 478 bookmarks, 2.16. cyrilXBT took 26,648 from 196,856 followers, and marcusyul 40,222 from 536,135, the largest account in the whole corpus and one of the weakest reach-to-audience results in it.

One account in the tail is worth singling out because it is one of the 2 posts in 49 where replies beat likes. Teslaconomics, at 506,167 followers, posted a giveaway of 50 codes and drew 562 replies against 433 likes and only 111 bookmarks, a save ratio of 0.26. That is the shape the cynical hypothesis predicted for the whole corpus, and it turns up exactly twice, both times on a giveaway rather than on a claim. The mechanism exists on this platform. It is simply not what is carrying this genre.

The other consistent tail account, RoundtableSpace at 260,668 followers, published repeatedly across the window and landed between 41,153 and 66,108 views each time with save ratios from 0.29 to 1.55, which is what an account posting steadily into the same topic looks like when nothing in particular catches.

The Reddit side, counted

The threads we read behave nothing like the posts, and the engagement shape says why.

The r/SaaS thread carries 3 upvotes and 23 comments, a ratio of roughly 7.7 comments per upvote. The r/AI_Agents teardown carries 57 upvotes and 80 comments, about 1.4. The three-weeks-of-testing write-up carries 3 and 10. The session-access thread carries 4 and 7. The injection incident carries 9 and 18, exactly 2.0.

Five threads, and four of the five draw more comments than upvotes. On X the same subject drew 0.09 replies per like across 49 posts, with only 2 of the 49 inverting. The two platforms are carrying the same topic and producing almost exactly opposite engagement shapes: X collects silent saves, Reddit collects argument.

That is not a criticism of either. It is a reason to read both, and a reason we would not have written this post from one of them.

The same genre on YouTube

X is not the only surface carrying this material, and the video version is older, longer and behaves differently.

The Eric Siu video is the closest thing to a specification anybody has published. Sixteen minutes and fifty-six seconds naming ten bots by function, from an operator who also appears in our X corpus. It went up on 1 September 2026 and had 12,507 views when we checked it two days later, which is a fraction of what a single X post in the same week did.

The Greg Isenberg video is the money-claim genre at forty-four minutes and twenty-one seconds, and at 129,234 views it is the most-watched Grok-bot-specific piece in the set. Length is doing something here that a post cannot: a forty-four minute video has room for a method, whether or not it uses it.

The two February videos are the useful contrast, because they were published five days apart and their view counts differ by a factor of nearly 6,870. The general prompting video took 206,088. The marketing-specific one took 30. That gap says the same thing our keyword measurement said: the audience for Grok content is enormous and the audience for Grok marketing content, as a distinct thing people go looking for, barely exists yet.

It is worth saying plainly that four videos is not a sample and we are not treating it as one. These four are simply the ones that appeared in our three SERP reads, which is a selection rule with an obvious bias toward whatever Google currently favours. What they establish is that the category exists on video and that nobody has published the study there either.

Where the timeline is right

It would be easy to read everything above as a debunking and that would be the wrong conclusion. Several things the loud posts say are correct, and separating them from the unsupported parts is the actual work.

The category is real. When xAI, OpenAI and Anthropic all converge on agents that own outcomes and have their own compute, that is not a marketing fashion. The competitor teardown we cited makes this point against his own interest, saying the feeling after the launch was validation rather than fear, and he is right. Something changed this year in what a non-technical operator can automate.

The org chart framing is a good instinct. Thinking in terms of roles rather than tasks is genuinely the right mental model for a bot stack, and the posts describing eight or nine named agents by function have understood something the single-assistant framing misses. What they leave out is governance, not structure.

Teach-a-task genuinely changes the economics if it works as described. The expensive part of automation has always been specification. A screen recording that collapses that cost changes who can automate, which is a bigger deal than any model improvement in the same period.

Speed genuinely matters. A first draft in seconds instead of an hour changes what you attempt, not just how fast you finish. Teams start testing five angles instead of committing to one, and that is a real behavioural change with real output consequences.

The cost floor for trying moved. Free access was enabled on our own account when we checked. A founder can find out whether this is useful to them this afternoon, which was not true a year ago and is genuinely the most important thing about the whole category.

Where the timeline goes wrong is not in any of that. It goes wrong at the last step, in the leap from these agents are genuinely capable to therefore they replace the function. The capability claims survive scrutiny. The outcome claims have no method attached, and it is specifically the outcome claims that are being used to sell.

The verdict

If you run marketing at a tech, SaaS, deep tech or web3 company, here is what we would actually tell you if you asked us in a room.

Try it this week, on your own signup flow, for the cost of an afternoon. That single test is worth more than everything else in this post because it replaces reading with knowing.

Build the loop before you build the stack. One bot with a real brief, a claim ledger and a different-model reviewer will outperform nine bots with none of those, and it will do it while producing material you can defend when somebody asks where a number came from.

Price the allowance before you commit to a cadence. The subscription is the advertised cost and it is not the constraint.

Do not give a bot posting permission on a live account. Not yet, possibly not ever, and certainly not before you have watched what it does with input a stranger wrote.

Keep the four things that did not get cheaper. Who the buyer is, what you are willing to claim in public, which problems actually cost money, and how the work gets distributed once it exists. Those are the parts of marketing that were always the job, and the arrival of a capable drafting machine has made them more of the job rather than less.

And treat the genre itself as data. Our whole corpus was bookmarked 1.58 times per like, which is a market saying it is not sure. The right response to a market that is not sure is not to be louder. It is to be the one who measured something.

One number to keep

If you remember a single figure from this post, make it the ratio rather than any of the dollar amounts.

The 49 loudest posts in this category were bookmarked 1.58 times for every like they received, and 34 of the 49 were saved more often than they were endorsed. That is a market reading claims it is not ready to stand behind and filing them for a day when somebody has done the work.

The dollar figures in those posts will be forgotten in a quarter, because unsourced numbers always are. The gap between what is being claimed and what has been shown will still be there, and it is the only durable opportunity in the category. Whoever publishes the instrumented run with a stated baseline and a stated window will own this subject, and on the evidence of three weeks and 49 posts, nobody has even attempted it.

That is a low bar and an open field, which is a combination you do not see often.

There is a second reason the ratio matters more than the totals. A dollar figure is a claim about one person's account in one month. A save ratio computed across 49 posts from 30 different accounts is a claim about the audience, and audiences move more slowly and more honestly than individual results do. If that ratio inverts over the next quarter, and posts in this category start being liked more than they are saved, that will mean the market has made up its mind. Watching it is close to free and it is a better leading indicator than any case study anybody publishes between now and then.

What we are doing next

This is a pillar and it is incomplete on purpose in three specific places, named so the gaps are auditable rather than invisible.

The instrumented run. Four weeks, one loop, the five metrics from the measurement section, with allowance consumption recorded per cycle. That is the study nobody in this category has published and it is the one that would settle the cost question. It is not written because we have not run it.

The brief library. The full brief above is one example. The useful artifact is a set covering the jobs a marketing team actually hands over, with the forbidden lists that go with each.

Bots against a general assistant. The tethering cuts both ways and we have argued both directions from public evidence rather than from a controlled comparison. That comparison is worth running properly.

Each of those appears in the cluster map above as not written, and each will link back here when it exists. A pillar that claims completeness it does not have is doing the same thing as a post claiming a revenue figure it cannot source.

Using bots inside an actual X growth practice

Most of this post treats the bot as a general marketing instrument. This section is narrower: what changes if the thing you are trying to grow is the X account itself, which is the case for a large share of the founders reading posts like the ones we measured.

The honest starting point is that the bot cannot do the part that works. X growth for a founder runs on replies inside conversations where somebody asked a question, and on posts that carry a specific point of view. Both are judgement-heavy and both are the thing the audience is evaluating. A bot writing your replies is a bot building somebody else's relationship with your buyer.

What the bot can do is everything around that, and there is more of it than people assume.

Finding the rooms. The hardest and least glamorous part of reply-driven growth is locating the threads worth being in. Most of what a manual search returns is not a buyer. A retrieval pass that returns threads where a named question was asked in the last day, filtered to accounts that look like your market, collapses an hour of scrolling into a list. You still choose which to enter and you still write the reply.

Watching the ones that matter. A small set of accounts your buyers actually read is worth monitoring continuously, and a bot does that without the attention cost of following them and drowning your own feed.

Drafting the long stuff. Threads and articles are structurally repetitive and benefit from a first draft. Replies are not and do not.

Auditing the profile. Point the new-user test at your own profile rather than your signup. A stranger has five seconds to work out what you sell and who you sell it to, and a bot told to read it as a stranger will tell you flatly whether the second half is answerable. Most profiles fail that test and the failure is invisible to the owner.

Keeping the record. What you posted, what happened, and what you concluded. Almost nobody keeps this, which is why almost nobody's X strategy compounds.

The line to hold is that the bot never speaks. Everything above is preparation, retrieval, monitoring and record-keeping, and all of it is real work that currently does not get done because it is tedious. Handing it over frees the founder to do the part that requires being a person, which is the part the channel actually rewards.

There is one more reason to hold that line and it is specific to this platform. The audience on X is unusually good at spotting generated replies, and the penalty is not indifference, it is a public reply pointing it out. The downside is asymmetric in a way that makes the trade obviously bad: a generated reply saves you ninety seconds and can cost you the account's credibility in a thread your buyers are reading.

Reproducing every reading in this post

We have asked you to trust several numbers. Here is how each was produced, in enough detail that somebody could repeat it and get a different answer if we are wrong.

The 49-post corpus. Three searches through our own X data infrastructure, each combining Grok with marketing intent terms, at engagement floors of 30, 50 and 100 favourites, restricted to English, excluding replies, and dated from 14 August 2026 onward. The three result sets were merged and de-duplicated by post id, giving 49 unique posts. Before any statistic, a purity control checked how many of the 49 mention Grok in visible text. The answer was 49. Every ratio was computed per post and then reduced to a median, never computed on summed totals, because summing first lets the largest post set the ratio for the whole set.

The claim audit. Regular-expression passes over the visible text of each post for a currency figure, for method words including sample, tracked, measured, methodology and spreadsheet, for any explicit day, week or month window, for an outbound link, and for giveaway framing. Every count was hand-checked against a sample of the matches, because a text match counts a word appearing anywhere including inside an unrelated sentence.

The Grok surface probe. One configuration read on our own authenticated account on 3 September 2026, returning eligibility, ineligibility reasons, free-access state, default mode, default model and the full model options array. Then three chat attempts, one in fast mode, one in fast mode with a shortened prompt, one with no mode specified. All three returned an upstream 502. The configuration read is the positive control: it establishes that the credential and the host were working, which is what makes three failures a reading about the chat surface rather than about our setup.

The keyword volumes. One batched request covering fourteen terms against United States volume through the single sanctioned keyword-metrics surface, on 3 September 2026. A positive control on the same path in the same session returned instagram marketing at 2,900 and email marketing agency at 3,600. Ten of the fourteen returned no data, and the control is what makes those ten a statement about the terms rather than about the account.

The SERP reads. Three queries, ten organic results each, pulled through firecrawl against the United States locale on 3 September 2026. No keyword vendor SERP surface was touched. Domains were counted distinctly and every page's composition was read by opening the results rather than inferring from domain names, which is how the two agencies named Grok were caught.

The Reddit evidence. Two threads read in full including their complete comment trees, plus four further threads read as posts. Every quotation is verbatim from a named account with the thread date attached. Where a claim rests on a single person, the row carrying it is tagged published rather than measured, and the text says so.

The pattern across all six is the same and it is the only methodological point worth carrying away. Each reading has a control that must produce a known answer, and the control is printed beside the result. Two of our three internal errors were caught by exactly that and neither would have been visible in the output otherwise.

A closing note on how to read anything in this category

The posts we measured are not fraudulent. Most of them are written by people who genuinely tried something, saw something work, and reported it with the honest enthusiasm of a person who has just found a tool that helps. The problem is structural rather than moral: the format rewards the total and not the method, and the ranking system rewards the promise and not the proof.

That is why the correction cannot come from reading more of them. Reading fifty confident posts produces fifty confident impressions and no plan. What produces a plan is a small number of readings you took yourself, with a control beside each one, and a willingness to write down the number that came back inconvenient.

We measured 49 posts and found 18 money claims with zero methods. We probed a surface and had three calls fail. We priced ten phrases and got nothing back on any of them. None of those was the result we expected when we started, and all three of them are more useful than the post we would have written from the timeline.

The bots are good. Use them for the six jobs. Keep the six things. Put a ledger between the draft and the reviewer, and put a person at the end.