salesascode
Get started
← All feature docs
Feature docs · /studio

Work

Saved research and drafts from your roles, with Content Studio tools for seats that include them.

Open Work → All docs

Open Work to see your saved outputs and the content draft queue. Draft review is visible before publishing configuration. Expand Publishing settings, goals and performance for channel controls and reporting, Schedule and engagement for calendars and replies, or Manage studio access for teammate permissions.

Page layout

Content drafts use separate content and decision panels. The content panel shows the Destination (the connected site or account and the target inside it), the saved revision, the state and the body. Preview exact revision shows the body of that saved revision, which is the one an approval covers. The decision panel shows Visibility (who will see it: public, inside the provider account, a provider draft only, or your workspace), the Approval scope (this saved revision to this one destination) and the Delivery evidence recorded so far. A draft waiting for review asks Publish this reviewed revision?; check I reviewed this revision and destination, then Approve publication. An approved draft offers Schedule. Inspect receipt opens the latest publication attempt and the stored receipt: state, external item, revision, destination and any error. When there is nothing to inspect yet, the button is off and its tooltip says why. Below both panels, Revision and outcome history lists the saved revisions, the approval, the latest publication attempt and any outcomes in one table.

The blog is only public for the operator of this site. Other workspaces show Saved in workspace when the pillar step completes. Inspect receipt opens the local record of that save, including its revision, time and workspace visibility. This is not an external publication receipt. Older copies without a receipt keep the button disabled and explain why. Connected destinations show their own publication evidence. The channel approval and safety gates still apply.

Warm leads from a paused mailbox

If too much mail from your Gmail bounced this week, Send as email on a warm lead is disabled, and hovering it gives the reason. Check the address, then choose I checked this address beside the button to send that one lead. Every other lead stays held until you resume the mailbox in Connections.

Your saved work

Accounts with content access start with the content review queue; saved research and other work remain in an expandable section below. Other accounts start with their saved outputs. Search across saved output, narrow to a role, and use Older outputs to continue through history. Open work takes you to its original record, including the sources and review actions available there. Expand Publishing settings, goals and performance for configuration. Channel approval, revision and publication rules still apply.

Overview

Content Studio at /studio is the view of the content engine that runs for you on a schedule, on our servers. The engine drafts; you decide. The drafting happens on a weekly cron; this page is where you review the draft queue, approve the risky posts, and connect your channels. There is nothing to install.

It clones the "seven AI agents run a YouTube channel" model and generalizes it to multi-channel, founder-GTM demand generation, the content markets your product and routes readers into signup.

Content Studio operators

How a week runs

  1. Monday 12:00 UTC, Scout. First it searches Hacker News for your topic keywords and your competitors' names (see What your market talked about). Then it reads your confirmed brief (positioning and ICP) and those threads, and saves up to eight scored trend angles and four search-keyword angles as ideas.
  2. Monday 12:30 UTC, the week's plan. The Strategist takes up to eight of your trend angles and turns them into at most five briefs, one channel, format, funnel stage and link each. With a conviction on your brief, every brief argues it and each uses a different kind of proof. The Writer then drafts each brief. The drafts land in the queue on /studio carrying Theme and Proof chips. None is scheduled: each waits for you to approve it. You get one plan a week; a workspace already planned in the last six days is skipped.
  3. Same run, campaigns. The ideas the plan did not use, including every search-keyword idea, become blog pillar campaigns, described below. Every pillar lands as needs approval and none is scheduled, even one that passes the fact-check. It publishes only when you approve and schedule it on /studio.

A brief without a conviction still gets a plan, just without themes or proof types. The plan counts against your weekly draft allowance, and a workspace over its allowance or spend cap waits for the next run with its ideas kept.

What your market talked about

Under Schedule and engagement on /studio, this list shows last week's public threads and comments that used your topic keywords or a competitor's name. Topic keywords are the phrases a buyer uses when the problem becomes a priority, such as "SOC 2 audit" or "GDPR fine". Type up to ten, separated by commas, and choose Save keywords. Each must be 2 to 60 characters. They are saved on your ICP. Competitor names come from the Competitors list on your business brief. With neither a saved ICP nor a confirmed brief, Save keywords is greyed out and hovering it says to confirm your brief first, because the keywords sit on the ICP the brief creates. If a save is refused anyway, the reason shows under the button.

Every Monday the Scout searches six terms at most, your keywords first, over the last seven days. Each item shows its title, the term it matched, its points and comments, how long ago it was posted, and links to the discussion and to the article it discusses. An item appears only when its own text contains the term, because the search matches loosely. The list ranks busy threads above quiet ones and new above old, with a thread's weight halving every three days. The same threads go to the Scout as signals, so they shape the week's ideas. The community-monitor and competitor-watch skills on your console read the list too.

Three sources feed the list, and each item names its own. Hacker News is public and free, so reading it costs you nothing and breaks no terms. Reddit is left out because its Data API terms require an agreement for commercial use. Company news comes from the GDELT Project, which allows commercial use of its data without a fee as long as it is credited, so the list links to GDELT whenever it shows a news item. Once a day we search it once for your recently lost accounts, your target accounts and your competitors, and keep only articles with a date whose headline names the company. X is the one paid source, and it runs only on your own key (see below). A LinkedIn engagement vendor comes later the same way. If Hacker News or GDELT does not answer, the list keeps the last results it had.

X reads on your own key. Open X reads on your own key above the list (marked preview), paste the bearer token from your own app in the X developer portal, choose the API plan you are on and list up to ten competitor handles. X bills reads to your X account, never to us, and nothing is read from X until you save a token. The token is encrypted, never shown again and checked with one lookup when you save it; Remove token stops all X reads. Once a day we search recent X posts for your topic keywords and for what your competitors posted, then look up who reposted their busiest posts. Each request to X also counts one credit against your credit budget, and a read stops the moment the budget is used up or cannot be read. A request limit from X stops the read until X says its window has reset, and the plan you choose keeps the number of requests under that plan's limits. Likes are not read, because X does not let an app token see them. The same token reads impressions and engagement for the posts you publish to X, once a day at one credit a post; without a saved token, X posts show the clicks and signups your own analytics recorded and no X impressions. Operators working in a client studio do not see this section.

Competitor engagers. Beside Warm leads, the list Competitor engagers on X shows people who reposted a competitor's post and whose public bio names a buyer title, an industry or a trigger from your ICP. It is plain word matching on the bio, with no AI call. Each person is added once to your people records with the origin competitor-engagement, so revenue by origin can credit it later. Someone whose bio matches nothing is left out.

What buyers searched to find you (preview). Below the list, a table of the Google searches that showed your own site in the last 28 days, with clicks, impressions and average position, and the pages they led to. It comes from your own Google Search Console, which you connect on the Search Console card in Connections. That is its own Google sign-in, read-only, separate from Gmail, Calendar and Drive. Once a day we read the property whose address matches the website on your business brief; if the Google account sees no such property, or more than one, the table says so and nothing is read. Disconnecting Search Console deletes the stored rows, and from that moment they stop reaching Studio, the Scout and your skills. Google keeps about two days back, so the 28 days end two days ago. The top searches also go to the Scout as signals for the week's ideas, and the community-monitor and competitor-watch skills can read them. Search Console never says which company searched, so these rows do not start revival cards. Until Google approves this app to read Search Console data, the section says it is waiting and nothing is read.

Lost accounts. The same news feeds the closed-lost revival lane. A dated article about a lost account, newer than the loss and inside the freshness window and past the cooling-off period, can start a revival card that names the headline. An article with no date never counts.

This week's questions

Once the week's plan is made, This week's questions appears at the top of /studio, above the draft queue. Each topic in the plan gets two short questions. The first asks for the proof the topic needs: a moment from your own work, a customer, a number, an opinion or a worked case. The second asks what most people get wrong about it. Five topics is ten questions, about 20 minutes in all, and every question is optional.

Type your answers and choose Save answers and redraft. The writer reads your answers before your business brief and rewrites the topic's draft around your own examples. The new version lands in the queue as a new revision, still waiting for your approval; nothing is scheduled or published. A skipped question adds nothing, and the writer is told to add no detail you did not give. Drafts you already approved or published are left alone, and your answers are kept on the topic either way. Saving the same answers again does not rewrite the draft, and a topic is rewritten from answers at most three times a week; after that, edit the draft in the queue.

When an answer is a story worth keeping, choose Keep as a story, write the lesson it proves and send it to your brief. It goes to your story bank as a change waiting for review and reaches your roles only when you confirm the brief.

Only you see these questions. A teammate operating your studio does not. Record a voice note is off for now: this workspace has no transcription service yet, and its tooltip says so. No audio is recorded or stored.

Each redraft is one writer call, counted in your AI usage and held to your spend cap like the Monday plan.

Every campaign is anchored on a blog pillar

When the engine researches a topic, it doesn't just fire off disconnected posts. It writes a 5-minute-read blog post, the pillar, and then derives the channel posts from it, so everything in a campaign says the same thing in each channel's native shape. The pillar stays in your workspace. Completing its blog step shows Saved in workspace and records a local receipt, with no public URL. Only the deployment operator publishes on the public blog. To reach your own audience, review a derivative for a connected publishing destination. Older workspace copies may have no receipt; the review card says so.

Campaigns come in two modes. Trend-led: Scout proposes angles from your positioning and what's moving in your market. SEO-led: a keyword pass proposes the search queries your ICP actually types, and those pillars are written to win the query, it's in the title and subheads, the meta targets it verbatim, and the first paragraph answers the search. SEO-led drafts carry an SEO: query chip in the queue; both modes flow through the same approval gate, so you pick which campaigns run by approving them.

Your real work feeds the queue too: each week the engine turns your most recent won deal into a drafted case study (pillar + LinkedIn version) and recent buyer conversations into a "what buyers actually ask" post. Both are built only from facts you actually have, no invented names, quotes, or numbers, and always arrive as needs approval: customer stories never publish without you.

Publish modes (why nothing gets you banned)

Each channel runs in one of three modes, chosen for how the platform treats automation:

Quality gates (fact-check + scoreboard)

Every pillar waits for your approval. Before it reaches the queue, a fact-check gate scans it for statistics, dollar figures, multipliers, and "studies show"-style citations; anything it can't verify against your own material is listed on the draft with the exact claim and a suggested fix (cite a real source, use your own data, or soften the wording), so you see it before you approve. A pillar that passes the check still waits for you. Nothing the engine writes publishes until you approve and schedule it. Every pillar also gets a quality score (brand-fit / clarity / hook, hard-grader 0 to 100) shown as a Q chip on the draft, so you can see quality trend as the engine learns your voice.

Content budget (quotas & governance)

The engine is metered so it can't run away with your AI spend or your posting volume. Each account has a content budget, a cap on how many pieces the engine generates per rolling day and week (defaults: 20/day, 80/week, admin-adjustable). When you're inside the budget, the This week's content budget strip under Publishing settings, goals and performance on /studio shows how much you've used and how much is left; when you hit the cap, the engine pauses new drafts and says so, it never silently stops. Generation resumes on its own as the rolling window clears. Ideas that were skipped for budget aren't thrown away; they're picked up the next window. Deployment admins set the default caps (and per-account overrides), a cap of zero means unlimited.

Underneath, a shared-app governance layer bounds the whole deployment's outbound traffic, the model calls the build cron makes and the publishes the dispatch cron fires, so one busy window across all accounts can't blow the token budget or trip a platform's rate limit. It's fail-safe: when a cap is reached the work defers to the next scheduled run rather than erroring. The knobs are environment variables (CONTENT_GOV_CAMPAIGNS_PER_MIN, CONTENT_GOV_PUBLISHES_PER_MIN, CONTENT_GOV_WINDOW_SEC) documented for operators in docs/ops-hardening.md.

Goal-based autopilot

Set a monthly goal under Publishing settings, goals and performance on /studio, signups, clicks, or revenue. The pace bar shows what attribution has actually measured against straight-line pace for the month (the marker is where you "should" be today), with what each remaining day must average to hit the target. When you fall behind, the engine responds with a known playbook, not a guess: goal-targeted, conversion-stage campaign ideas go to the front of the build queue (extra action-stage content for a signups goal, conviction-stage for revenue), capped so it never spams the queue. The math is deliberately simple enough to check by hand. Set goal with no target, or a target of zero, and the form says so under the button rather than doing nothing.

Per-draft performance

Every published draft card on /studio shows what that piece actually drove, clicks, signups, and attributed revenue, joined from the same attribution the public /watch board reads (each published CTA is UTM-tagged with the draft's id, and the pipeline follows content to click to signup to paid). Pieces that produced signups carry a "Drove N signups" badge next to their status, so the winners are visible at a glance while you review the queue.

Attribution is honest about sparsity: a freshly published piece reads "No attributed clicks yet" until UTM-tagged traffic actually lands, you'll never see zeros pretending to be data. Use the Sort, Performance option in the queue's filter row to rank drafts by signups first, then revenue, then clicks; drafts with nothing attributed (and unpublished drafts) stay in newest-first order below the performers. /watch remains the public proof board; this is the operator's working view of the same numbers.

Channel compare

Below the goal bar, the Channel performance, last 30 days card compares every channel that published a piece in the window: pieces published, clicks, signups, attributed revenue, and the conversion signal (signups over clicks, shown only when clicks landed). Channels are ranked the way the revenue-first optimizer ranks winners, revenue first, then signups, then clicks, so the channel that deserves the next campaign sits on top. It reads the same attribution as /watch and the per-draft cards; nothing new is tracked.

Attributed revenue keeps its currency. Each piece stores the invoices and refunds behind its number, in the currency they were paid in, and the label shows that code (a USD figure keeps the dollar sign). A piece or channel whose payers paid in more than one currency reads mixed currencies instead of a sum that would mean nothing. A conversion whose tag names a piece this workspace does not own is counted as unmatched and changes nothing, and a piece whose supporting payments have left the 180-day window goes back to zero on the next rollup rather than keeping a stale figure.

One rationale line under the table says why the engine is leaning where it's leaning. When the optimizer (the weekly metrics-rollup) has stored a note, you see its own reasoning, tagged Optimizer; until it has, the line is computed deterministically from the same 30-day metrics and tagged Signal, e.g. "prioritizing linkedin, 3.2x conversion vs reddit last 30d". Sparsity stays honest here too: a channel with pieces but no attributed traffic reads "published 3, no attributed traffic yet", and the card says so when nothing has published in the window at all.

Publishing to your own stack

Six more destinations connect from Settings, Connect. WordPress creates a provider draft and promotes it to live after approval. Webflow stages and publishes a CMS item. Notion creates a page in the selected database. Each uses the same revision-bound approval and durable publication receipt as the other channels.

HubSpot Marketing, Mailchimp, and Customer.io are lifecycle destinations, separate from the HubSpot CRM connection. Before approval, Studio shows the exact provider, audience, revision, body fingerprint, and requested run time. The Audience select shows the audience configured in Connections, and the approval carries it: if the audience changes in Connections while you review, approval is refused until you reload. Eligible counts the members the last sync read, minus the addresses your suppressions hold (an unsubscribe, a bounce, a do-not-contact record), for example 84 recipients · 6 suppressed. Where the members are not known here it says Not counted and why: Customer.io picks campaign recipients inside Customer.io, and a HubSpot Marketing list or Mailchimp audience shows counts only after its first member sync. Reporting says where outcomes come back (the daily content-attribution job for Mailchimp and HubSpot Marketing, the signed reporting webhook for Customer.io) and what has arrived so far. Choose Stage provider draft to prepare content without sending, or Approve exact send to authorize that one reviewed revision for that one audience. Mailchimp runs its provider send checklist immediately before its send request. Customer.io updates the selected broadcast email action and triggers the selected API broadcast. HubSpot Marketing updates the selected email and exact ILS segment, with graymail suppression enabled, before requesting the approved send.

Every attempt keeps the destination id, approver, approval time, dispatch state, and provider receipt on the draft. A provider accepting a send is not delivery proof, so Studio shows it as awaiting outcomes. Mailchimp reports and HubSpot email statistics move a send to outcome received only when the provider reports it. Customer.io uses signed reporting webhooks, counts replayed events, and keeps subscription decisions in a tenant-scoped ledger before projecting them onto contacts. WordPress, Webflow, and Notion report no native campaign performance, so their cards say "not reported by destination" rather than showing a false zero. These lifecycle integrations remain Preview until their credential-backed acceptance runs are recorded.

Channel token health & reconnect

Every connected channel on the strip under Publishing settings, goals and performance on /studio carries a token-health pill so an expired login never hides inside a stray publish error. The state is classified from what the engine already stores, the token's expiry (where the provider reports it), the last token-refresh error, and the most recent publish outcome on that channel, with no new polling: Healthy (fresh token or a successful publish in the last two weeks), Reconnect soon (the token expires within three days), Needs reconnect (expired), Publish failing (the last publish bounced on authentication), or Unverified, an honest state for providers that report no expiry and haven't published yet, so a green pill never overstates what we actually know.

That promise depends on the reads behind it. Every signal the pill is built from is an absence, no publish error, no expiry, no refresh error, so a query that fails produces exactly the shape of a healthy channel. Those reads used to fail quietly. They now report, so a health check that could not run is an incident somebody sees, rather than a green pill you find out about at your next failed publish. The strip still renders either way: one dead query does not blank the studio.

When a channel needs attention, a Reconnect action appears on its pill. For channels with a web login (LinkedIn, LinkedIn company, YouTube, Reddit, X, Threads) it opens the same connect flow Settings, Connect uses, in a popup, and the strip refreshes the moment it succeeds. For channels whose token arrives another way (Bluesky, Dev.to, Hashnode, the API-key providers), it copies a paste-ready instruction to add a fresh key in Settings, since there's no web handshake to open. Owned and assisted channels (blog, Substack, Hacker News) hold no credential and show Ready.

Failed-publish recovery: when a draft failed because of authentication, its card spells out the fix instead of a raw error, a Reconnect <channel> action next to a Retry publish button. Retry re-queues the piece through the normal dispatch (the compliance gate still runs before anything goes live), so once you've reconnected, one click puts it back in line. A failure that wasn't a login problem (a rate limit, a content issue) says so honestly, a reconnect wouldn't fix it, so none is offered.

Check existing item: a failed card shows the external item it saved, when there is one, and a Check existing item button. It asks the destination, read-only, whether that item exists and in what state: already public (do not retry, it would publish twice), an unpublished draft (Retry publish continues from it), gone (create a new revision), or not answerable right now. Retry publish works the same way after a publish whose outcome was unknown, and the card offers it even when the failure was not a login problem: the next run reads the saved item first, finishes that same item when it is still an unpublished draft, and stops without writing when it is gone. When the destination returned no item ID, there is nothing to read first and a retry could publish the piece twice, so Retry publish is disabled and says so. Look for the item in the destination, and if it is not there, save a new revision and approve it. A WordPress post in the trash, and a Notion page archived or moved to trash, count as gone. A Notion page that still exists is reported as needing review, because Notion can prove a page exists but not that it holds the approved revision; open the page and review it.

Changed in the destination since it was published: before WordPress, Webflow or Notion updates an item it already published, it reads the item's last-edited time and compares it with the time it recorded after its own last write. If they differ, someone edited the item there, so nothing is written and the card says Changed in WordPress since it was published. Nothing was overwritten. (with the destination's name). Open the item, compare it with the draft, and either leave it or choose Overwrite after review, which only an approver or the owner can do. The overwrite replaces the edit you reviewed and no later one: if the item changes again before the publish runs, it stops and the notice comes back. An item published before these times were recorded is held the same way the first time it is updated. Notion reports its edit time to the minute, so an edit made in the same minute as our own write is not caught.

Rate limits: when WordPress, Webflow or Notion answers too many requests, a read, an update of an item we already hold, a Webflow publish and a Notion block delete are tried again after the wait the destination asks for, up to three attempts and never more than ten seconds apart. Creating a new item, and adding blocks to a Notion page, are sent once: repeating them could make a second copy, so a rate-limited create is held as unknown and checked by id before anything else is sent.

Draft history & versioning

Every draft on /studio keeps an append-only history of every body it has ever had. The Revision and outcome history table on each draft card shows the latest five: the Action column says which revision is the Current draft and which are earlier ones (and which one you approved), and the Evidence column says who saved it and when: the engine (the pipeline drafted it), you (a manual edit), or an AI edit. Compare to current puts any older version side-by-side with the current body, so you can see exactly what changed before you approve. Restore saves an older body as a new revision; the one it replaces stays in the history, and the restored draft needs a fresh review before approval.

Unpublished drafts get an Edit button: change the body and Save as new version, the previous body stays in history, nothing is overwritten. Published (and failed) drafts are immutable: what actually went out is part of the record, so iterating on a published piece means repurposing it into a new draft. History keeps the last 20 versions per draft; older versions are pruned as new ones land, and the table says so, truncation is never silent.

If a manual save cannot be confirmed, the editor keeps your text and explains the uncertainty. Check the history table before retrying, since the server may have saved the version before the response was lost. Save and Cancel pause while a save request is pending.

Revise with instructions turns approve/reject into a conversation: type what should change ("tighten the hook, cut the last paragraph, make the CTA softer") into the box under the history table and the AI applies it server-side, saving the result as a new AI edit version, the body it revised stays one row below in history, one Compare to current click away. The endpoint runs behind your studio entitlement, is metered like the other studio AI surfaces (and respects the deployment's admin kill-switch for this surface), and says so honestly when the deployment has no model key, manual Edit always works.

Image cards

Every draft has a Card button under its content preview. It turns one line of the draft into an image for the post: a quote card, or a stat card built around a number. The line starts as the first short sentence of the draft, and you can pick another or rewrite it. Choose Light or Dark, check the preview, then download a 1200 x 1200 PNG for a square post or a 1200 x 675 PNG for a wide one.

A stat card only offers numbers that appear in the draft. If the draft has none, the Stat choice is off and says why, and the quote card is the one to use. The card never makes up a figure.

The card uses the accent colour and company name from Settings, Brand & Company, or the default emerald and black when none is set. Text always keeps its own dark or light ink. If your brand colour is too pale to read as the big number, the card deepens it toward the ink and says so under the preview. A quote holds up to 220 characters and the line under a number up to 160. Text that will not fit at the smallest size is refused with the reason, never cut off.

The card is drawn in your browser. Nothing is sent to a server or saved, so attach the PNG to the post yourself.

Calendar + campaigns

The Next two weeks grid on /studio shows what's queued to publish, day by day; any pending slot can be moved with its inline date picker (published/failed history stays put). Below it, Campaigns shows each campaign the way it's built: one blog pillar plus the channel posts derived from it, with each derivative's channel and status at a glance.

Every panel that loads from the server (the draft queue, replies, warm leads, the calendar, and channel compare) tells the truth when a load fails: instead of showing an empty state that reads like "nothing here yet", it shows an honest "unavailable right now, reload to retry" so a server hiccup never masquerades as an empty queue.

Team & agency mode

The Operators section on /studio lets you grant a teammate or agency access to run your studio. Approvers can do everything you can operationally, approve, schedule, reschedule. Drafters can create and edit, but every transition toward a publish is enforced server-side to an approver or you: a drafter clicking Approve gets a clear "approver required" message and the queue stays exactly as it was, the action never silently fails. Grant access with the email empty and the form says so under the button, the same line that reports a failed grant instead of a browser alert. Agencies work multi-brand: an operator granted access by several founders switches client workspaces from the picker at the top of /studio, the draft queue and calendar follow the selected client, and each client's own license covers their studio.

Team voices

A buyer listens to the person they trust, so each person on your team can post in their own voice. Open Team voices on /studio. Every member, you included, can add a few posts in their own words (leave a blank line between posts), the rules they write by, the topics they are credible on and the buyers who trust them. A member edits their own voice; you can edit anyone's. Only you set the name each person's posts go out under. Operators see a teammate's name and topics, not their email, samples or rules. Revoking someone's access deletes their voice in your studio.

Each week the plan gives every piece to the person buyers will believe on that topic, and the writer drafts it from that person's own samples and rules. The belief the week argues, the conviction from your business brief, stays the same for everyone. A member with no samples is never picked, and a studio with nobody else in it writes in your voice exactly as before.

Every draft shows its Author. You can move a held draft to someone else from that field; an approved or scheduled draft has to be held first, because its approval was for the old name. The body is not rewritten when you move it.

Nothing is approved or scheduled under a teammate's name without them. A draft in a member's voice can be approved only by that member or by you. An approver who is not the author sees Approve publication turned off, with the reason in its tooltip, until the author clicks Approve in my voice. A drafter can give that approval for their own drafts, but still cannot approve or schedule anything. Editing the draft afterwards cancels the author's approval, so they see the version that goes out.

The publisher checks again when a scheduled slot comes due. If neither the author nor you approved the exact revision about to go out, the draft goes back to needs approval and the slot is cancelled instead of posting. When you or the author schedule a teammate's draft straight from the queue, that counts as approving the current revision.

Hold cancels a draft's queued slot on every channel, so a held LinkedIn post or blog post never goes out on the old schedule. Approve and schedule it again to queue a new slot.

If a teammate deletes their account, their unpublished drafts in your studio are held rather than switched to your name. The card shows the author as a former teammate, any queued slot is cancelled, and only you can take the draft on: approve it to publish under your own name, or give it a new author. Their published posts stay as they are.

Engagement, replies to your comments

Once a post is live, the engine watches for comments on it and drafts replies in your voice (LinkedIn first). They land in the Engagement section of /studio for you to edit and Send, or Skip. Each draft is marked "auto-send ok" or "needs you"; high-risk channels (Reddit, Hacker News) always require a human and never auto-send. A reply you send posts back to the platform as a comment. Runs on the content-engage-poll cron; needs the channel connected and a model key (it no-ops cleanly without one).

Comment keyword giveaways

A LinkedIn post can give something away to people who comment a keyword. Open Comment keyword giveaway on the post's card in /studio, type the keyword (2 to 40 letters, numbers, spaces or hyphens), and pick a resource: one of the published worksheets, such as the buy-versus-build worksheet, or Write my own and paste the text people get. Save, and the card shows the post's opt-in link. The link answers once the post is published. Starting or stopping a giveaway takes an approver or the owner, because the page collects people's details for the workspace.

When a comment uses the keyword as a word of its own, in any case, the engine drafts a reply with the opt-in link. It lands in Engagement with every other reply and waits for you to send it; a keyword reply never posts by itself. It costs no model call, so it drafts even without a model key or with your content budget spent. A post with a keyword reads up to 50 recent comments per run instead of 5.

The opt-in page asks for a name and an email. The file opens in the browser straight away, and an email brings a link back to it. The person is recorded as a lead with the post as its source. The page needs the captcha to be configured, and it is rate limited per address and per network. Your giveaways send at most 300 opt-in emails a day between them; past that, people still get the file and are still recorded, and the email waits until they opt in again. A separate, unticked box asks whether they want your welcome emails.

Saving a giveaway also drafts five welcome emails into your connected lifecycle channel (Mailchimp, HubSpot Marketing or Customer.io, the first one connected with an audience): the resource on day 0, who you are on day 1, one idea on day 3, a proof story on day 5 and an invitation to reply on day 7. They are written from your dossier and nothing else. Where the dossier has a gap, the email carries a line marked ADD BEFORE APPROVING, and approval refuses it until you fill it in. The proof email only uses a story from your dossier that records its source; with none, you write the proof yourself. Each email ends with the channel's own unsubscribe tag and is approved on its own, like any lifecycle draft, but only to stage: a send would reach the whole audience the channel points at, and every one of those people would read that they asked for your resource. Approve each one to stage, then start the staged emails from an automation in your provider that runs on a giveaway sign-up, at the days above.

A person who ticks the welcome box gets a confirm link in that email, because anyone can type somebody else's address. Only the click adds them to the channel's audience. Mailchimp adds them as pending when the audience requires double opt-in, so Mailchimp sends its own confirmation first. HubSpot Marketing adds them to the segment. Customer.io cannot take new people through the token this connection holds, so the card shows how many asked and you add them in Customer.io. The delivery email carries a link to stop the welcome emails. Anyone who uses it is taken out of the audience where the provider allows it, and a later opt-in never adds them back. The card counts who opted in, who asked for the welcome emails, who confirmed and who unsubscribed. Stop giveaway turns the opt-in link off; records already made stay.

LinkedIn engagers on your topic and competitors

The LinkedIn engagers section of /studio, above Engagement, lists people who reacted to or commented on LinkedIn posts about your topic, or on posts by the competitor pages and people you watch (their company page, founders and sellers). People who fit your ICP by headline come first; a tenant with no buyer titles, seniorities or functions on its ICP gets no matches, and staff of your competitors or of your own company never match.

Two ways in. Connect Trigify with your own API key, create a Social Topic there with your topic keywords, paste its id (three at most) and up to five competitor company or profile URLs, then press Read now. Or import a CSV with a LinkedIn profile URL column under Import engagers from a CSV, which calls no one. Opening Studio never reads from Trigify.

Each ICP match becomes a person with a LinkedIn engagement origin (it appears in revenue by origin under attribution), and when their company matches one of your accounts it counts as one fresh signal on that account. A topic like and a competitor comment on the same account are one signal, so it takes a second kind of signal, a funding round or a site visit, to lift the account one tier. Reads count against your Enrichment Budget, each paid call is counted as it returns, and the pass stops when the budget is spent. Engagers are kept 90 days, and at most the newest 5,000 per workspace. Remove on a card deletes that person from the list and from the people recorded from it; Remove all for this topic (or competitor) does the same for everyone listed under it.

Warm leads from content, engagement becomes pipeline

Every like and comment on a published piece is captured and scored against your ICP dossier (industries, buyer titles, buying triggers). Engagers who clear the warm bar become prospects on /prospects-awareness automatically, tagged with the piece that drew them and the reason they fit, and each gets a short drafted note that references what they engaged with (and responds to their comment when they left one).

The Warm leads from content section of /studio lists them hot-first: the engager, their fit score and reason, the piece, their comment, and the editable draft. Copy draft for a platform DM, Send as email (you supply the address, social engagers rarely come with one), Snooze, or Dismiss. Draft-only by design: nothing is ever sent without your click. Runs on the hourly content-warm-leads cron; needs a model key (engagements simply wait, unscored, without one).

Hardening (2026-07-18): engager profile links are scheme-checked on ingest and at render, only http(s) URLs from external social sources ever become clickable links in the warm-leads panel.

Engine status (deployment owners)

Admins see an Engine status strip under Publishing settings, goals and performance on /studio, a live, per-capability readiness check (migrations, model key, PostHog, Resend, LinkedIn, cron, entitlement). Each capability is green when the thing it gates on is actually present, amber when a value still needs setting (with the exact action), and red when a probe fails. The same status is available as JSON at /api/studio/health (admin- or cron-authed).

To flip the whole "safe path" live in one command, run npm run content-studio:golive -- --email=you@co.com. It applies the database migrations, grants the content-engine entitlement to that user, validates every go-live environment variable, fires the content pipeline (Scout, Build, Dispatch, Attribution), and prints the readiness report. The handful of steps only a human can do, pasting third-party API keys, verifying the Resend sending domain, creating the LinkedIn app, are flagged MANUAL with the exact value to set.

When a load fails

A panel that cannot load says so. The Operators list in particular never falls back to "no operators yet" on a failed read: that would say nobody has access to your workspace when the truth is that we could not check.

How to use it

  1. Finish onboarding so the engine has your voice (your GTM Context Dossier).
  2. Connect the channels you want under Settings, Connect (LinkedIn connects with the self-serve "Share on LinkedIn" permission, no approval). On /studio, set each channel's publish mode; the strip shows which are connected.
  3. Let the weekly cadence build the queue. Review drafts, Approve the ones that need a human, Schedule what's ready.
  4. Watch what converts, the Orchestrator attributes signups back to the pieces that drove them, and /watch shows real platform numbers per connected channel (YouTube views and likes, Reddit ups and comments, LinkedIn likes and comments) merged with the PostHog click/signup attribution, plus revenue attributed per piece: signups are followed through to what they actually paid in your own connected Stripe account, never this platform's, and the optimizer ranks winning angles by revenue first, not reach. Connect Stripe under Settings, Connect to turn this on; without it a piece's revenue reads unmeasured, never zero.
  5. Every Monday a founder digest email recaps the week: what shipped, what converted (including revenue), warm leads your content produced, and the recommended next moves. Weeks with nothing to report send nothing.

Channels on the strip now include X (Twitter), Bluesky, Threads, Dev.to, and Hashnode alongside LinkedIn, YouTube, Reddit, Substack, and Hacker News, plus WordPress, Webflow, Notion, Mailchimp, and Customer.io on your own stack (see Publishing to your own stack, above). X needs a paid developer app; Threads needs Meta app review; Bluesky connects with a handle plus app password; Dev.to and Hashnode connect with an API key. Each activates the moment its credential lands, adding the next channel is still a single adapter file.

// deep walkthrough · 2 min