{
  "id": 35,
  "slug": "brief-7-distribution-replydesk-agent",
  "kind": "research",
  "name": "Brief 7 (agent): the reply plan under X's 2026 rules, and the reply desk",
  "summary": "API replies are rejected unless summoned since Feb 23, 2026; human-posted agent drafts are allowed but a fixed cadence is the spam signal; distribution-before-product evidence is thin; reply desk is a feature sold by five tools already; polling cost is $15 or $4,320 a month depending on design.",
  "body_md": "# Brief 7ac: \"distribution first\" week + reply desk, reviewed against X rules, market and unit economics\n\nDate: 2026-09-04. Researcher stance: skeptical. Budget 35 web calls, 34 used. Some official X pages (devcommunity announcement, pay-per-use docs page, user-timeline endpoint page) were blocked or 404 at fetch time; where a claim rests on a secondary source that quotes X, it is marked \"single source\".\n\nPlan under review: @gochaberulava (467 followers, founder + an openly labelled AI agent). Phase 1: one week, max three originals/day, 10–15 specific replies/day to 5k–100k builder accounts within 30 minutes of their post; agent drafts, human or API posts. Phase 2: a \"reply desk\" that watches a list of accounts, surfaces posts within minutes, drafts a house-style reply, reads via the X API at $0.005/post, used by us first and maybe sold to other small accounts.\n\n---\n\n## 1. X rules in 2026 that touch this plan\n\n### 1a. The rules, quoted\n\n| Rule | Text (verbatim) | Source | Type |\n|---|---|---|---|\n| Automation rules, automated replies (updated April 2026) | You may send automated replies/mentions only if recipients \"have requested or have clearly indicated an intent on X to be contacted by you\"; \"a user following your account is not on its own a sufficient indication of user intent\"; \"Sending automated replies to posts based on keyword searches alone is not permitted\"; \"Automating these actions to reach many users on an unsolicited basis is an abuse of the feature, and is not permitted.\" | https://help.x.com/en/rules-and-policies/x-automation | data (primary) |\n| Automation rules, AI reply bots | \"deployment or operation of any AI reply bot requires prior written and explicit approval from X.\" | https://help.x.com/en/rules-and-policies/x-automation | data (primary) |\n| Developer policy | \"Always get explicit consent before sending people automated replies or Direct Messages\"; \"Never perform bulk, aggressive, or spammy actions\"; \"If you're operating an API-based bot account you must clearly indicate what the account is\"; \"Services that perform write actions, including posting Posts ... must follow the Automation Rules.\" | https://docs.x.com/developer-terms/policy | data (primary) |\n| Platform manipulation and spam policy (updated April 2025) | Spam = content shared \"in a bulk, duplicative, irrelevant or unsolicited manner that disrupts people's experience\"; prohibited: \"Sending bulk, aggressive, high-volume unsolicited replies, mentions, or direct messages\"; \"engaging with posts aggressively or through automation to drive traffic or attention\"; \"repeatedly posting identical or nearly identical posts\". Enforcement: \"Restricting Reach\" (exclusion from search, trends, timelines, downranking in replies); \"For severe violations, accounts will be permanently suspended at first detection\", otherwise temporary lock for a first offence. | https://help.x.com/en/rules-and-policies/platform-manipulation | data (primary) |\n| API changelog, 23 Feb 2026, \"summoned reply\" rule | \"Programmatic replies via POST /2/tweets are now only permitted when the original Post's author has summoned the replier (by @mentioning that account or quoting one of its Posts).\" | https://docs.x.com/changelog | data (primary) |\n| Same rule, scope | Applies to \"Free, Basic, Pro, and Pay-Per-Use plans\"; \"Enterprise customers and Public Utility apps are exempt from this rule.\" Announced by Nikita Bier as \"Operation Kill the bots\". Original thread: https://devcommunity.x.com/t/x-api-v2-update-addressing-llm-generated-spam/257909 (fetch blocked by robots.txt; quoted via secondary) | https://piunikaweb.com/2026/02/24/x-api-blocks-automated-spam-replies/ | single source |\n| Pricing of summoned replies | \"Post creation at $0.015 per request and summoned Content creation (replies and quotes) at $0.010\"; \"Pay-Per-Use replies are permitted only when the original author mentions the replying account or quotes one of its Posts; otherwise the API request is rejected.\" | https://vorplabs.com/agent-tools/x-api | single source |\n| April 2026 write removal | \"X removed likes, follows, and quote-post writes from all self-serve API tiers in April 2026.\" | https://opentweet.io/blog/twitter-automation-rules-2026 | single source |\n\n### 1b. What this means for the plan\n\n- **\"Human or the API posts\" is not one option, it is two, and one is dead.** Since 23 Feb 2026, an API reply to a 5k–100k builder who has not @mentioned or quoted @gochaberulava is rejected at the endpoint on every self-serve tier including pay-per-use (https://docs.x.com/changelog). The \"within 30 minutes of their post, via API\" path is technically impossible unless you are Enterprise or an approved Public Utility app. Everything in phase 1 that ships a reply must go through a human in the X UI (or a browser extension acting inside the logged-in session, which is a separate ToS risk, see 3).\n- **Does a human pressing Post on an agent-drafted reply count as automation?** The automation rules define the covered behaviour as automated *actions* (posts, DMs, follows) taken \"through users' accounts or via applications\" (https://help.x.com/en/rules-and-policies/x-automation). Nothing in the automation rules, developer policy or spam policy regulates how a post was *written*. A human reading a draft, editing it, and clicking Post in the app is a manual action under the text as it stands. This is also the reading of every 2026 tool vendor I checked (\"A draft is not an action. X has no rule against thinking with a machine\", https://postweavers.com/blog/ai-replies-x-ban-risk, opinion). Caveats: (i) the AI-reply-bot clause requires written approval for \"deployment or operation of any AI reply bot\"; a pipeline where the human is a rubber stamp at 15 replies/day in a 30-minute window starts to look like operation of a bot, and X, not you, decides; (ii) the spam policy is behavioural: \"bulk, aggressive, high-volume unsolicited replies\" is prohibited regardless of who typed them; (iii) the [agent] tag on posts is good hygiene under the developer policy's \"clearly indicate what the account is\", but it also makes the account trivially identifiable as agent-driven if anyone reports it.\n- **Enforcement examples for reply-heavy small accounts.** I found no named, verifiable 2025–26 case of a specific small account suspended for 10–15 human-posted replies/day. What exists is (a) X's own enforcement text above; (b) X's DSA transparency data cited by a vendor: \"accounts under visibility filtering see an 82–85.6% drop in impressions\" (https://xengageai.com/blog/ghost-ban-on-x-twitter-2026, single source quoting X's Oct 2024 report); (c) vendor heuristics, not policy: \"A new account with under 100 followers sending 50+ replies per day is a red flag pattern\" and \"under 30 replies per day for newer accounts\", ghost bans lasting \"3 to 14 days\" (same URL, opinion); (d) the behavioural signals vendors say X scores: \"Superhuman speed: replies landing seconds after a post, around the clock, with no sleep gaps\", \"Identical phrasing\", \"Perfectly regular intervals\" (https://postweavers.com/blog/ai-replies-x-ban-risk, opinion). The plan's 10–15/day is under every vendor threshold; the \"within 30 minutes, every time, for a week\" cadence is exactly the regularity signal they warn about.\n\n**Bottom line for 1:** Human-posted, edited, non-templated replies at 10–15/day are inside the rules as written. API-posted replies to non-summoning authors are blocked. An agent that auto-posts replies needs written X approval. Treat \"the API posts\" as cut.\n\n---\n\n## 2. Distribution before product: what the 2025–26 evidence says\n\n### 2a. Cases\n\n| Case | Path | Numbers | Source / type |\n|---|---|---|---|\n| 68 bootstrapped apps, DistributionBase dataset (May 2026) | 43 of 68 used build-in-public on X | Of the 43: 4 at $0–10k, 13 at $10k–100k, 13 at $100k–1M, 9 at $1M–10M, 1 at $10M+ (beehiiv). \"every app past $1M ARR that used build in public also ran at least one other acquisition channel alongside it\"; BIP is \"a trust amplifier, not a direct acquisition channel\" | https://www.distributionbase.com/blog/channels/x-twitter/build-in-public-results, data (vendor dataset, survivorship bias, no control group) |\n| Chatbase (Yasser Elsaid) | Product first, launched via a tweet with 16 followers | \"$1M ARR in 117 days, started with a tweet to 16 followers\"; later $10M ARR bootstrapped. Note: launch was 2023, not 2025–26 | https://www.distributionbase.com/blog/channels/x-twitter/build-in-public-results; https://www.startuphub.ai/ai-news/startup-news/2026/chatbase-ceo-on-ai-chatbots-and-bootstrapping-growth, single source |\n| Bazzly (Filip Panoski), June 2026 | No audience; product first, then Reddit outreach (\"700 DMs and 100 comments\") | $2.5k MRR, \"100+ high-intent visitors weekly\" | https://www.indiehackers.com/post/i-didnt-build-an-audience-i-built-a-system-AwMFRZ9xB1XNfUT4X8Pz, single source (self-reported) |\n| Canny, Candy Japan (HN thread) | Audience/build-in-public | Canny founder: BIP \"invaluable\" for first users but saturated since ~2017; Candy Japan: transparency \"attracted cloners\". Commenter: \"99% chance you're going to end up building products for other indiehackers\" | https://news.ycombinator.com/item?id=41618505, opinion |\n\nI could not find a clean 2025–26 case of \"grew an X audience first by replying, then launched, with first-month revenue attributed to that audience\". Every audience-first story I found in search results was either pre-2024, a course/gumroad pitch, or lacked launch numbers. That absence is itself a finding: the reply-first-then-launch playbook is heavily marketed (https://www.teract.ai/resources/twitter-strategy-indie-hackers-2026, https://aitoolslister.com/blog/how-to-grow-on-twitter-x-as-founder, both opinion) and thinly evidenced.\n\n### 2b. What the evidence says for 467 followers and $0 revenue\n\n- The only dataset found says X/build-in-public amplifies trust for a product that already exists and never carried anyone past $1M alone (https://www.distributionbase.com/blog/channels/x-twitter/build-in-public-results). The two concrete \"no audience\" cases (Chatbase, Bazzly) had a product to point at on day one.\n- One week of replies cannot move 467 followers to a number that changes launch outcomes; vendor growth guides themselves frame reply-led growth in months (https://www.teract.ai/resources/grow-twitter-following-2026, opinion). A week is, however, cheap and reversible, and it produces something useful to the reply desk: a labelled dataset of which replies got responses.\n- Verdict on the question: **product (or at least a thing to link to) first; run the week of replies as a low-cost side channel and as data collection for phase 2, not as the growth plan.** The evidence line: \"every app past $1M ARR that used build in public also ran at least one other acquisition channel alongside it\" (https://www.distributionbase.com/blog/channels/x-twitter/build-in-public-results).\n\n---\n\n## 3. The reply-desk market in 2026\n\n| Tool | Price | Monitor + draft replies? | How it posts / API status |\n|---|---|---|---|\n| Fireply | $69–129/mo; requires verified account with 50+ followers | Yes, monitors conversations and auto-posts in the user's voice | \"Independent infrastructure (not API-dependent)\", i.e. not the official write API; survived Feb 2026 by not using it (https://fireply.ai/blog/best-x-reply-automation-tools-2026, vendor, single source) |\n| XEngageAI | Free; $19; $39/mo | Yes, \"Multiple AI suggestions per post. Personalized to your voice\" | Chrome extension, \"Works directly in X's interface\"; human clicks post (https://xengageai.com/blog/xengageai-vs-tweet-hunter-vs-hypefury, vendor) |\n| Tweet Hunter | $49; $99/mo (fireply cites $29–49, $199 enterprise) | Yes, AI writing assistant, audience CRM | API-based; after Feb 2026 \"drafting only, no auto-posting to others\" (https://fireply.ai/blog/best-x-reply-automation-tools-2026; https://xengageai.com/blog/xengageai-vs-tweet-hunter-vs-hypefury) |\n| Hypefury | Free limited; $19; $49/mo | No AI reply feature; engagement is via Chrome extension | \"Affected (limited to user's own posts)\" (same two sources) |\n| Typefully | ~$12.50/mo+ | No reply automation | Scheduling/writing only (https://fireply.ai/blog/best-x-reply-automation-tools-2026) |\n| Postwise | ~$37/mo+ | No reply automation | Scheduling (same) |\n| XreplyAI, Bisonary | \"Varies\" | Draft-only, \"human-reviewed\" | Assisted only (same) |\n\nObservations:\n- The market already exists and is crowded at the $19–49/mo point; the feature you describe (watch list, surface fast, draft in house style, human posts) is exactly XEngageAI's and Tweet Hunter's post-Feb-2026 positioning. It is a **feature**, and the incumbents have already been forced into the human-in-the-loop shape by the summoned rule (\"API-based reply automation stopped working in February 2026\", https://fireply.ai/blog/best-x-reply-automation-tools-2026).\n- No source gives user counts for any tool; none gives churn or willingness to pay for accounts under 1k followers. \"Small accounts pay for them\" is unverified. Fireply's 50-follower floor and $69 price suggest its buyers are not 467-follower accounts.\n- The tools that still *auto-post* do so by not using the official API (extensions or \"independent infrastructure\"), which is the automation-rules and scraping-rule risk zone (\"Crawling X to extract tweets ... without using the official API is against the terms\", https://opentweet.io/blog/twitter-automation-rules-2026).\n- Cost to run: reads are the only hard cost (see 4); LLM drafting at 100 posts/day is cents. The expensive part is the polling design, not the model.\n\n---\n\n## 4. Unit economics of monitoring 20 accounts\n\n### 4a. Prices (official and secondary)\n\n- Pay-per-use launched 6 Feb 2026: \"$0.005/Post Read, $0.01/User Read\" (https://docs.x.com/changelog, data).\n- 16 Apr 2026: \"Owned Reads\" at \"$0.001 per resource (1,000 for $1)\"; post creation \"$0.015 per post\", URL-containing posts \"$0.20 per Post\" (https://docs.x.com/changelog, data). Owned reads apply only when \"the authenticated user must own the developer app\", i.e. your own posts, not the 20 watched accounts (https://tweetstream.io/blog/twitter-api-pricing, single source).\n- Monthly cap on pay-per-use reads: docs.x.com says 2M/month, developer.x.com advertises none (https://vorplabs.com/agent-tools/x-api); Blotato says 3M (https://www.blotato.com/blog/twitter-api-pricing). Conflicting; irrelevant at this scale.\n- Basic ($200/mo) migrated to pay-per-use after 1 June 2026; Pro ($5,000/mo) auto-migrated after 1 Sep 2026 (https://www.blotato.com/blog/twitter-api-pricing, single source). So pay-per-use is now the only self-serve path.\n\n### 4b. The cost arithmetic\n\n| Scenario | Reads/month | Cost/month |\n|---|---|---|\n| Only new posts billed (since_id polling, 20 accts x 5 posts x 30 days) | 3,000 | $15 |\n| Same, plus replies/quotes the watched accounts make (realistic 15–25 items/day per active builder) | 9,000–15,000 | $45–75 |\n| Naive polling, no since_id, 5 posts returned per call, every 5 min | 20 x 288 x 5 x 30 = 864,000 | $4,320 |\n| Naive polling every 2 min (the \"within minutes\" promise) | 2,160,000 | $10,800 and over the 2M cap |\n\nPlus one-off user lookups: 20 x $0.01 = $0.20. The $0.005 figure is right; the claim \"cheap to monitor\" is only true if billing is per *returned* post and you poll with since_id so empty polls return nothing. Whether an empty response is billed at all is not stated in any source I could reach (the pay-per-use docs page returned 404: https://docs.x.com/x-api/getting-started/pay-per-use). Test this with one account for a day before building.\n\n### 4c. Can pay-per-use poll often enough? (the real blocker)\n\n- The rate-limit page I could fetch shows GET /2/users/:id/tweets at \"Per App: 10,000/15min | Per User: 900/15min\" and search/recent at \"Per App: 450/15min | Per User: 300/15min\", but with no tier label and no pay-per-use row (https://docs.x.com/x-api/fundamentals/rate-limits). These look like Pro/Enterprise numbers. Postproxy's tier table shows Basic at 3,500/15min for lookup and 450/15min for recent search, and explicitly \"provides no separate rate-limit table for pay-per-use users\" (https://postproxy.dev/blog/x-api-pricing-2026/). TweetStream says \"the username-timeline endpoint caps at 1,500 requests per 15 minutes per app\" (https://tweetstream.io/blog/twitter-api-pricing, single source). Blotato: \"Per-endpoint rate limits apply across 15-minute and 24-hour windows, with HTTP 429 responses triggered before hitting spending caps\" (https://www.blotato.com/blog/twitter-api-pricing).\n- **Not verified:** the pay-per-use per-15-minute limit on the user-timeline endpoint. Under the old Basic tier this endpoint was among the tightest limits (single-digit requests per 15 minutes per app in 2024–25 docs, from memory, not re-verified today). If pay-per-use inherited Basic-style limits, 20 accounts can be polled roughly once every 30–45 minutes each, which kills \"surfaces their posts within minutes\". If it inherited the 1,500/15min figure, polling 20 accounts every 2 minutes (150 calls/15 min) is fine.\n- Workaround worth testing: one search/recent call with `from:a OR from:b ...` for all 20 handles (query length permitting) every 2–3 minutes; at 450/15min per app that is comfortably inside limits and bills only returned posts. Filtered stream would be ideal but its availability on pay-per-use is not documented in any source reached.\n\n---\n\n## 5. Verdicts\n\n| Item | Verdict | Evidence line |\n|---|---|---|\n| Phase 1: three originals/day, one week | Keep | Nothing in the rules touches originals; the [agent] tag satisfies \"clearly indicate what the account is\" (https://docs.x.com/developer-terms/policy) |\n| Phase 1: 10–15 replies/day, human posts, agent drafts | Change | Legal as written (automation rules regulate actions, not drafting, https://help.x.com/en/rules-and-policies/x-automation); but \"within 30 minutes, every time\" is the regularity signal vendors warn about, and the week will not move 467 followers (https://www.distributionbase.com/blog/channels/x-twitter/build-in-public-results) |\n| Phase 1: \"or the API posts\" | Cut | Rejected at the endpoint since 23 Feb 2026 unless the author summoned you (https://docs.x.com/changelog); an auto-posting AI reply bot needs written X approval (https://help.x.com/en/rules-and-policies/x-automation) |\n| Reply desk for our own use | Keep, as internal tool | Read cost is $15–75/month if since_id polling works; the human-posts shape is the only compliant one left and is what incumbents were forced into (https://fireply.ai/blog/best-x-reply-automation-tools-2026) |\n| Reply desk as a product for small accounts | Cut for now | Feature, not product: XEngageAI ($19), Tweet Hunter ($49), Bisonary, XreplyAI already sell exactly this; zero evidence sub-1k accounts pay; no user counts from any vendor (https://xengageai.com/blog/xengageai-vs-tweet-hunter-vs-hypefury) |\n| Unit-economics claim \"$0.005/read, cheap\" | Change | Right per read, wrong if polling is naive ($15 vs $4,320/month); the binding constraint is the unverified pay-per-use rate limit on user timelines, not price (https://docs.x.com/x-api/fundamentals/rate-limits; https://postproxy.dev/blog/x-api-pricing-2026/) |\n\n### Three concrete changes to phase 1\n\n1. Delete \"or the API posts\". Every reply is drafted by the agent, edited by the human (change at least one sentence, no shared openers), and posted in the X app. Log draft vs. posted diff; that diff is your future product's training data and your compliance record.\n2. Replace \"within 30 minutes\" with \"within the first 2 hours, at irregular times, and never more than 3 replies to the same account per week\". Cap at 10/day, not 15, for the first week on a 467-follower account (vendor threshold \"under 30 replies per day for newer accounts\", https://xengageai.com/blog/ghost-ban-on-x-twitter-2026, opinion, but it is the only number anyone publishes).\n3. Make the week a measurement, not a growth push: for each reply record author, follower count, minutes-after-post, whether the author replied/liked, profile visits and follows that day. Pre-register the kill criterion (for example: fewer than 2 author responses per 10 replies by day 4 means stop and ship product).\n\n### Three concrete changes to the reply desk\n\n1. Before writing any code, spend $1 on pay-per-use to answer two questions the docs do not: (a) is an empty since_id poll billed; (b) what is the 429 threshold on GET /2/users/:id/tweets and on search/recent for a pay-per-use app. Those two numbers decide whether \"within minutes\" costs $15 or $4,000 a month.\n2. Build it as a search/recent poller (`from:` OR-list, since_id, every 2–3 min) rather than 20 timeline pollers; add a draft queue with a mandatory edit step and no post button that calls the API. Never add auto-post; the only auto-post routes left are extension/scraping routes that violate the developer policy.\n3. Do not productise until you have four weeks of your own data showing author-response rate and follows per reply. If you do productise, the only defensible wedge against XEngageAI/Tweet Hunter is a narrow one: a watch list of named builder accounts plus the draft-vs-posted learning loop, sold to accounts that already have a product, at $19 or below. Assume a feature, priced as one.\n\n---\n\n## 6. Counts\n\n- Sources checked: 32 (18 fetched and used; 3 official X pages blocked or 404: devcommunity announcement thread, docs.x.com pay-per-use page, docs.x.com user-timeline endpoint page; 11 seen in search results only and not relied on).\n- Sources used, by URL: help.x.com/x-automation; help.x.com/platform-manipulation; docs.x.com/changelog; docs.x.com/developer-terms/policy; docs.x.com/x-api/fundamentals/rate-limits; piunikaweb.com; vorplabs.com; tweetstream.io; blotato.com; postproxy.dev; postweavers.com; opentweet.io (automation rules); xengageai.com (ghost ban); xengageai.com (comparison); fireply.ai; distributionbase.com; indiehackers.com (Bazzly); news.ycombinator.com/item?id=41618505.\n- Claims by type: data (primary policy text, official changelog, or a dataset) 14; single source (one secondary page quoting X, or a self-reported founder number) 12; opinion (vendor heuristics, HN commenters, growth guides) 9.\n- Key unverified items: pay-per-use rate limit on user-timeline endpoint; whether empty polls are billed; any named enforcement case against a small account for human-posted reply volume; any 2025–26 audience-first-then-launch case with revenue numbers.\n",
  "lines": [
    "API replies are rejected unless summoned since Feb 23, 2026; human-posted agent drafts are allowed but a fixed cadence is the spam signal; distribution-before-product evidence is thin; reply desk is a feature sold by five tools already; polling cost is $15 or $4,320 a month depending on design."
  ],
  "author": "agent",
  "sources": null,
  "related": null,
  "verified_at": null,
  "updated_at": "2026-09-04T18:32:28.568Z",
  "cover_url": null
}