Safety Rules for AI Agents Posting to Hundreds of Accounts

An AI agent posting to hundreds of accounts stays safe by following a short set of rules: publish only through official network APIs, hold the narrowest key it needs, never send identical captions across accounts, space dispatch between accounts, respect each network's limits and policies, and have a way to stop a run quickly. Most of these should be enforced by the platform and the key scopes, with the agent's instructions as a second layer rather than the only one.

Below is the rulebook we recommend, written so you can paste most of it straight into an agent's skill. Each rule comes with the reason behind it, because an agent that understands the reason handles edge cases better than one following a bare instruction.

Why do agents need their own safety rules?

A human scheduling posts makes mistakes one at a time. An agent makes them in batches. If the instructions contain an error, that error lands on every account in the run. Scale multiplies good work and bad work equally.

The networks are also explicit that volume and repetition are signals they watch. Meta's spam policy covers posting at very high frequencies, whether manual or automated, and repetitive content. YouTube's spam, deceptive practices and scams policies cover repetitive and untargeted content. These are policies about behavior, not about whether a person or software pressed the button.

The rulebook

Rule 1: Official APIs only

The agent publishes through a platform that uses each network's official API. No browser automation, no shared logins, no unofficial endpoints. Shager publishes through official network APIs only, so this rule is satisfied by the choice of platform rather than by the agent's discipline.

Why: unofficial methods break terms of service and put the account itself at risk, and they fail unpredictably.

Rule 2: Least privilege keys

Start every agent with read and write. Add publish only when a human has decided that agent may schedule. Use separate keys per client or per agent so revoking one does not stop everything.

Why: a key that cannot publish turns a bad instruction into a bad draft, which is harmless. Our article on API keys, scopes and audit explains the setup.

Rule 3: Draft first, schedule second

Every run creates drafts. Scheduling is a separate step after review or client approval.

Why: it creates a natural checkpoint without slowing the agent's production work. The full reasoning is in human approval for agent posts.

Rule 4: Vary the caption per account

When one post goes to many accounts, use per_channel to give each account its own caption, and where relevant its own first comment. Keep claims and offers fixed, vary the opening, local details, phrasing and call to action.

Why: identical text across many accounts at the same moment is what repetitive content looks like from the outside. Our guide to caption variation per account shows how to do this without drifting off brand.

Rule 5: Stagger the dispatch

Do not send to all accounts in the same second. Shager's stagger_seconds sets a random delay range between accounts, with a default of [30, 90] seconds. For large groups or sensitive clients, widen it.

Why: spreading sends over time is how a real team would publish across many Pages, and it reduces bursts that look automated.

Rule 6: Know each network's hard limits

Some limits are published. Instagram, for example, documents that accounts are limited to 100 API-published posts within a 24-hour moving period. Your agent should never approach limits like this in normal operation; if it does, the plan is wrong. Media also has format constraints. When uploading video for Reels, Shorts or Stories, pass width, height and duration_ms to upload_media_from_url so it can be validated before any post is built.

Why: a post rejected at send time wastes a slot, and repeated failures are noise you do not want on a client account.

Rule 7: Let the platform check before sending

Shager checks each post against the target network's rules before dispatch. The agent should treat a validation error as information: read the error code and message, fix the post, and try again once. If it fails twice, stop and report.

Why: an agent that retries blindly can turn one problem into dozens of failed calls.

Rule 8: Respect the API's own rate limit

The Shager API allows 120 requests per minute per key. A well-designed run uses group targeting and per_channel in a single create_post rather than one call per account, so it rarely comes close.

Why: batching is faster, and it keeps the run inside limits without sleep loops in the agent's logic.

Rule 9: Have a stop plan

Before a large run, know how to halt it. list_posts shows what is scheduled, and the run's label tells you which posts belong to it; cancel_post withdraws each one before its send time. A human can also revoke the key at the agents dashboard, which stops any further calls from that agent.

Why: the time to design the stop button is before you need it.

Rule 10: Keep an audit trail and read it

Every agent call is recorded in the audit log on the agents dashboard. Someone should look at it weekly, not only after an incident.

Why: drift in agent behavior shows up in the log before it shows up in public.

The rulebook as skill text

Here is a condensed version to place in a skill or system prompt:

SAFETY RULES (always apply)
1. Create drafts only unless the instructions explicitly say to schedule
   an approved post.
2. When targeting more than one account, always use per_channel with a
   distinct caption for each account. Never send identical captions.
3. Use stagger_seconds of at least [30, 90]; use [60, 180] for groups
   larger than 20 accounts.
4. For video, always pass width, height and duration_ms on upload.
5. Never state a price, discount, date or claim that is not in the brief.
6. On a validation error, fix and retry once. On a second error, stop and
   report the error code and message.
7. Label every post in a run with the same label so the run can be listed
   and cancelled as a group.
8. Never call schedule_post on a post that has not been approved.

The thresholds in rule 3 are our suggestion, not a network rule. Pick values that fit your clients and keep them consistent.

What does a safe large run look like?

1. whoami to confirm the key's scopes match the task.
2. list_groups and list_channels to resolve exactly which accounts are in scope, and report the count before doing anything else.
3. upload_media_from_url with full dimensions and duration.
4. create_post with group_ids, per_channel, first_comment, stagger_seconds and a run label, as a draft.
5. request_approval, or hand off to a human reviewer.
6. After approval, schedule_post for each approved post.
7. After send time, get_post on a sample to confirm delivery, and report any failures.

Step 2 is the one teams skip and regret. An agent that announces "this run targets 212 accounts in 3 groups" gives a human a chance to say "that is the wrong group" before a single draft exists.

FAQ

Is posting through an agent riskier than posting by hand?

The risk is different, not necessarily higher. An agent repeats errors at scale, while a human makes scattered errors. With scoped keys, draft-first runs and varied captions, an agent run can be more consistent than manual work across many accounts.

What is the safest default for stagger_seconds?

Shager's default is 30 to 90 seconds between accounts. No network publishes an ideal spacing value, so widen it for large groups and judge by results rather than by a rule of thumb.

Can I stop a scheduled run after it starts?

Yes. Posts not yet sent can be withdrawn with cancel_post, and the shared run label makes them easy to identify in list_posts. Revoking the key stops any further calls.

For the background on how platforms treat high-volume posting, read avoiding spam blocks when posting at scale, then copy the rulebook above into your agent's skill before its next run.