How to Build a Social Media Agent That Actually Runs Your Calendar

Two weeks ago I planned fourteen posts without opening a composer. I typed a paragraph to Claude describing what I wanted, answered two follow-up questions about tone, and watched it draft the copy, pick the times, and queue everything through Planpost. I rewrote three of the drafts. The other eleven went out as written.

I build Planpost, so I am the least neutral person who could write this piece. Keep that in mind. But I also spent years scheduling posts by hand, and the shift I have watched over the last eighteen months is concrete enough that pretending it is not happening would be stranger than admitting my bias.

From chatbots to agents

The first wave of AI in social media was a writing assistant with amnesia. You pasted a product description into a chat window, got five caption options, picked one, then did everything else yourself. Open the scheduler. Upload the image. Set the time. Publish. Come back next week to read numbers the AI never saw.

That loop was faster than writing from scratch, but the AI was a passenger. It could not see your calendar and had no idea whether last month's thread flopped.

An agent is different in one specific way: it has hands. Give a model access to real tools and it stops suggesting things for you to do and starts doing them. It can look at your actual schedule, notice the gap on Thursday, draft something to fill it, and ask you before it commits. The conversation stops being "write me a caption" and becomes "handle next week."

The plumbing is boring, which is the point

The piece that made this possible is a protocol most people scheduling posts will never hear about. MCP, the Model Context Protocol, is an open standard that lets an AI model call tools in outside software. A tool might be "create a post", "list scheduled posts", or "get analytics for August". The model decides which tools to call and in what order, the same way you would click through an interface.

Planpost ships an MCP server, so I can say this part from direct experience rather than speculation. Once Claude is connected to it, the tools it can reach include creating and scheduling posts across the seven platforms Planpost supports, turning one piece of content into platform variants, rendering carousels and short videos, pulling analytics, and suggesting posting times based on when your audience actually responds.

None of that is science fiction. It is a list of API calls. That is exactly why it works. Agents do not need magic, they need well-labeled levers, and social media scheduling turns out to be full of them.

Building one, concretely

There is no framework to learn here, which surprises people. A social media agent is three pieces you already have or can get in an afternoon.

The third piece is the one that decides whether this works at all. A model with no tools gives you captions to copy and paste, which is where we were two years ago.

Step one, connect the tools

Every client stores this differently, and the config is short. The per-client snippets are in the agent docs, and I wrote a longer walkthrough of the fiddliest one in how to add an MCP server to Gemini CLI.

Step two, prove it can see your account

Before asking an agent to do anything, ask it something read-only. This is the equivalent of a smoke test and it takes ten seconds:

List my connected social accounts and show me what is already
scheduled for this week.

If it comes back with your actual accounts, the tools are wired. If it describes what it would do in general terms, it is not connected and everything after this will be fiction.

Step three, set the guardrail before the first write

Do this now rather than after the first surprise, and use both of the available mechanisms.

The first is an approval queue. In Planpost anything an agent schedules lands in one by default, so a prompt cannot publish straight to your audience. Check that your tool has an equivalent before you give it write access, because plenty do not.

The second lives in the client rather than the scheduler. Most MCP clients support includeTools or excludeTools, so you can hand over the read and draft tools while leaving publish_post out entirely. That is a sensible first week.

Step four, the prompt that does real work

Briefing an agent is closer to briefing a freelancer than writing a search query. The prompts that work carry constraints, not just a topic:

Plan next week for LinkedIn, X and Threads.

Three themes: the new revenue report, one honest post about
what it does not do, and one customer story.

Rules: no posting Friday afternoon. Nothing that reads as a
launch announcement, we did that last week. Keep X under two
sentences. Check what I posted in the last 30 days first so we
do not repeat a topic.

Draft everything, propose times, and stop before scheduling.

The last line is the important one. "Stop before scheduling" turns the agent into something you review rather than something you discover afterwards.

Behind that request, the tools doing the work are ordinary: list_posts to read the last month, repurpose_content for the platform variants, suggest_schedule or get_best_times for the timing, and create_post for each draft. You never name any of them. The model picks.

Step five, close the loop

This is the part that separates an agent from a fancy caption generator, and most setups never get here:

Pull the last 30 days. Which posts got the most link clicks,
and which ones actually produced revenue? Then tell me what to
do more of next month.

That reads get_analytics and get_revenue_overview. Whether your tool can answer the second half depends entirely on whether it connects posts to payments, and most schedulers do not, so the agent will confidently answer with engagement numbers and call them results. Worth knowing which question your stack can actually answer.

What a working session looks like

A real planning session runs roughly like this, allowing for the fact that mine usually has more arguing in the middle:

Step three is the one people skip in their imagination and should not skip in practice. More on that below.

What agents are genuinely good at

Volume, first. Turning one idea into a LinkedIn post, an X thread, and a shorter Threads version is exactly the kind of tedious variation work that used to eat an hour and now takes a minute. The variants are not identical posts trimmed to length. A decent agent restructures for each platform, because it has read more of each platform than you ever will.

Then there is consistency. An agent does not get bored in week three. My own posting used to collapse whenever product work got heavy, which was always. The weeks I let an agent keep the calendar full were the first weeks in months where the gap between intention and output was zero.

The last one surprised me: memory. Because the agent can list past posts and read their results, it can answer questions like "have we covered pricing changes this quarter?" or "which format got the most link clicks in July?" without me building a report. The weekly analytics review I used to do by hand on Fridays now takes one question.

Where they still fall over

Taste. The best post I published last quarter was a slightly unhinged observation about invoice emails that no model would have proposed, because it scored badly on every conventional signal until it did not. Agents write toward the middle of the distribution. The middle is fine for keeping a calendar alive. It rarely produces the post people remember.

Current events. An agent will cheerfully publish your scheduled product joke while your industry is having its worst news day of the year. It has no ambient awareness of the room it is walking into. A human glance at the feed before things go out is cheap insurance, and I have not found a substitute for it.

Platform nuance drifts faster than model training. What reads as native on Threads this month read differently six months ago. Agents lag that drift. You correct for it in review, which is another reason review stays in the loop.

And they need supervision in the plain, unglamorous sense. I read everything before it publishes. Not because the agent produces garbage, but because the cost of reading a draft is thirty seconds and the cost of a bad post wearing my name is not.

What this does to the job

The honest trend line: the production part of social media management is being absorbed, and the judgment part is not. Writing fourteen caption variants was never the valuable part of the job. Knowing which fourteen things are worth saying, and catching the one draft that will land wrong, still is.

If your value is typing speed and remembering to post, an agent is a threat. If your value is knowing the audience and having the sense to pause the queue on a bad news day, an agent is the intern you always wanted: tireless, and in need of a boss.

Agencies feel this first. A team that manages ten client calendars by hand is competing against a team that manages thirty with agents and spends the reclaimed hours on strategy. That gap compounds monthly.

If you want to try this

Start narrow. Let an agent draft while you keep scheduling manually, and see how many drafts survive your edit. When most of them do, let it schedule with your approval on each post. Full autonomy is a bad first step and, frankly, a questionable last one.

The setup on the Planpost side is documented at /docs, and the same pattern works with any tool that exposes an MCP server. The protocol is open. That matters more than any single product, mine included.

If you want the client-specific version rather than the general one, scheduling social media from Claude walks through that setup end to end.

The agents are not coming for your calendar. They are already in it. What is still up to you is whether yours has supervision.