How to Automate Your Weekly Build-in-Public Thread

A build-in-public thread is a short X thread in which a founder shares what happened in the product that week: what shipped, what broke, which number moved, and what the work taught them. It turns the week's real output into a public story, one idea per post, so an audience follows the company as it is built instead of hearing about it after the launch.

Done consistently, it is some of the cheapest distribution a small product gets. Readers who watched the struggle trust the launch, and the writing itself forces a weekly reckoning with what moved. The hard part is doing it every week, because the thread is the first thing dropped in a busy week, and a busy week usually holds the best story.

Why the weekly thread dies

Build-in-public content works through cadence, not through any single post. Each thread should read like the next chapter of one story, so the audience carries context from week to week: the promise made in March pays off in May. Skip three weeks and the chapters stop connecting, and the account slides back to disconnected updates nobody has a reason to follow.

The failure mode on the other side is worse. A founder who forces a thread out of a week with no real story ships filler, and filler trains readers to skim. A week's work either contains an angle with genuine tension (something counterintuitive, something honest, something the reader felt but could not name) or it belongs in the changelog. Telling those apart every single week, under deadline, is exactly the kind of recurring editorial work that stops happening when nobody owns it.

What the manual process looks like

Done by hand, the weekly thread is a ritual with six steps:

1. Collect everything that shipped or moved this week: features, numbers, bugs, reversals, customer moments.
2. Decide which of those, if any, deserves a thread rather than a changelog line.
3. Write the first post over and over until it can stand alone and still earn a tap on "show more".
4. Draft the rest of the thread, one idea per post, cutting every word that does not earn its place.
5. Reread the draft cold, fix the posts that sag, and publish.
6. Stay close for the first hour and reply to every comment, because that window matters most for reach.

Every step is teachable. Together they take a real block of focused time each week, and the quality depends on craft rules (hook mechanics, thread structure, story arc) that are easy to know and easy to forget at 9pm on a Friday.

What an agent can automate

Most of that ritual is method rather than judgment, which makes it a good fit for an agent running a fixed weekly workflow:

• Gather the week and extract the atoms. The agent collects the week's shipped work from your connected changelog or the notes you attach, then surfaces three to five self-contained content atoms: a quotable result, a complete story arc, a tactical tip, a contrarian take, or an honest behind-the-scenes moment.
• Pick the one angle worth a thread. Each candidate runs through a novelty filter: it survives only if it is counterintuitive, counter-narrative, surprising, or an articulation of something the reader felt but could not name. When nothing passes, the agent recommends skipping the week instead of shipping filler.
• Engineer the hook. The first post decides whether anyone reads the rest, so the agent builds it deliberately: open a gap, break a prediction, drop into a scene, promise a payoff, or lead with the real number, ideally two of those at once. It reveals roughly 80% (the result or subject) and withholds roughly 20% (the how), and it stays radically specific.
• Draft the thread one idea per post. Hook, then the mechanism in two or three concrete steps that show the change rather than claim it, then the lesson framed so the reader can apply it, then a genuine close with no hard sell. The story arc comes from brand-storytelling craft: find the five-second moment the thread turns on, start in the middle of the action, and keep the reader as the hero.
• Self-critique and revise. Before anything reaches you, the agent reads its own draft cold against a fixed bar: does post 1 force post 2, is there a real number or an honest admission, is every post one idea that scans on a phone, are hype words and AI tells stripped, is the close genuine. It revises until the draft passes.

What stays with you is the judgment an agent cannot make: whether the story is true to how the week felt, whether it posts at all, and the replies once it is live.

The guardrails that make it safe

A thread published in your name is a public action, and public actions should wait for a person. The workflow ends at an explicit approval step: the agent gathers, picks, drafts, critiques, and revises, and then the finished thread waits in your inbox, post-by-post and ready to paste, with a one-line note on the angle and the week it covers. Nothing posts until you approve it, and the agent never posts on its own.

The skip recommendation is a guardrail too. An agent under instruction to produce a thread every week will manufacture one. This one is instructed to say so when the week has no real story, which protects the asset the whole process exists to build: a feed readers trust.

Access works the same way. The agent works in X through its web interface in your browser and pauses before any post. Until you connect it, the agent drafts entirely from the changelog or notes you attach to each run and ships nothing on its own.

Set it up in Task Machine

The Build-in-public writing playbook provides a starting point for the method above. You need an active Task Machine workspace with Chat, workspace-management and Playbook-installation access (workspace owners have it). Access to X is not required up front. Until you connect it, the agent drafts threads from what you attach and posts nothing.

1. Find the playbook

Open Search in your workspace and enter "Build-in-public writing". The command center lists Set up Build-in-public writing under Playbook setup.

2. Start the conversation

Choose Set up Build-in-public writing. Task Machine opens a dedicated Chat with the Playbook card and an editable, unsent request. Read the intended job and outcome. Add your situation and send it when ready. Opening the draft does not install anything or start work. This walkthrough uses settings that require approval of the proposed Playbook.

3. Agree the working brief

Use Chat to agree the inputs, expected output and limits before asking for a proposal. Discuss the build-in-public context that shapes every thread the agent drafts. Product name sets what the threads are about. Milestone or lesson gives the agent the current arc the first drafts should build on. Audience names who the threads speak to. Tone guardrails hold the lines your founder voice never crosses, and you can add several.

4. Review the proposed Playbook

Ask the Agent to generate the Playbook from the agreed brief. Open its proposal in Chat and check the instructions and resources it will install, which carry more detail than the conversational summary. Read the agent card to confirm the voice notes landed, and check the workflow to see the approval step sitting after the revise step. Ask for a revised proposal if anything is missing or changes the job.

5. Approve and prepare the first work

Choose Approve on the proposal in Chat when the configuration matches your brief. Task Machine installs that reviewed configuration. The approved item retains its review details. If your autonomy settings allow direct installation, this approval may not be required. Check the resulting configuration in that case too.

Complete any remaining secure service setup from the installation details in Chat. Inbox keeps those setup items available if you return later. Prepare the source documents and inputs before starting the first Task or Workflow. Installation does not authorize sending, publishing or changing an external service beyond the boundaries you agreed. Confirm each schedule's cadence and timezone, and resolve any pending schedule setup before it starts. A readback must wait for its agreed observation window and source data.

What good looks like

The signals worth watching split by what they measure:

• Cadence held. The goal is one founder-voice thread approved every week, or the week explicitly skipped for lack of a real story. A skipped week is a pass. A filler week is a fail.
• Engagement that costs the reader something. Comments, shares, and saves are worth more than likes, because each one took effort. Review weekly which thread landed and why, and feed that pattern back into angle selection.
• Conversion signals. Profile visits, link clicks, and DMs show the threads are building an audience that acts on what it reads.

Common questions

What happens in a week where nothing worth posting shipped? The agent recommends skipping, and skipping is the right call. A build-in-public feed lives on trust, and one manufactured thread costs more than a quiet week does. The item that failed the novelty filter still makes a fine changelog entry.

Does the agent ever post to X on its own? No. The workflow ends at a human approval step, and the thread arrives in your inbox post-by-post, ready to paste. You approve it and you post it. Before X access is connected, the agent cannot post at all and works only from what you attach.

Will the threads sound like AI wrote them? The self-critique step exists for exactly this. The agent rereads its own draft for hype words, tidy tricolons, over-even sentence rhythm, and other tells, and revises before handing off. Your tone guardrails constrain every draft, and you still edit anything off-voice before approving.

Where should the link to my product go? In the final post or a reply, never in the body of the thread, because external links mid-thread suppress reach. The close itself stays soft: a genuine "building this in public, follow along" is the ceiling, and a hard sell fails the quality bar.

How long should each thread be? The structure sets the length: one hook post, two to four posts of mechanism showing what changed, one post for the lesson, and a genuine close. One idea per post, short lines, readable on a phone. If a post carries two ideas, it becomes two posts or loses one.