SMM Agent's Documented Publishing Gates: What the Public Materials Commit To and How to Verify Them

A verification path for operators who want AI help with social content but will not let a post publish without approval.

*Image: Insomnia and Social Media by https://pixabay.com/en/users/xusenru-1829710/, licensed under CC0.*

SMM Agent's posting documentation instructs agents to create drafts first, and publishing is a separate, explicit call. The homepage frames the same arrangement in product terms, as an operating layer for social posts, replies, approvals, and platform-specific distribution, aimed at teams that want automation with control. For an operator who wants AI help with social content but will not ship unapproved posts, that split is the claim to check before granting access to real accounts, and the check fits in one session: a created draft should stay a draft until an explicit publish call.

Two standards of evidence run through the public material. Documented statements are what a named surface states or specifies; verified statements are what someone observed the product doing. The surfaces reviewed here, from the homepage and the posting docs to the terms, the blog index, and the repository README, supply documented material, some of it specific about mechanics, and no independent test results. Product statements below stay attached to the surface that makes them, and the unresolved items become checks in the first trial near the end.

The documented posting contract

The posting docs begin with access: an App Access key with Read and Write permission, scoped to the workspace. The quickstart stores that key as the SMM_AGENT_API_KEY secret and creates posts with POST https://smmagent.app/api/posts, where intent defaults to a draft and content is required unless media is supplied.

Scheduling reuses the same endpoint with intent set to "schedule" and a future ISO timestamp in scheduledAt, and the optional platformIds field narrows targets to connected channels inside the current workspace. Publishing is a separate endpoint, POST /api/posts/{id}/publish, and the docs say it should stay behind explicit user approval. The docs also publish a drop-in agent prompt with matching defaults: drafts by default, scheduling only with a future scheduledAt, publishing only after explicit approval, and an instruction not to print the API key.

None of the calls in this section has been executed. The draft-and-publish gate described here rests on documentation; observing it takes a trial.

The control plane behind the agent

The posting contract is one layer of a system the repository README describes as a Next.js 15 control plane for scheduled posts, reply review, provider connections, and deployment health; the README's own summary is "Dashboard first, agent second."

The README lists workspace approval modes, post approval requests, and review queues as first-class surfaces, and it records audit events, a content reviewer, fail-closed writer and reviewer behavior, and durable run evidence as part of the operating controls.

The README documents one lane with no per-post human review or approval step once the worker is enabled: the X liked-post queue. A like from the account holder feeds the queue; liked posts become scheduled post rows assigned to hourly slots between 8 AM and 8 PM, deduplicated with an x-like:<tweetId> key, and published later by the normal scheduler. The import worker is disabled by default and runs only when both X_LIKES_AUTOPUBLISH_ENABLED=true and X_LIKES_AUTOPUBLISH_MODE=publish are set.

The homepage describes reply operations as covering discovery, drafting, and risk scoring, with the human approval step kept visible.

Declared limits in the terms and the repository

The terms of service took effect April 21, 2026, covering access to smmagent.app, clawposter.app, and social.maxpetrusenko.com during a migration window; the README notes that social.maxpetrusenko.com is kept temporarily for legacy sessions and OAuth callbacks.

From the terms

• AI-generated content may be inaccurate, incomplete, duplicative, delayed, offensive, infringing, noncompliant, or unsuitable, and users are responsible for reviewing and approving output where review controls are available. The terms state the service is not intended for legal, financial, medical, safety, crisis, political, employment, or regulated-industry advice.
• Platform APIs can fail, revoke access, change scopes, reject posts, throttle requests, remove content, or return incomplete data. The terms disclaim responsibility for platform decisions and third-party outages, note that features may not work until extra platform review, permissions, or verification are satisfied, and allow features to change, be suspended, limited, or discontinued when platform APIs, rate limits, account permissions, or provider policies change.
• Liability is capped at the amount paid for the service in the three months before a claim, or 100 dollars if nothing was paid, and the terms set New York governing law with an informal dispute step before legal claims.

From the repository README

• Additional public schedules require operator approval.
• The README instructs against claiming Medium autopublish, and Medium mutation and scheduling are conditioned on approval plus visible UI proof.
• Comment and DM surfaces carry stricter safeguards, and some of those surfaces are paused.
• SQLite remains the active runtime database while the Supabase Postgres migration is planned and incomplete, and cross-workspace aggregate reporting is still open.

What the public record does not settle

The pages reviewed leave four items unresolved.

• Independent assessment. No third-party tests or independent assessments of the product appear among the pages reviewed. The record comes from the product's pages and the waitlist pages at clawposter.app and smmclaw.app.
• Client reviews. The homepage states that reviews are not fabricated or bought and are published with consent, tied to the campaigns they came from. No client reviews appear on the pages reviewed, so the absence is scoped to those pages.
• Platform counts. clawposter.app states sixteen platforms, while the repository registers eleven named provider integrations (X/Bird, LinkedIn, Instagram, Facebook, Threads, TikTok, Bluesky, Mastodon, YouTube, Pinterest, and Google Business), plus Late and Zernio where configured. Neither figure establishes which accounts a workspace can connect.
• Autonomy emphasis. clawposter.app advertises letting posts run autonomously, and April 2026 blog entries describe unattended posting, while the homepage describes replies with a visible human approval step and the repository documents the liked-post worker as disabled by default with an explicit publish mode. No observed behavior reconciles the difference.

A bounded first trial

None of the checks below has been run against the live product. Each pairs one action with the behavior the documentation specifies, so a match becomes evidence of your own and a mismatch shows where the documentation stops. The terms note that some features may stay unavailable until platform review, permissions, or verification are satisfied, so record a blocked check as an availability note.

1. Key scope. Create an App Access key with Read and Write, store it as SMM_AGENT_API_KEY, and confirm that posting requires it and keeps targets inside the workspace; the docs scope keys to a workspace.
2. Draft default. Create a post and confirm it lands as a draft that reaches no connected platform. Draft is the documented default intent, and publishing is a separate call.
3. Scheduling. Queue a post with intent set to "schedule" and a future ISO scheduledAt, and confirm it appears as a scheduled item with nothing published yet; a past timestamp should be refused.
4. Explicit publish. Publish the draft through POST /api/posts/{id}/publish and inspect the approval record behind it; if the workspace exposes approval modes, set one that requires review and confirm the publish path respects it.
5. Workspace targets. Record which providers the workspace can connect, and confirm platform targets stay inside it; your own connection list is the count that applies.
6. Liked-post lane, if used. Confirm the background worker stays off until X_LIKES_AUTOPUBLISH_ENABLED=true and X_LIKES_AUTOPUBLISH_MODE=publish are both set, and confirm the queue deduplicates likes through the x-like:<tweetId> key.

A single session will not settle per-platform delivery behavior at volume, the quality of reply review under real traffic, or the depth of audit history over months. Those answers build with repeated use.

If the checks hold, the operator ends the session with evidence of their own: drafts stayed drafts, schedules queued, and publishing waited for an explicit call. That evidence is what an evaluation can establish before real accounts go live. Output review and platform outcomes stay with the account holder under the terms.