2
9 Comments

I thought the hard part was connecting 30 platforms. It was knowing when not to publish.

I am building PostSider, a social publishing tool for teams and AI agents.

At first, I measured progress by the number of platforms I could connect.

One more provider working. One more OAuth flow approved. One more API request returning a successful response.

That felt like progress.

Then I realized that every new platform adds another way to publish the wrong thing at the wrong time.

The difficult question is not:

Can the agent send a publish request?

The difficult question is:

Should this post be published at all?

An AI agent is very good at producing a valid request.

It can write the caption, attach the media, select a channel, choose a time and call the API.None of those actions prove that the post should go live.The account might be wrong.The approval might be missing.The offer might have expired.The media might not be ready on the platform.The token might have expired.The post might already have been published by another workflow.The content might be technically valid and still be a terrible idea.That changed how I think about automation.

The default path should not be:

agent writes → platform publishes

It should be:

agent drafts → checks the post → human reviews → queue schedules → platform publishes

The agent can do most of the mechanical work.

It can prepare platform-specific variants. It can check whether required fields are missing. It can find the next available slot. It can put the post into the right workspace.

But there needs to be a point where the system can say:

Not yet.

That is not a failure of automation.
That is the part that makes automation usable.
I now think there are several good reasons not to publish:

  • The destination channel is ambiguous.

  • The post has not passed the required review.

  • The media is not confirmed as ready.

  • The offer, price or availability may have changed.

  • The agent cannot explain why this post is being published now.

  • The request looks like a duplicate.

  • The platform returned an unclear result.

  • The post is outside the campaign's approved timing.

A green API response is not the same thing as a good publishing decision.

This is especially important when one workflow touches many platforms. Each platform has slightly different rules, permissions, media behavior and failure modes.

The more platforms you connect, the less useful “it worked in testing” becomes.

A system that works on one network can still make a bad decision across thirty others.The product lesson for me is that the queue is not just a place where posts wait.

It is a control surface.

A draft should be visible before it becomes a scheduled post.A scheduled post should be easy to inspect.A failed post should remain visible instead of disappearing into a log.

A human should be able to stop or change something without fighting the automation that created it.I am not trying to make an agent autonomous as quickly as possible.

I am trying to make its actions understandable enough that autonomy becomes a choice instead of a risk.

Thirty platforms is an integration problem.Knowing when not to publish is a product problem.What would you require before allowing an AI agent to publish without approval?A sandbox? A rollback button? A confidence score? Or would you never give it that permission?

https://postsider.com

Łukasz Blania

posted toAvatar for product PostSider
PostSider
  1. 1
    This matches what I learned while building a WordPress publishing pipeline. The safest design was to separate Generated, Scheduled, and Published into durable states instead of treating a successful API call as the finish line. Each article also needs one reserved publication slot, idempotent checks, visible warnings, and a watchdog that can recover a missed cron event without publishing twice. I ended up offering three modes: draft-only, pending human review, and quality-gated automatic publishing. The important part is that switching to a safer mode removes future schedules without deleting the generated work or its history. For me, the minimum before unattended publishing is: explicit destination, validated content and media, a unique slot reservation, an expiry check for time-sensitive claims, and a recoverable audit trail. I’d treat a rollback button as useful, but prevention and idempotency matter more because some external side effects cannot truly be rolled back. How are you modelling the difference between a recoverable “not ready yet” state and a permanent blocker?
    1. 1
      Thanks! The "API call as the finish line" trap is exactly what I keep running into. I split it by who can unblock it. "Not ready yet" = something specific is missing (approval, media, a slot) — the post is fine, it just waits. It stays visible in the queue with the reason, someone resolves it, it picks up where it stopped. A permanent blocker = the post itself is no longer valid. Offer expired, account dead, content superseded. Retrying won't help, so it surfaces as an exception and a human decides: reschedule, edit or kill it. Main rule: the system should never quietly retry its way from blocked to published.
  2. 1
    The inspect-and-delete layer feels more important than the memory itself. Curious whether users actually engage with the Memory Book to correct or remove things, or whether simply knowing they can see and control the memory is what makes the companion feel trustworthy.
    1. 1
      Good point. I think you're right that the memory itself isn't the valuable part — it's that the user knows they can see it and remove it. For me the inspect layer is the whole point: drafts visible before they go live, failed posts don't disappear into logs, and you can always stop or change something without fighting the tool. Whether people actually use the edit/remove often — my guess is the *knowing it's there* matters more. Control you rarely use still builds trust.
      1. 1
        That makes sense. The more interesting test will be whether that sense of control actually reduces hesitation to let the system act, even when users rarely need to exercise it.
        1. 1
          Exactly — that's the real question I want to see answered in practice. If giving people a visible escape hatch actually makes them more willing to let the system act, that's the whole game. I'm dogfooding it myself — my agents schedule my own posts through this flow, so I'm both the builder and the most anxious user. Curious how many people will confirm the same pattern once they try it.
          1. 1
            That’s a much stronger test than just asking users whether they like the idea. I’d be curious whether the escape hatch actually changes behavior — specifically, whether people let the system act more often once they know they can inspect and undo it.
            1. 1

              Yeah, it would definitely be worth measuring. The tricky part is privacy — I don’t want to track too much of what users or their agents are actually doing.

              One thing I added specifically for this is an approval flow. An agent can send a post for approval instead of publishing it directly, and the user can review, edit, approve, or reject it.

              I think that’ll probably be the most common middle ground between manual and fully autonomous publishing. In real use, Vincent is already doing something similar — planning content for the whole month, then reviewing the plan, removing what doesn’t make sense and approving the rest.

              So I’m really curious whether people naturally move from approval-first to giving the agent more autonomy over time.

              1. 1
                That approval-first to autonomy transition is the part I’d be most interested in understanding further. It’s a much more consequential signal than whether users simply like the control layer. Happy to continue that privately — what’s the best email to reach you on?