SMM Agent's Public Record: Which Publishing Lanes Run Unattended and Which Wait on a Human Gate

A lane-by-lane read of the homepage, repository, terms, and blog index for operators setting a review policy before they connect accounts

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

Liked-post import in SMM Agent's public repository does nothing until two named conditions are set, and the Medium lane requires operator approval with visible UI proof. Those two gates set up the rest of the record, which answers the same questions for each publishing lane: what state the lane starts in, where a human step sits before anything reaches a platform, what condition changes the default, and what an operator can verify in a trial before connecting brand accounts.

What the public record contains

Four first-party surfaces form the record, and each is a different kind of statement. The product homepage is promotional and describes SMM Agent as an operating layer for social posts, replies, approvals, and platform-specific distribution, aimed at teams that want "automation with control." The public repository documents the control plane and states that its content covers verified behavior. The terms of service, effective April 21, 2026, describe the service as helping users draft, adapt, schedule, publish, and monitor social content across connected platforms, and reserve the right to change or discontinue features. The blog index lists dated posts from April 9 through September 28, 2026; only the index was checked, so its titles are pointers to posts whose bodies were not reviewed. Both the repository and the terms also reference a migration window during which social.maxpetrusenko.com remains available alongside smmagent.app; the repository ties the window to legacy sessions and OAuth callbacks, and no end date is stated on either surface.

The documented route a post takes

The repository states its design principle as "Dashboard first, agent second," which places the operator's control surface ahead of the agent's autonomy. The documented route starts with source signals: RSS feeds, the manual composer, liked X posts, YouTube playlists, and the article workspace. Those signals move through source capture, a draft, a reviewer and evaluation step, packet readiness, and a scheduled slot. The operator control plane sits between the queue and dispatch, and provider dispatch is followed by a production proof stage. The homepage adds one calendar for planning, reviewing, and tracking channels.

The repository documents five lanes on that route, each with a different publish signal:

• Manual post: the operator composes and sends it.
• Workspace approval: publishing waits for an approval decision from the review queue.
• Liked-post queue: publishing waits on two enablement settings.
• Medium article: publishing waits on operator review before any mutation or scheduling.
• Replies: a human approval step stays visible, and the homepage describes reply operations that find conversations, draft responses, and score risk.

The gates leave records behind. Workspace approval modes, post approval requests, and review queues are described in the repository as first-class surfaces, along with writer and reviewer behavior that fails closed (a failed check stops the post). The approval-request route records the request, the decision, and an audit event.

Default states and enablement conditions

The liked-post pipeline carries the most explicit enablement rules in the record. The repository keeps its background import off until it is explicitly enabled, and it allows publishing only when both X_LIKES_AUTOPUBLISH_ENABLED=true and X_LIKES_AUTOPUBLISH_MODE=publish are set. Once enabled, liked X posts become scheduled posts in hourly slots between 8 AM and 8 PM, deduplicated by the key x-like:<tweetId>.

The repository's boundaries add two more limits. They instruct against claiming Medium autopublish and require operator approval, with visible UI proof, before any Medium mutation or scheduling. Comments and direct messages carry stricter safeguards that are partially paused.

The homepage describes model keys as stored and tested per workspace, with model selection limited to models unlocked by active keys.

Every statement in this section comes from documentation. No runtime test was performed for this review, so each condition is something to confirm inside a workspace, and comments and direct messages are the surfaces to leave alone.

Where the first-party surfaces state different things

A related first-party page at clawposter.app uses different wording for the same subjects, and ClawPoster branding still appears in the terms page header.

Autonomy wording

• clawposter.app tells visitors they can let the agent run autonomous (How It Works, step 3).
• The repository states that the marketing landing page mentions autonomous behavior while verified behavior is gated, and that liked-post import stays off unless explicitly enabled.

Platform coverage

• clawposter.app says sixteen platforms, and the same page lists eleven names: X, LinkedIn, Instagram, TikTok, Threads, Bluesky, Facebook, YouTube, Pinterest, Reddit, and Mastodon.
• The repository's provider registry names eleven providers, including Google Business, with a separate note about "Late/Zernio where configured."

Access state

• clawposter.app asks visitors to join a waitlist for launch.
• smmagent.app offers "Start using SMM Agent" and a sign-in link.

None of the three resolves from the pages themselves. Each becomes a check for a trial: compare what a workspace connects against both platform lists, confirm which page matches the sign-up experience, and verify that the liked-post queue stays off until its enablement settings are set.

What the terms put on the operator

The terms of service place the review duty on the user. They state that AI-generated content may be inaccurate, incomplete, or unsuitable, that users are responsible for reviewing and approving output wherever review controls are available, and that the service does not guarantee output is original, lawful, platform-safe, or factual. The terms extend the same caution to platform APIs, which can fail, revoke access, change scopes, reject posts, or throttle requests, and they note that some features may not work until platform permission requirements are satisfied.

The repository's gates are where that responsibility gets discharged. Review queues, approval requests, and visible UI proof put the human decision in the path and leave a record of it. For an operator, that keeps review policy inside the rollout plan, where platform rejections, scope changes, and throttling count as routine conditions.

What an operator can check, and what stays unproven

The repository's evidence map links public claims to implementation locations, which turns its statements into inspectable targets. Approval requests are the decision trail to inspect in a workspace. The health route returns database and runtime drift counts. The deploy workflow runs a public canary check, a SQLite backup, and rollback. A local evaluation path runs with DISABLE_AUTH=true against an isolated database, and the demo path's dashboards cover liked-post eligibility and skips, pipeline steps keyed x-like:*, article packages, and schedule drift. The map is operator-provided, and the file contents behind it were not opened for this review.

The limits are part of the record too. All four surfaces are first-party, so none of this is an independent audit and the pages do not establish effectiveness. No client reviews were displayed when the pages were checked; the homepage states that reviews will be published with consent and tied to the campaigns they came from, and the operator states it does not fabricate reviews or buy ratings. For the operator's own framing of the gates, the blog index lists a September 28, 2026 post titled "SMM Agent's Documented Publishing Gates: What the Public Materials Commit To and How to Verify Them," though only the index entry was checked.

The decision left open

The first lane to enable depends on the operator's review capacity and on the documented defaults. The liked-post queue is off unless enabled; the workspace approval lane runs on decisions the operator already makes in the review queue; Medium stays review-first; and comments and direct messages stay partially paused. The unresolved inputs are specific: whether the platforms a workspace connects match the lists on the pages and in the registry, which access state applies to a given sign-up path, and whether the documented gates behave as described once accounts are live. A failed check, or a paused surface that stays paused, is a reason to change the plan.