How do I know which account the agent is allowed to use?
An AI agent should select an account from an explicit identity record, never from whichever connection happens to be available. Each record should name the client or brand, network, account identifier, account label, permitted actions, owner, and current connection state.
A human-readable account name is useful for review, but the agent also needs a stable identifier that does not change when a display name or handle changes. Keep the identity record separate from the credential. The credential proves access; the identity record defines whose account that access represents.
Require the agent to show the selected account before it drafts or publishes. If two connections have similar names, the agent should stop and ask for a choice rather than infer one. The same rule applies when an account is disconnected, renamed, transferred, or connected by a different team member.
For operators managing several brands, an account-to-client map prevents the most expensive class of mistake: a valid post sent to the wrong valid account. The map should also record whether the connection is available for publishing or only for reading and analytics.
In PostWharf that map is the workspace. Each workspace holds one brand's or one client's channels, and each agent connection opens exactly one workspace, so the agent sees that brand's accounts and no others. Every channel has a stable id beside its handle, and the agent's list of channels flags any that must be reconnected before a post can reach it.
For more context, read How to Publish Social Posts Safely from an MCP Server.
Which permission should an agent receive?
An agent should receive only the permission needed for the requested action, and publishing access should be granted deliberately rather than bundled into every connection. Read access, draft access, scheduling access, and live publishing access are different operating modes.
Permission names and approval requirements vary by platform and change over time. The developer wiring the agent in should check the relevant official documentation before requesting access, then record the granted scope in the connection record. A successful connection does not prove that the account can publish every format or use every endpoint.
Treat an expired, revoked, or incomplete permission as a blocked action, not as a reason to keep retrying. The agent should explain which capability is missing in ordinary language and direct the operator to reconnect or approve the required access. It should never ask the model to guess whether a permission is sufficient.
A useful boundary is to let the agent prepare content with broad access, but require a separate, explicit publishing capability for live actions. Review the current requirements in the official developer documentation because platform rules, eligibility, and permissions change.
For more context, read How to Verify That a Social Post Really Published.
What content contract must exist before publishing?
A content contract must define what the agent may publish, what it must reject, and which fields each destination requires. A plain text request such as “post this everywhere” is not a publishing specification.
The contract should cover the final text, media files, links, alt text where relevant, destination, intended time, authorisation state, and any brand or legal restrictions. It should also state whether the agent may shorten, crop, reformat, or omit content when a destination cannot accept the original version. Without that rule, a model can make a silent change that turns an approved draft into a different post.
Use a structured draft with a status such as draft, approved, scheduled, publishing, published, or failed. Store the exact approved version separately from any adapted version. Approval should attach to a specific account, destination, and content version, not to a vague campaign name.
The overlooked decision is whether “publish” permits adaptation. If the answer is no, incompatible destinations should be reported as blocked. If the answer is yes, every transformation should be visible before approval or recorded after publication.
PostWharf takes the strict answer. A caption over a network's limit is refused when the post is created, not cut short on the way out, and a post shape such as a Story that a network does not offer is refused rather than quietly turned into a feed post. Where you want a different version, you give that network its own wording and hashtags inside the same post, so the adaptation is written down before anything is sent.
How should the agent handle destination-specific differences?
The agent should create a separate delivery plan for each destination instead of treating cross-posting as one operation. A delivery plan names the target account, content version, media variant, timing, and rules that apply to that destination.
Different services can impose different limits on text, media, links, formats, account roles, and timing. Those rules may also change, so the integration should validate the plan against current platform documentation and the destination's response before attempting publication. A post that is valid for one account can be invalid for another without either connection being broken.
The agent should report a partial result honestly. If two destinations accept a post and one rejects it, the run is partially complete, not successful. The operator needs the accepted destinations, the blocked destination, the reason in plain language, and the next safe action.
The practical decision is whether the agent may automatically alter content to fit. Automatic adaptation is acceptable only when the contract permits it and the result remains reviewable. Otherwise, the agent should produce a repair task rather than publish a shortened, stripped, or mismatched version.
What counts as proof that a post was published?
A publish request being accepted is not proof that a post is visible on the intended account. Proof should include a destination identifier, the final content or a reliable content fingerprint, the account identity, and a later read-back or status check when the platform permits one.
The agent should separate three states: request accepted, publication confirmed, and visibility reconciled. An accepted request may still lead to delayed processing, moderation, media failure, or a post that appears under a different object than expected. The operator needs those states presented separately instead of seeing one green “published” label.
A useful verification record stores when the request was made, what the agent sent, what identifier the service returned, and what the follow-up check found. The check should compare destination and content, not merely whether an identifier exists. If verification cannot run, the result should say “unverified” and give the operator a way to inspect the destination.
An agent should not tell an operator that a post is live until evidence supports that claim. The same evidence makes later support and reconciliation possible.
PostWharf builds that evidence into every post. One post fans out to one delivery per network, and a post where one network refused reads as partial, not published. Each delivery carries its status, the live link once published, or the reason it failed, and published deliveries are checked again afterwards, so a post removed later stops reporting as live. The MCP server's health tool names the networks that post to real accounts, and agents are told never to describe a delivery outside that list as published.
When should an agent retry, and when should it stop?
An agent should retry only when it can show that repeating the operation cannot create an unintended duplicate or when the platform provides a safe way to identify the original attempt. Unknown outcomes require reconciliation before another publish request.
A timeout, interrupted connection, or delayed response does not tell the agent whether the destination received the post. Retrying immediately can produce duplicates, while refusing every retry can leave a campaign incomplete. The integration should record a client-generated operation identity, preserve the request details, and check for a matching destination result before sending again whenever the platform allows that approach.
Validation failures, missing permissions, rejected media, and ambiguous account selection should stop the run. Temporary service unavailability may be retried under a bounded policy, with increasing delays and a clear final state. The agent should never let the model decide retry behaviour from the wording of an error.
Operators need a recovery queue, not a vague failure message. Each item should say whether the outcome is confirmed, failed before delivery, or unknown. Unknown items stay blocked until a read-back, operator check, or platform-specific lookup resolves them.
PostWharf takes the retry decision away from the model. Failures in transit are retried with backoff, and a permanent rejection is not blindly retried, because it would fail the same way again. Posting calls accept an idempotency key, so an agent that repeats a call after a dropped connection gets back the post it already made, and a retry goes only to the networks where the post failed.
Which posts need human approval before the agent acts?
Human approval should be required whenever the agent cannot prove that the content, account, timing, and destination all match an established policy. Approval is a control for uncertainty, not a cosmetic step before a button click.
Set approval rules around risk and novelty. New accounts, sensitive subjects, regulated claims, unfamiliar links, changes to approved wording, unusual posting times, and content created from incomplete instructions deserve review. Routine posts can use a lighter workflow only after the operator has defined what routine means and what evidence is retained.
Approval must expire when the draft changes. A model that edits a caption, swaps media, changes the destination, or alters a link should return the item to the appropriate review state. Approval should also identify the approving person and the exact version approved.
Give the reviewer a compact decision screen: selected account, final content, media preview, destination-specific adaptations, scheduled time, and known risks. The reviewer should be able to approve, reject, edit, or route the item for clarification. A vague “looks good” instruction should not grant blanket authority to future posts.
PostWharf's MCP server keeps that pause in place for agents. Its save_draft tool stores a post without queueing it, and the server tells agents to prefer it whenever they act on their own initiative. Nothing in a draft reaches a network until it is released, and agents are told to release one only when someone has said to.
What records let an operator recover from a failed post?
An agent needs an audit trail that connects the request, approval, delivery attempt, platform result, verification check, and final operator decision. Without that chain, a failed post becomes a guessing exercise.
Store the account identity, content version, media references, destination plan, permission state, approval record, operation identity, timestamps, returned destination identifiers, verification evidence, and any subsequent edits or deletions. Protect credentials separately and avoid placing secret values in prompts, logs, or screenshots. Retain only what the business needs, with access limited to people who manage the accounts.
Build a reconciliation view that compares intended posts with confirmed destination records. The view should expose missing confirmations, duplicates, partial runs, expired connections, and content that changed after approval. It should support an operator action for each exception, such as reconnect, inspect, retry safely, mark as manually resolved, or cancel.
The most useful success measure is not how many requests the agent sent. It is how quickly an operator can explain every intended post and resolve every uncertain outcome.
That is the record PostWharf keeps, whether a post came from an agent, a script or the web composer. The receipt for every post sits in the dashboard after the chat ends, the events feed and webhooks report each delivery, retry and failure, and a failure carries an action field naming what to do, such as reconnecting the account. The owner is emailed when a post does not go out or a channel needs reconnecting. Every plan includes the MCP server, REST API and CLI, from $15 a month with a seven-day free trial; the developer page shows all three side by side.
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
Can an AI agent publish with the same connection used for analytics?
Not necessarily. A connection may permit reading account data without permitting live publishing, or it may allow publishing only for particular formats or account roles. The integration should inspect the granted permissions and validate the requested action against current platform requirements before presenting a publish option. In PostWharf, one workspace key both publishes and reads back the figures each network reports for a post, such as views, likes, comments and shares, where the network provides them.
What should happen when a platform says a post was accepted but it cannot be found?
Mark the outcome as unverified and do not immediately retry. Preserve the request details, check the destination using the returned identifier or an approved read-back method, and ask the operator to inspect the account if automated verification is unavailable. Retry only after the original outcome is resolved.
Does approval still apply if the agent changes a post for one destination?
Yes, unless the publishing policy explicitly permits that transformation. Approval belongs to a specific content version and destination plan. A changed caption, link, crop, format, or media file should be shown to the reviewer and should require renewed approval when the change could affect meaning or risk.
Should the agent choose an account from its available connections?
No. The agent should use an explicit account selection tied to a stable account identifier and a client or brand record. Similar names, renamed accounts, transferred ownership, and stale connections make inference unsafe. Ambiguous selection should stop the run and request a human choice.
Where can developers check changing publishing requirements?
Developers should consult the official documentation for each destination and review permission, format, eligibility, and policy changes before maintaining an integration. Official requirements differ by platform and can change independently, so a previously valid connection or workflow should not be treated as permanently valid.
PostWharf is priced per workspace rather than per connected channel, and every plan carries unlimited channels. See per-brand pricing.