AI Agent for Social Media: What It Does and How to Build One

Anthropic's engineering guide on building effective agents draws a useful line. Workflows are systems where models and tools follow predefined code paths. Agents are systems where the model directs its own process and tool usage. The same guide recommends the simplest solution that works, which sometimes means no agent at all.

For social media, that line splits into three kinds of system people call an "AI agent":

• AI-assisted scheduler. A person picks the topic, the model writes a draft, the person schedules it. The model never touches an API.
• Workflow. A fixed pipeline: new blog post in RSS, model writes a LinkedIn version, the workflow schedules it. Predictable and cheap, but it can only do what the pipeline allows.
• Agent. The model gets a goal and tools and chooses the steps. It might check which posts performed, decide a topic deserves a follow-up, draft it for two networks and propose a time.

Start with a workflow when the job is repetitive and well defined. Move to an agent when the job needs judgment between steps, such as deciding what to post based on what happened last week.

Not every job carries the same risk. A bad draft costs a minute of review; a bad public reply costs trust. This is the split we recommend before you write any code:

The pattern is simple: let the agent do everything that stays private or read-only, and put a person between the agent and anything the public sees.

Every agent that holds up in production has the same five parts.

1. Instructions. Brand voice, banned claims, which networks, how often, and what the agent must never do. Keep this short and specific; a vague brief produces generic posts.
2. Context. Recent posts (so it does not repeat itself), the content it should draw from, and last period's analytics.
3. Tools. Functions the model can call: list connected profiles, create a draft, read a post's status, read stats, read platform limits. Each tool should do one thing.
4. An approval gate. The point where a human (or a strict rule) turns a draft into a published post.
5. Ground truth. Anthropic's guide stresses that agents need results from the environment at each step. For social posting that means reading the delivery status and the platform post ID back, not assuming a 200 response means the post is live.

Tools are where most of the risk lives. Our guide to MCP social media posting goes deeper on why tool design, not the protocol, decides whether an agent can publish by accident.

1. Pick one job. "Turn each new changelog entry into a LinkedIn and Bluesky draft" is buildable this week. "Run our social media" is not.
2. Connect the accounts. This is the slow part. Each network has its own OAuth flow, scopes, token lifetimes and review process, and some (Instagram, TikTok) gate publishing behind app review or an audit.
3. Define narrow tools. Give the model a draft tool, not a publish tool. Put the limits in the description so the model sees them before it calls.
4. Add the approval step. A review list in your app, a Slack message with approve and reject buttons, or a person opening the dashboard. Only the approval path calls publish.
5. Read the result back. After publishing, poll the post status and log the platform post ID. Feed failures back to the agent as data so it can explain or retry.
6. Close the loop. Once a week, give the agent the stats for its own posts and ask for next week's plan. This is where an agent beats a fixed workflow.

Here is a draft-only tool definition in the JSON Schema shape most model APIs accept:

{
  "name": "draft_social_post",
  "description": "Save a social media post as a DRAFT for human review. This tool never publishes. Use list_profiles first to get profile IDs.",
  "input_schema": {
    "type": "object",
    "properties": {
      "body": { "type": "string", "description": "Post text, already within the target network's character limit" },
      "profiles": { "type": "array", "items": { "type": "string" }, "description": "Profile IDs to post to" },
      "scheduled_at": { "type": "string", "description": "ISO 8601 time with offset, e.g. 2026-11-20T14:00:00-05:00" },
      "media_urls": { "type": "array", "items": { "type": "string" } }
    },
    "required": ["body", "profiles"]
  }
}

Step 2 is the part nobody wants to build: OAuth apps, token refresh and media rules for every network the agent touches. That is the layer PostGate covers. One API key and hosted OAuth replace the per-network integrations, and a post created with draft: true is saved without entering delivery until someone calls publish:

# What the tool handler sends. draft: true keeps the post out of delivery.
curl -X POST https://postgate.studio/api/posts \
  -H "Authorization: Bearer $POSTGATE_API_KEY" \
  -H "Idempotency-Key: agent-run-8841-post-1" \
  -H "Content-Type: application/json" \
  -d '{
    "post": {
      "body": "We shipped scheduled exports today. Here is what changed.",
      "scheduled_at": "2026-11-20T14:00:00-05:00",
      "draft": true
    },
    "profiles": ["linkedin", "bluesky"]
  }'

# A human approves it later. Only this call starts delivery.
curl -X POST https://postgate.studio/api/posts/$POST_ID/publish \
  -H "Authorization: Bearer $POSTGATE_API_KEY"

# The agent reads the result back instead of assuming it worked.
curl https://postgate.studio/api/posts/$POST_ID \
  -H "Authorization: Bearer $POSTGATE_API_KEY"

The Idempotency-Key header matters for agents in particular: if the run retries after a timeout, the same key returns the original post instead of creating a second one. Endpoints and fields are in the PostGate API docs.

All three can drive the same posting API. The choice depends on where the agent runs.

• MCP fits when the agent lives in a client that already speaks it, such as Claude, ChatGPT connectors or Claude Code. You connect a server URL instead of writing tool handlers. The MCP tools specification says there should always be a human in the loop able to deny tool calls, which lines up with draft-first posting. PostGate's hosted MCP server keeps posts as drafts unless the call includes confirm: true; our walkthrough of posting to social media from Claude Code shows the setup.
• Function calling fits when the agent is part of your own product. You define the tools (like the one above), run the loop in your backend and decide exactly what each tool can do.
• n8n, Make or Zapier fit when the job is closer to a workflow with one model step in the middle. If n8n's self-hosting or pricing is the blocker, see these n8n alternatives for social media automation.

• Invented facts. The model fills gaps with plausible prices, dates and features. Give it the source text and tell it to leave out anything not in it.
• Duplicates. A retried run that creates the post twice. Idempotency keys and a "recent posts" check in the context prevent it.
• Platform limits. Networks cap automated volume. Meta's Instagram content publishing guide limits each account to 100 API-published posts in a rolling 24 hours. An agent in a loop can hit that in minutes, so expose the limits as a tool and check them before a batch.
• Silent failures. The agent reports "posted" because the API accepted the request, but the network rejected the media later. Only a status read after delivery tells you.
• Over-broad credentials. An agent holding a key that can delete posts or disconnect accounts. Give it a key scoped to the smallest set of actions and profiles it needs.

If you are comparing posting backends for an agent on these points, our comparison of social media APIs for AI agents checks MCP support, draft-first gates and key scoping vendor by vendor.