FounderReply

Approval queue

Human-in-the-loop approval, on every single draft.

Everything the agent wants to say in public — a reply, an original post, a comment under someone else’s thread, a DM — is written to an approval queue as a pending row. Nothing reaches a network until a human releases it. You can rewrite the draft first; approving sends exactly what you released.

Your own connected accounts · Free to start · No credit card required

5
Statuses a row can hold
1
Transition that reaches the public
3
Things you can do to a draft
0
Timers that release a pending item
Approval queue3 pending
Redditreplypending2m

We had the same problem at about thirty tickets a week. What fixed it was moving support into a shared inbox so the whole team could see a thread instead of forwarding it — and writing down who owns a reply after 24 hours. Happy to share how we set the rules up.

Drafted by the agent · 412 characters · edits are saved as a correction

ApproveEditReject
Xcomment_on_otherspending14m

The bit that moved our activation was cutting the second step entirely — most people…

Discoursedmpending1h

Thanks for the detailed writeup — one question about the migration path you mentioned…

Approving dispatches through your own signed-in session. Rejecting sets the row to rejected — the network is never called.

Illustrative view — no real accounts or drafts

The gate

A review step is a promise. This is a code path.

Most tools describe approval as a setting, which makes the only thing between a bad draft and your audience a checkbox nobody checks twice. Here there is no code that reaches a network except the code approval runs.

The queue is the send path

There is no express lane. A drafted reply, post, comment or DM becomes a row in the approval queue at status pending, and the only code that calls a connector is the code that runs when you approve.

HOW · approveAndSend() loads the item and returns early unless its status is exactly pending, so an already-sent, failed or rejected item can never be dispatched twice.

Editing is the training signal

You can rewrite a draft in the queue before releasing it. When the text you shipped differs from the text the model wrote, that difference is kept — it is the only labelled data about your voice that exists.

HOW · the draft→final delta is written to edit_events; the 8 most recent for that network are injected into the next draft’s system instruction as few-shot corrections.

You start inside the rules, then you decide

With no setting of your own, an action lands on the safer of our default and that network’s own automation policy — so a new workspace is compliant before it configures anything. Loosening one is your call, and you are told which rule it crosses first.

HOW · decide() returns your setting verbatim and reports beyondPlatformDefault, the gap against the network’s own position on the ordering off < approve < auto.

One row, end to end

From draft to sent, with you in the middle.

Five statuses, transitions that only run one way, and exactly one of them puts a message in front of a stranger.

  1. 1

    The draft is enqueued

    enqueue() writes a row carrying the network, the type, the target it would act on, the draft text, and the context that prompted it — the thread, the mention, the brief.

    The four types

    publishreplycomment_on_othersdm

    The type decides which connector method approval would eventually call.

  2. 2

    It waits

    The row sits at pending. Nothing releases it on a timer, and nothing expires it into a send. If you never open the queue, nothing is ever posted.

    The five statuses

    pendingapprovedrejectedsentfailed

    Only one transition out of pending puts a message in front of a stranger.

  3. 3

    You approve, edit or reject

    Approving with edited text sends exactly what you released, not the draft. Rejecting sets the status to rejected and stops there — the connector is never called for that item.

    Three outcomes

    approveapprove with editsreject

    An edit that is more than whitespace or case is also written to edit_events as a correction.

  4. 4

    It dispatches, and the result is recorded

    The connector call runs in your own signed-in session, the status becomes sent or failed, any provider error is stored on the row, and both the enqueue and the dispatch are written to the audit log.

    What is kept

    draft textfinal textstatusprovider error

    Enqueue and dispatch are both audit-logged with the item id, the type and the network.

The rules, plainly

What the queue guarantees, and what it never switches off for you.

All four actions ship gated on every network, and no plan, price or upgrade lifts one for you. Only a change of your own does — with the platform rule named before it saves, and your decision written to the audit log in your own terms.

The approval queue

Approving is the dispatch. Everything below follows from that one fact.

Always
Holds every draft at pending until a person acts on it.
Sends exactly the text you released, not the text the model wrote.
Keeps the draft, the final text, the status and any provider error on the row.
Writes both the enqueue and the dispatch to the audit log.
Tells you when a setting you chose goes past a network’s own policy.
Never
Releases a pending item on a timer, or expires one into a send.
Lets a DM go out un-gated unless you raised that dial yourself.
Un-gates commenting under someone else’s thread for you, on any plan or upgrade.
Re-sends an item that is already sent, failed or rejected.
Calls a connector for an item you rejected.

Why a rejected item can never come back

Approval requires a status of exactly pending. approveAndSend() loads the row and returns early on anything else, so “rejected” is not a label on a row that could still be dispatched — it is a state the dispatch path refuses to act on.

The policy line

Where the line sits, network by network.

Out of the box every action is gated and growth commenting is off, on all of them. This table is the separate thing: what each network’s own automation policy allows, and what your own settings get measured against.

What each network’s policy allowslib/autonomy.ts
What each network’s own automation policy allows, per connectable network and action type
NetworkPostReplyDMComment on others
Redditapproveapproveapproveoff
Instagramautoautoapproveapprove
Facebookautoautoapproveapprove
LinkedInautoapproveapproveoff
Xautoautoapproveapprove
Blueskyautoautoapproveapprove
YouTubeapproveapproveapproveapprove
Stack Exchangeapproveapproveapproveapprove
Lemmyautoautoapproveapprove
Discourseautoautoapproveapprove
  • An auto here is what the network allows, not what you get: with no setting of your own the action resolves to the safer of this row and our own default, which is approve for posting, replying and DMs and off for commenting under other people’s threads.
  • Set a dial past its row and it is applied exactly as you set it. You are shown the rule it crosses before it saves, and the decision is written to the audit log as yours.
  • A network or action with no entry falls back to approve, never to auto — a connector added tomorrow is human-gated by default rather than by memory.
  • The 10 networks you can connect today. The ones still shown as “soon” carry their own rows — the network pages say what each one can and cannot do yet. A row can also be moot: Bluesky has no direct messages we can send, so its dm position never comes up.

The resting state

If you never open the queue, nothing is ever posted.

There is no timer, no expiry and no “publish anyway” path around the row. A draft the agent wrote six weeks ago is still sitting at pending, and it will still be there tomorrow.

FAQ

Before you hand over the keyboard.

What the queue holds, what happens when you edit or reject, and what turning a dial to auto actually does.

It means a person releases every message before a network sees it. In FounderReply the agent’s output is not a post — it is a row in an approval queue with status pending. A human reads it, edits it if they want, and approves it. Approval is what calls the network.
Yes — it is per action and per network, and you turn it on. Out of the box nothing is unattended: posting, replying and DMs all start at approve, and commenting under other people’s posts starts off, on every network. Setting one looser is applied exactly as you set it, after you are shown the platform rule it crosses.
Two things. The edited text is what gets sent — the original draft is not. And because your version differs from the model’s, the pair is stored as an edit event. The eight most recent edits for that network are fed into the next draft, so corrections you make once stop coming back.
The row’s status becomes rejected and the flow ends there. No connector is called, nothing is sent, and the item cannot later be approved, because approval requires a status of exactly pending. The rejection itself is written to the audit log.
Only what you set to auto yourself, per action and per network. Nothing is auto out of the box — every action on every network starts gated, and growth commenting starts off. Anything sitting in the queue waits indefinitely: there is no timer that releases a pending item.
Yes. Enqueueing and dispatching are both written to the audit log with the item id, the type and the network, and the row itself keeps the original draft text, the final status, and any error the network returned on a failed send.

Fill a queue

Let it draft. You release.

Connect an account and let the agent fill a queue. Read the first three drafts, change what you would say differently, and approve the ones you like.

Free to start · No credit card required · Disconnect any time