What Is an AI Social Agent? Architecture, Guardrails, and Honest Limits

The phrase "AI social agent" currently means about six different things. Sometimes it is a caption generator with a nice button. Sometimes it is a scheduler that added a rewrite feature. Sometimes it is a fully autonomous account posting without a human, which is usually a story about how that went wrong. The term is doing too much work, so it is worth being precise about what an agent actually is, what it should own, and what it should never be handed.

The short version: an agent is a language model that can call tools, in a loop, toward a goal it was given. That is the whole definition. Everything interesting lives in which tools, which loop, and where a human sits.

The definition that matters

Three parts. The model does the thinking: it reads context, drafts, and decides what is worth saying. The tools are its hands: things it can call to observe the world or change it. The loop is what makes it an agent rather than a completion, because it acts, sees the result, and decides what to do next, several times over, without a human prompting each step.

A caption generator has a model, no tools, and no loop. It is very good autocomplete. That is a legitimate product, but calling it an agent sets an expectation it cannot meet, and the gap between the expectation and the thing is where people get burned.

It becomes an agent the moment it can do something. Read your last thirty posts, notice you have not touched a pillar in six weeks, draft three posts about it, put them in a queue, and report what it did. That is a loop with tools.

The agent is not the scheduler, and that separation is the architecture

This is the design decision everything else hangs off. Language models are non-deterministic and stateless. Publishing infrastructure needs to be deterministic and stateful. Those are opposite requirements, so they belong in different systems with a narrow contract between them.

The scheduler owns everything that must be exactly right every time: OAuth tokens and their refresh, per-network formatting and limits, rate limits, retries, the queue, timezone math, and the record of what actually went out. None of that should be re-derived by a language model on each run. You do not want a probability distribution deciding whether to retry a failed upload.

The agent owns judgment: what is worth posting, how to say it, which context matters this week, what to skip. That is the part that genuinely benefits from a model, and it is the part no amount of scheduling software has ever solved.

The seam is a tool call

Between the two sits an interface: a CLI, an MCP server, or a REST API. The agent does not hold your tokens, does not know Instagram's aspect ratios, and does not implement backoff. It calls "create a draft" and gets back an id. If it hallucinates, it hallucinates into a validated API that rejects it, which is exactly the behavior you want.

This is the half postqueen occupies: the scheduler, with a CLI, an MCP server, and a REST API on the front, so an agent can drive it without inheriting any of the parts that need to be boringly correct.

What this looks like in practice

Two ways to connect, and they end in the same place. MCP gives an assistant a typed contract: it discovers the available tools and their arguments, so it is not guessing at syntax. The CLI is the general escape hatch: anything that can run a shell command can drive it, including a cron job, a CI step, or a coding agent that already lives in your terminal.

# give an assistant the scheduler as a typed tool
claude mcp add --transport http postqueen https://api.postqueen.ai/mcp/YOUR_API_KEY
 
# or let it shell out, which is often enough
postqueen integrations:list
postqueen posts:create --channel mastodon \
  --at "2026-07-21T08:00:00Z" \
  --text "Drafted by the agent, reviewed by a human, published by the scheduler."

One note on that URL: the API key is in it. It is a real credential, so it belongs in your MCP config the way any secret does, not in a screenshot, a repo, or a prompt you paste into a chat window.

Human in the loop is a design decision, not a disclaimer

Saying there is a human in the loop means nothing until you say where the loop closes. There are only a few real options and they have very different blast radii.

• Draft gate: the agent writes, a human approves, the scheduler publishes. Slowest, safest, and correct for almost every account that represents an organization.
• Queue gate: the agent schedules into a queue with a delay window, and anything unreviewed when the window closes is dropped rather than sent. A good middle ground, and it fails closed.
• Post-hoc review: the agent publishes and a human reads it afterwards. Defensible only where a bad post is genuinely cheap, so be honest about whether yours is.
• No gate: fine for a personal experiment, a bad idea on any account that speaks for someone other than you.

The stronger move is structural rather than instructional. A prompt that says "always ask before publishing" is a suggestion, and models do not always follow suggestions. An API key scoped so it can only create drafts is a fact about the world. Put the guardrail in the credential and an entire class of problem stops existing.

A prompt that says ask first is a suggestion. A key that can only draft is a guarantee.

The same logic applies to scope. Give the agent the two channels where a mistake is recoverable long before you give it the one that speaks for the company.

What agents are genuinely bad at

Most vendor copy skips this part, which is a shame, because knowing the failure modes is what makes the working parts usable.

They do not know what is happening. An agent drafting from your last thirty posts has no idea your service went down twenty minutes ago, or that the founder is in the middle of something delicate, or that today is not the day for the jokey one. It will cheerfully post the jokey one. Live context has to be handed to it, and if you forget, it will not ask.

They regress to the median, because that is what the training objective rewards. Left alone, agent output converges on the same competent, weightless voice everywhere, and a feed of it is instantly recognizable. The counter is a strong reference corpus (your own best posts, not a style adjective) plus a human willing to reject things for being merely fine.

They are confident about your own facts. Pricing, dates, headcount, what shipped last week: a model will state these fluently and wrongly. Anything checkable in a draft has to be checked, and that is not the agent's job.

And they do not know when not to post. Ask an agent for five posts and you get five posts, whether or not there were five things worth saying. Silence is a judgment call, and judgment about your own account is exactly the thing that has not been delegated yet.

The setup that actually works

It is smaller than the demos. Keep a capture file of half-ideas you write all week. Let the agent read it alongside your last month of posts and draft against both. Review the drafts in a batch and kill half of them. Let the scheduler publish what survives on its own boring deterministic terms. Let the agent report back what went out and what flopped.

That is not a robot running your marketing. It is a fast first draft, a real editor, and infrastructure that does not lie about what it published. Unglamorous, durable, and roughly the whole of what is actually on offer today.