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?
Łukasz Blania
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.