Letting an AI agent schedule social posts safely: length checks, approvals and Idempotency-Key
If you let an AI agent post to your social accounts, the scary part is not the writing. It is the retry. A model calls a tool, the network times out, the agent tries again, and now the same announcement is up twice. Or the agent writes 340 characters for a network that allows 300, and you find out
If you let an AI agent post to your social accounts, the scary part is not the writing. It is the retry. A model calls a tool, the network times out, the agent tries again, and now the same announcement is up twice. Or the agent writes 340 characters for a network that allows 300, and you find out at send time, at 9:00 on a Monday.
We build GPTpost, a social media scheduler for small teams, and we gave it a REST API and a remote MCP server so Claude, ChatGPT and plain scripts can draft and schedule posts. This post is about the guard rails we put in front of agents, because they are useful patterns even if you never use our product.
An agent is just another author. Posts it creates go through the same checks as posts written in the app:
The point: do not build a separate, looser path for automation. Put the agent behind the rules you already trust.
Every write accepts an Idempotency-Key header. Send the same key twice and you get the first result back instead of a second post.
curl -X POST https://app.oraglegpt.org/api/v1/agent/posts \ -H "Authorization: Bearer $GPTPOST_API_KEY " \ -H "Content-Type: application/json" \ -H "Idempotency-Key: launch-2026-11-02-mastodon" \ -d '{"text":"Hello from my agent","account_ids":["ACCOUNT_ID"],"schedule_at":"2026-11-02T09:00:00Z"}' Enter fullscreen mode Exit fullscreen mode Two tips that apply to any API like this:
A scheduler can be wrong in two directions: it can say a post went out when the network silently refused it, or it can resend something that actually landed. We mark a post published only after the network confirms it, and when the answer is unclear we hold it instead of retrying blindly. One duplicate on a brand account costs more trust than one late post.
Keys are per workspace, shown once, stored hashed, and carry scopes ( accounts:read, posts:read, posts:write, media:write ). A key never has more rights than the person who created it. Give an agent the smallest set it needs, and set an expiry.
claude mcp add --transport http gptpost https://app.oraglegpt.org/mcp \ --header "Authorization: Bearer <YOUR_API_KEY>" Enter fullscreen mode Exit fullscreen mode The MCP tools are whoami, list_accounts, create_post, schedule_post, publish_post, upload_media, get_post_status and list_posts. The OpenAPI file at https://app.oraglegpt.org/openapi.json works for ChatGPT custom actions and OpenAPI-aware agent frameworks.
Honest limits: GPTpost publishes today to Mastodon, Bluesky, Lemmy, DEV, WordPress, Telegram, Discord, Slack and a few more; Facebook, Instagram, LinkedIn and others open up as each network finishes reviewing the app. There is no social inbox and no listening.
Docs: https://app.oraglegpt.org/developers. There is a 14-day trial with no card at https://oraglegpt.org if you want to point an agent at a real workspace.
What guard rails do you put in front of agents that touch public accounts?