How do you turn a client brief into a publishable queue?
A client brief becomes a publishable queue only after each post has an owner, destination, format and deadline. Start by recording the campaign, intended account, target network, publishing window, asset location, caption, call to action and approval owner. Do not begin in the scheduler with a block of copy and a date, because missing context makes later failures difficult to diagnose.
Check that every post has one unambiguous destination and one accountable reviewer. Separate required dates from preferred dates, and record whether the post is time-sensitive or can move to the next available slot. Mark dependencies such as a landing page, discount code, product release or client sign-off. A queue should also identify posts that must not appear together, such as repeated announcements or competing offers.
For a developer or AI agent, represent those fields as structured data before sending anything to a publishing tool. For an operator, the same discipline can be a shared intake template. PostWharf can accept prepared posts through its web composer, REST API, command-line tool or MCP server, but the intake record should remain the source of truth for why each post exists.
For more context, read Social Media Approval Workflow: What to Check.
Which version of each post should be scheduled?
Each destination needs a deliberate version of the post, even when the central idea stays the same. Create a source version first, then adapt its text, media, links, mentions and call to action for each selected account. A single copy-and-paste operation often carries over an unsuitable aspect ratio, an irrelevant mention or wording that depends on a feature another network does not provide.
Check four things before scheduling: the caption matches the destination, the media opens and displays as intended, every link reaches the expected page, and the account name or mention is valid for that destination. Check text length and unsupported formatting against the current platform documentation, because publishing rules change. Review subtitles, alternative text and thumbnail choices where the destination supports them.
Keep a record of the source post and its destination variants. Give each variant a stable internal identifier so an operator can tell whether a later edit changed the caption, asset or destination. This record is more useful than treating every scheduled item as an isolated draft, especially when an agency needs to explain why two versions of one campaign differ.
What should you approve before scheduling?
Approval should happen after destination-specific edits and before a publishing time is committed. The reviewer should approve the exact caption, media, destination account, links, mentions, timing and disclosure, not merely the campaign idea. Approval of a planning document does not automatically approve the final item after a platform-specific rewrite.
Check that the reviewer has seen the rendered post or a faithful preview, including line breaks, crop, thumbnail and link placement where available. Check that legal or client requirements are attached to the approval record, rather than hidden in a chat thread. Confirm that the person approving has authority for that account and that no unresolved comment remains.
Lock the approved version or record a revision identifier. If an operator changes an approved caption, asset or destination, send the item back through the relevant approval step. An AI agent should never infer approval from the presence of a due date or from a previous approval of a similar post. The practical decision is simple: schedule only the version that a named reviewer can identify and defend.
How do you schedule without creating duplicate posts?
Duplicate prevention requires a stable post identity and a clear rule for what happens when a request is repeated. Assign one internal publishing ID to each intended post and destination, then store its current state, planned time and last submission attempt. A retry or timeout must look up that ID before creating another submission.
Check whether the item already has a confirmed publication, a pending submission or an unresolved delivery state. If the answer is yes, do not create a new post automatically. Ask an operator to reconcile the original attempt first, or use the publishing system's delivery evidence if it can safely identify the result. Keep the original request and later attempts linked, so a client does not receive two versions of the same update.
The rule applies equally to a web composer, an API integration, a command-line workflow and an AI agent. PostWharf supports publishing through all four of those entry points, so teams should use one shared identity and audit record rather than allowing each entry point to invent its own retry logic. A queue that prevents duplicates is safer than one that merely reports successful requests.
What should you check when the scheduled time passes?
After the scheduled time passes, check delivery evidence and the destination account separately from the scheduler's acknowledgement. A request being accepted for processing proves that the workflow received the post, not that the post is visible on the intended account. Verify the account, caption opening, media, link and publication time against the expected version.
Check within a defined operating window, then record one of three useful outcomes: confirmed live, still unresolved or not delivered. Do not mark an unresolved item as failed merely because it is not visible immediately, and do not mark it live solely because the scheduler says it finished. Visibility can be affected by review, processing or platform-specific timing.
For high-risk posts, capture the public post reference or an internal evidence record and note who checked it. For routine posts, a delivery report may be sufficient if its meaning is understood. PostWharf reports on delivery but does not provide analytics, social listening, an engagement inbox, link-in-bio or visual planning. Agencies should therefore keep delivery verification separate from later performance reporting and community-management work.
When should a failed post be retried?
Retry a failed post only after identifying whether the failure is correctable, temporary or uncertain. Correctable failures include invalid media, an outdated mention, missing permission or content that no longer meets a destination's rules. Temporary failures may clear without changing the post. An uncertain result requires reconciliation before another submission, because the first attempt may have succeeded even when confirmation did not arrive.
Check the evidence, not just the label. Compare the destination account, requested time, media and caption with the stored publishing ID. Check whether the platform has placed the item under review or whether account permissions have changed. Correct the smallest possible cause, preserve the original attempt, and record who approved the retry.
Do not retry sensitive or time-critical content indefinitely. If the publishing window has passed, decide whether a late post still serves the campaign or whether the client should approve a replacement. A developer should make retry limits and escalation states explicit. An operator should have a visible queue for unresolved items. The safe default is no automatic duplicate creation when delivery cannot be distinguished from non-delivery.
How do you handle edits after a post is scheduled?
A scheduled post should be treated as mutable only through a recorded change decision. When a client requests an edit, first determine whether the item is still queued, currently being submitted or already live. The answer decides whether to edit, cancel and replace, or leave the published item alone and issue a correction.
Check the requested change against the approval record, destination rules and campaign timing. Reapprove any change to claims, pricing, legal wording, links, media or target account. Keep the old and new versions linked, and record the person who requested, approved and applied the change. If the item is close to its publishing time, stop automatic action until the change decision is clear.
For API and AI-agent workflows, use an explicit update or cancellation policy instead of sending a new post when the intent is to modify an existing one. For manual workflows, use a queue status that makes replacement items easy to distinguish from duplicates. A client change is not merely an editing task. It is a new control point that protects the agency from publishing an obsolete version or publishing both versions.
Which publishing setup fits an agency with many accounts?
The right setup depends on whether the agency needs a human composer, repeatable automation, or both. A web composer suits operators who want direct review. A REST API suits a controlled integration with an existing content system. A command-line tool suits scripted operations, while an MCP server lets an AI agent submit posts through a defined publishing interface. The workflow controls remain necessary in every setup.
Check pricing against the unit that grows fastest. A tool priced per connected channel can become harder to forecast as client accounts and destinations multiply. PostWharf is priced per workspace with unlimited channels, with Starter at $15 a month, Startup at $29, Plus at $67 and Pro at $99, and a seven-day free trial on Starter. Those plan facts should be checked before purchase because commercial terms can change.
Check the boundary of the product as well as its entry points. PostWharf publishes posts and reports on delivery, but it does not provide analytics, social listening, an engagement inbox, link-in-bio or visual planning. An agency that needs those functions must keep them elsewhere. The honest choice is the setup that matches the missing work, not the one with the longest feature list.
Sources consulted: Meta for Developers (developers.facebook.com) · X Developer Platform (developer.x.com) · LinkedIn Developers (developer.linkedin.com) · TikTok for Developers (developers.tiktok.com)
Common questions
What is the most important check before scheduling an agency post?
Confirm that the exact destination-specific version has approval, the correct account, valid media, working links and a named publishing owner. Campaign approval alone is not enough if the caption, crop, mention or call to action changed during adaptation. Store that approved version with a stable internal publishing ID before scheduling.
What should an agency do when a post says it published but is missing?
Treat the result as unresolved until the destination account and expected content have been checked. Look for review or processing delays, compare the attempt with its internal publishing ID, and do not submit a duplicate while the first attempt could still appear. Escalate or replace the post only after recording the evidence and client decision.
Can an AI agent run a social media scheduling workflow safely?
An AI agent can prepare or submit posts safely when approval, destination validation, stable post identities and retry limits are explicit. The agent should not infer approval from a brief or create a new post after an uncertain result. PostWharf provides an MCP server, REST API, command-line tool and web composer for different publishing workflows.
How should agencies avoid paying more as client accounts increase?
Compare whether the tool charges by connected channel, workspace or another unit, then model the cost of the agency's expected account structure. Also check whether the product covers only publishing or includes adjacent work. PostWharf uses workspace pricing with unlimited channels, while delivery reporting remains separate from analytics and inbox functions.
How often should platform publishing rules be checked?
Check current platform documentation whenever a destination changes its content requirements, account permissions, media rules or publishing behavior. Rules change, so a workflow should not rely on an old assumption about formats, mentions or review. Keep a destination-specific validation reference and update it before a campaign with unusual media or timing.
PostWharf is priced per workspace rather than per connected channel, and every plan carries unlimited channels. See per-brand pricing.