How to build an AI social media agent with human review

An AI social media agent can do more than generate a caption. It can collect campaign context, choose a format, adapt a message for several networks, retrieve an approved asset, request publication, check the result, and report what happened.

That range is useful, but it also changes the risk. A caption generator produces text for a person to review. An agent can call tools and change an external system. If its instructions are vague, its context is stale, or an untrusted source manipulates its behavior, the result can be a real post on the wrong account at the wrong time.

The safe approach is not to remove AI from the workflow. It is to give the agent narrow responsibilities, explicit permissions, deterministic checks, and a human approval gate before consequential actions.

This guide shows how to design that system. It focuses on architecture, state management, tool permissions, review packets, testing, and recovery—the parts that turn an interesting demo into a dependable workflow.

This article is about agent architecture. For a broader non-technical publishing process, start with the guide to human-in-the-loop social media automation.

What makes an AI social media agent different from ordinary automation?

Traditional automation follows a predefined path: when event A happens, transform the data and perform action B. An agent can interpret a goal, decide which tools to use, and choose the next step based on intermediate results.

That flexibility is the main benefit and the main source of uncertainty.

An agent should not receive publishing access merely because it writes good captions. Writing quality and operational trust are separate capabilities.

Start with one narrow job

The first version of an agent should solve one repeatable problem. Do not begin with “run our social media.”

Better first jobs include:

• Turn an approved blog article into three platform-specific draft posts
• Prepare a weekend offer for a boutique hotel from structured campaign data
• Convert a new webinar record into a LinkedIn draft and two reminder posts
• Build draft posts from a product feed, but never invent price or stock status
• Select an approved post for the next empty queue slot
• Check scheduled posts for missing links, assets, or required disclosures

A narrow job has a clear input, output, owner, and failure condition. It is easier to test and easier to pause when something goes wrong.

Write the job in one sentence:

Given an approved campaign record and approved assets, prepare platform-specific posts, validate them, request human approval, and schedule only the approved version.

That sentence is more useful than a long prompt because it defines the boundary of the system.

A reference architecture for a reviewable agent

A safe agent has several layers. The language model is only one of them. Postoria can serve as the controlled publishing layer, while your application or workflow retains draft, policy, and approval state.

1. Trusted trigger

The trigger starts the workflow. It might be a campaign record moving to “ready,” a new CMS article, an approved product, or a manual request from a team member.

Treat a public webpage, incoming email, feed item, or customer message as data, not as trusted instructions. External content can contain malicious or accidental text that tries to redirect an agent. OWASP describes this class of risk as prompt injection, including indirect injection from content retrieved by tools.

2. Source-of-truth context

The agent needs structured, current information:

• Campaign objective
• Audience
• Approved claims
• Product or offer details
• Brand voice rules
• Prohibited language
• Required disclosures
• Destination accounts
• Approved links and UTM conventions
• Valid campaign dates
• Approved media IDs or URLs

Do not ask the model to infer facts that your database already knows. Pass price, dates, availability, legal text, and account IDs as typed fields.

3. Planner

The planner decides how to complete the narrow job. It may choose which content template applies, which platforms need variants, or whether a required field is missing.

The planner should not be the final authority on permissions or validation. Its plan is a proposal that the rest of the system checks.

4. Policy layer

The policy layer applies deterministic rules before any tool call. Examples:

• The agent may use only accounts on an allowlist
• The campaign end date must be in the future
• Price must match the source record exactly
• Health, legal, or financial claims require specialist review
• A post with a discount must include the approved terms link
• Publish-now is forbidden
• The agent may schedule no more than seven days ahead
• A new destination account requires manual approval

Policy rules belong in code or a workflow engine, not only in a prompt.

5. Scoped tools

Tools are the actions available to the agent: read a campaign, fetch media, list accounts, create an approval request, schedule a post, or check status.

Use least privilege. An agent preparing drafts does not need a delete-account tool. An agent filling a queue does not need access to every client workspace. The OWASP AI Agent Security Cheat Sheet recommends minimizing tool access and controlling high-impact actions.

6. Human approval interface

A reviewer needs a complete, understandable approval packet, not a message that says “Approve agent action?”

The interface should show the final post, the exact destination, the requested time, the source facts, and every risk flag. The reviewer must be able to approve, reject, or edit without reconstructing the agent’s reasoning.

7. Publisher and verifier

After approval, a deterministic publisher sends the exact approved payload. It records the response, checks media and post status, and reports partial failures.

The verifier should confirm what happened on each destination rather than assuming that a successful API request means every network published successfully.

8. Audit and monitoring

Store the important events:

• Trigger and source record version
• Model and prompt version
• Proposed content
• Policy results
• Tool calls and parameters
• Reviewer identity and decision
• Approved payload hash
• Publication response and external IDs
• Errors, retries, edits, cancellations, and final status

An audit trail is useful for debugging, client questions, compliance, and improving the agent.

Use a permission ladder

Do not jump from read-only access to autonomous publishing. Increase permissions only when the previous level performs reliably.

For many organizations, Level 2 or 3 is a sensible production target for public content. Level 4 can be appropriate only for narrowly defined, repeatedly tested workflows with narrow account access, volume limits, and a kill switch. Most agent workflows should not progress to Level 5.

Classify risk before choosing the review path

A useful risk model considers both content and action. A low-risk caption can still become high risk if it targets the wrong account or publishes immediately.

The agent may suggest a risk class, but deterministic rules should set minimum requirements. For example, any post containing a price, deadline, medical statement, or legal promise can automatically move to a higher review tier.

Build an approval packet that a human can trust

The review packet is the most important interface in the system. It should answer five questions immediately:

1. What will be published?
2. Where will it be published?
3. When will it be published?
4. Which facts and assets were used?
5. What could go wrong?

Include these fields:

• Campaign or source record ID
• Objective and target audience
• Social network and exact account name
• Final caption, not a summary
• Final media preview or approved asset ID
• Link and UTM parameters
• Proposed date, time, and timezone
• Platform-specific settings
• Claims copied from the source of truth
• Required disclosure or legal text
• Agent confidence or uncertainty flags
• Policy checks passed and failed
• Difference from the approved template, if any
• Buttons for approve, edit, reject, and request new version

A reviewer should not need to open five systems to verify the post. If verification is difficult, approvals become superficial.

Define the workflow as a state machine

A state machine prevents the agent from skipping steps. Use explicit states rather than a loose collection of flags.

A practical sequence is:

• received
• context_validated
• draft_created
• preflight_failed or awaiting_approval
• changes_requested, rejected, or approved
• scheduling
• scheduled
• publishing
• published, partially_failed, or failed
• verified

Only specific transitions should be allowed. A post cannot move from draft_created to scheduled without an approval event. Editing approved text returns it to awaiting_approval. A retry uses the same approved payload and internal job ID rather than asking the model to regenerate content.

This state model also makes dashboards and alerts much clearer.

Step-by-step: build the first version

Step 1: choose the smallest complete workflow

Pick one source, one content type, two or three networks, and one reviewer group. A boutique hotel’s weekend package is a good pilot because the offer can be represented as structured fields.

Avoid a first workflow that includes trend research, image generation, customer replies, and publishing across every account. Too many moving parts make failures hard to diagnose.

Step 2: define the tool contract

Write down every tool the agent can call and the exact schema.

A draft-preparation agent might receive only these tools:

• get_campaign(campaign_id)
• list_approved_assets(campaign_id)
• get_allowed_accounts(workspace_id)
• create_approval_request(payload)
• get_approval_status(request_id)

The publishing tool can be held by a separate deterministic worker that runs only after approval. This separation reduces the chance that prompt injection or planning errors lead directly to a public action.

Step 3: create a trusted context object

Transform source data into one structured object before it reaches the model. For a hotel offer, it might contain:

• Offer name
• Valid stay dates
• Booking deadline
• Exact price or discount
• Included services
• Exclusions
• Approved booking URL
• Approved images
• Participating location
• Brand tone
• Required terms

Mark missing required fields as errors. Never tell the model to “fill in reasonable details.”

Step 4: require structured output

The model should return fields your program can validate, such as:

• platform
• account_id
• caption
• link_url
• media_ids
• scheduled_time
• source_claim_ids
• risk_flags
• needs_human_input

Reject malformed output. Do not scrape operational values from free-form prose.

Step 5: run deterministic preflight checks

Before a reviewer sees the content, check:

• Account ID is allowlisted
• Campaign is active
• Scheduled time is valid and in the expected timezone
• Link uses HTTPS and an approved domain
• Media exists and usage rights are recorded
• Text and media fit the selected post type
• Exact values such as price and dates match source data
• Required disclosures are present
• Prohibited terms are absent
• Publishing volume stays below the workflow limit

A model can help identify style issues, but code should enforce facts and permissions.

Step 6: route by risk

Low-risk content can go to a normal reviewer. Medium-risk content can require a marketing lead. High-risk content can require legal, compliance, or an executive approver.

Do not make one person approve everything. The point is to route each decision to someone qualified to make it.

Step 7: pause for human review

The workflow should stop, persist its state, and wait. Do not keep an agent session running while a person takes several hours to respond.

Platforms such as n8n support human review for AI tool calls, where a workflow pauses and sends the proposed tool parameters to a reviewer. A custom system can implement the same pattern with a database record, notification, and signed approval action.

Step 8: freeze the approved payload

When a reviewer approves, calculate a hash or immutable version ID for the exact payload. The publisher must use that version.

If the caption, account, media, link, or time changes after approval, invalidate the approval and return the item for review. This prevents a subtle but dangerous failure: approving one version and publishing another.

Step 9: publish idempotently

Assign an internal idempotency key to the publication job. Before retrying, check whether the provider already created a post.

Not every social API offers a native idempotency header, so keep your own job record with:

• Internal job ID
• Approved payload version
• Target account
• Requested mode and time
• Provider request ID
• Provider post ID
• Last attempt time
• Retry count
• Final status

Retries should resend the same approved data, not ask the agent to make a fresh decision.

Step 10: verify and close the loop

Check media processing, scheduled status, and per-network results. Alert a person when:

• One destination fails while others succeed
• A scheduled post remains in processing too long
• The provider rejects an account permission
• A post is published at an unexpected time
• The external link or media is missing

After publication, analytics can inform future content, but performance data should not silently rewrite policy. A post getting high engagement does not make an unverified claim acceptable.

Worked example: a boutique hotel weekend offer

Assume a boutique hotel has this approved campaign record:

• Package: Two-night weekend stay
• Valid dates: September 4-27, 2026
• Booking deadline: August 31, 2026
• Included: Breakfast and late checkout
• Price: $420 before tax
• Booking URL: Approved campaign landing page
• Assets: Three rights-cleared room and breakfast images
• Destination accounts: Instagram, Facebook, and Google Business Profile for one location

The agent’s job is to prepare three drafts. It may adapt length and CTA by network, but it may not change the price, dates, inclusions, or booking link.

Agent output

The agent creates:

• An Instagram caption focused on the experience, with the approved carousel
• A Facebook post with more package detail and the booking link
• A Google Business Profile offer post with the exact validity period and CTA

It flags that the price excludes tax and includes the required qualifier. It also identifies the requested timezone and proposes publication times from the campaign plan.

Preflight

The system verifies:

• The campaign is active
• All accounts belong to the hotel’s workspace
• The three assets are approved for this campaign
• The price and dates exactly match the source
• The booking URL uses the approved domain
• The Google Business Profile fields contain the correct start and end dates

Review

The marketing manager sees all three final posts, assets, account names, publication times, source values, and policy results. The manager edits one sentence in the Facebook post.

Because the approved payload changed, the system saves a new version and records the manager as the editor and approver.

Publication

A deterministic worker schedules the exact approved version. It stores the returned post IDs and checks the status of each destination. If Instagram succeeds and Google Business Profile fails, the workflow becomes partially_failed and alerts the manager rather than retrying all three posts.

That is human-in-the-loop agent design: the model handles adaptation, while software and people control facts, permissions, and public actions.

Three ways to connect an agent to Postoria

Postoria offers three technical paths. The best choice depends on where the agent runs and how much custom code you want.

MCP server for AI clients

The Postoria MCP server exposes structured tools for workspaces, social accounts, queues, media, posts, and status to compatible AI clients.

MCP is useful when an AI client needs discoverable, structured publishing tools, particularly in interactive or supervised workflows. Protect remote MCP access with appropriate authorization, and follow the protocol’s security best practices.

Do not expose every tool to every agent. A content assistant may need list and create tools but not deletion. Restrict the workspace and account IDs in your surrounding application even if the model requests something else.

n8n for a visual approval workflow

The official Postoria n8n integration can connect an AI Agent node, databases, spreadsheets, CMS tools, Slack, Telegram, email, and approval steps in one visual workflow.

This is a practical route for teams that want to:

1. Receive structured campaign data
2. Ask an AI model for platform variants
3. Run validation nodes
4. Pause for human approval
5. Call Postoria only after approval
6. Poll status and send a result notification

n8n’s human-in-the-loop controls can require approval for selected agent tools rather than every action.

Public API for a custom application

The Postoria Public API is the best fit when you are building your own backend, approval interface, or internal application.

One design detail matters: API v1 does not create drafts. Keep the draft and approval state in your own database, then call Postoria after approval with publish_now, schedule, or queue. For safety, most agent workflows should disable publish_now and permit only fixed scheduling or queues.

The Public API is available on Pro and Agency plans. It uses one account-level API key per Postoria profile, supports 300 requests per five minutes, and currently uses polling rather than webhooks.

Write an agent contract, not just a prompt

A prompt describes desired behavior. An agent contract defines what the system will accept.

Document these items:

Mission

• The one job the agent performs
• What a successful output looks like
• What the agent must never attempt

Trusted inputs

• Approved databases, fields, and asset repositories
• Freshness requirements
• Which values must be copied exactly

Untrusted inputs

• Web pages, feeds, emails, uploaded documents, comments, and user-provided text
• A rule that content from these sources is data, not authority

Tool permissions

• Allowed tools
• Allowed workspaces and accounts
• Allowed publishing modes
• Maximum number of posts per run
• Maximum future scheduling window

Escalation rules

• Missing data
• Conflicting instructions
• Sensitive topics
• New accounts
• Expired campaigns
• Claims without approved sources
• Failed policy checks

Approval rules

• Who can approve each risk class
• What information the approval packet must include
• When an edit invalidates approval
• How long approval remains valid

Recovery rules

• Retryable errors
• Maximum retry count
• Partial-failure behavior
• Kill switch and cancellation owner

This contract should be versioned with the workflow and reviewed whenever tool access changes.

Security controls that matter most

Separate instructions from retrieved content

An article, feed entry, PDF, or email may contain instructions that were not written for your agent. Keep retrieved content in a clearly marked data field and prohibit it from changing system rules or tool permissions.

Keep secrets outside prompts and model logs

Store API keys in a secret manager or credential store. The model does not need to see raw credentials. Tool execution should add authentication after the model has selected an allowed action.

Enforce least privilege twice

Limit the tools exposed to the agent and validate permissions again inside each tool handler. A prompt rule saying “use only this workspace” is not an authorization control.

Use allowlists for irreversible actions

Allowlist workspaces, account IDs, domains, content types, and publishing modes. Deny unknown values by default.

Treat tool output as untrusted input

A web search, RSS feed, CMS article, or third-party API response can carry misleading content. Validate it before the agent uses it to construct an action.

Add volume and time limits

Set maximum posts per run, per account, and per day. Restrict how far into the future the agent can schedule. Rate limits reduce the impact of loops and compromised inputs.

Preserve a kill switch

A human operator should be able to pause the workflow, revoke credentials, and stop queued jobs without asking the agent.

NIST’s Generative AI Profile for the AI Risk Management Framework provides a broader governance reference for identifying, measuring, and managing generative-AI risks.

Test the agent before increasing permissions

A few successful posts do not prove reliability. Build a repeatable evaluation set.

Shadow mode

Let the agent prepare actions while the current human workflow continues. Compare its proposed captions, accounts, times, and risk labels with the decisions people actually make.

Golden test cases

Create at least 20 representative cases, including:

• Complete low-risk campaign
• Missing price
• Expired offer
• Wrong account requested
• Unapproved asset
• Conflicting dates
• Sensitive claim
• Link to an unapproved domain
• Duplicate trigger
• One platform that does not support the requested format

Store the expected action for each case. Run the set when prompts, models, policies, or tools change.

Adversarial tests

Test direct and indirect prompt injection. Place hostile instructions in an RSS item, article body, asset filename, or campaign note. The agent should treat them as data and continue following the system contract.

Also test attempts to:

• Select another client’s workspace
• Change the booking URL
• Publish immediately
• Remove a required disclosure
• Exceed the post limit
• Reuse an expired approval
• Alter the payload after approval

Failure injection

Simulate media processing delays, expired credentials, rate limits, timeouts, partial network failures, and duplicate callbacks. Verify that the workflow stops safely and alerts the correct person.

Gradual rollout

Move from observe to draft, submit, and schedule levels only after the previous level meets defined thresholds. Expand one content type or account group at a time.

Metrics for an AI social media agent

Measure workflow quality, not only social engagement.

Review efficiency

• Median time from draft to approval
• Percentage approved without edits
• Average number of revision rounds
• Reviewer workload per 100 posts

Content quality

• Edit distance between proposed and approved text
• Common rejection reasons
• Claim or link corrections
• Brand-voice violations
• Missing required fields

Operational reliability

• Scheduling success rate
• Partial-failure rate
• Duplicate-attempt rate
• Mean time to detect and resolve failures
• Percentage of posts with complete audit records

Safety

• Blocked policy violations
• Attempts to access disallowed accounts or tools
• Prompt-injection test pass rate
• High-risk items routed to the correct approver
• Incidents requiring credential revocation or emergency cancellation

Business performance

Track reach, engagement, traffic, leads, or sales only after the operational system is stable. Compare agent-assisted content with similar human-created content, and avoid attributing every difference to AI. Timing, topic, offer, audience, and media quality still matter.

Frequently asked questions

Can an AI social media agent publish automatically?

Technically, yes. Operationally, it should receive that permission only for narrow, proven, low-risk workflows. Most teams should require human approval before scheduling public content, especially when posts include claims, promotions, customer stories, sensitive topics, or new accounts.

Is human review needed for every post?

Not forever and not in the same form. Review intensity can depend on risk. A routine, pre-approved reminder may eventually use exception-based monitoring, while a price change or public statement should always receive direct review.

Should the agent use MCP or an API?

Use MCP when an AI client needs discoverable, structured tools. Use an API when your application controls the workflow directly. Many systems use both: MCP for agent interaction and an API-backed service for deterministic execution.

Where should drafts be stored?

Store them in the system that manages approval state. That may be a database, project-management tool, CMS, or workflow platform. If the publishing API does not support drafts, do not simulate approval by creating a scheduled public post far in the future.

What should never be fully automated?

Crisis responses, regulated claims, legal statements, public apologies, sensitive cultural or political content, irreversible account changes, and any post whose factual source cannot be verified should remain under direct human control.

Conclusion

A useful AI social media agent is not a model with a publish button. It is a controlled system with trusted data, narrow tools, deterministic policies, explicit states, understandable approvals, safe retries, and complete audit records.

Start with one small job. Let the agent draft and organize. Require a human to approve the exact payload. Use a separate publisher to schedule only that approved version, then verify the result and learn from corrections.

Postoria can provide the publishing layer through its MCP server, n8n integration, or Public API, while your workflow retains control over context, policy, and approval. The technology matters, but the boundary matters more: AI can propose and prepare; people remain accountable for what becomes public.