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.
1. Agents get the same rules as people
An agent is just another author. Posts it creates go through the same checks as posts written in the app:
- Length is checked when the post is queued, not when it is sent. Bluesky 300, Mastodon 500, X 280. A post that does not fit is refused with HTTP 422, so the agent can shorten it while it still has the context.
- Approvals still apply. If the workspace requires sign-off, the agent can draft and schedule, but nothing goes out unapproved (409 if it tries to skip that).
- Plan limits still apply (402), so a runaway loop cannot post past what the workspace pays for.
The point: do not build a separate, looser path for automation. Put the agent behind the rules you already trust.
2. Retries must be safe: Idempotency-Key
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"}'
Two tips that apply to any API like this:
- Derive the key from what you are posting (campaign, slot, account), not from a random value generated per attempt. A random key per attempt defeats the purpose.
- Keep a small local state file of what you already sent. It makes re-runs boring, which is what you want.
3. "Published" should mean confirmed
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.
4. Scope the key, and expect it to expire
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.
Trying it with Claude Code
claude mcp add --transport http gptpost https://app.oraglegpt.org/mcp \
--header "Authorization: Bearer <YOUR_API_KEY>"
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?
Top comments (0)