How to manage multiple newsletters with AI agents

Give each newsletter its own key, name the newsletter in every request, and keep one read only key for watching the whole account. An agent that writes for one newsletter then cannot touch another, and what goes out to subscribers still waits for you.

How many newsletters an account can hold

Free has 1 newsletter. The paid plans have 3 on Starter up to 50 on Max. The pricing page lists each plan. A self-hosted server has no limit from FlockStack.

Newsletters share the plan. The emails and the subscribers of the account's plan are drawn on by all of them, so one busy newsletter can use up what the others have left.

How an agent picks a newsletter

Every action that works on one newsletter takes a newsletter input. Leave it out and the action uses the first newsletter you created. For an account with one newsletter that is fine. For several, it is how an issue for one newsletter ends up in another.

Do two things:

• Start the session with list_newsletters, so the agent sees each newsletter's name, slug and number of active contacts.
• Say the newsletter in the request: "In the weekly newsletter, draft...". Put it in the agent's standing instructions too.

The better fix is not to rely on the instruction at all.

Pattern 1: a key for each newsletter

A key can be limited to one newsletter. It reaches nothing of the account's others, its lists show only that newsletter, and anything that reaches the whole account (creating newsletters, domains, billing) is refused. Pair that with a level, a daily cap and an expiry.

Making that key takes a full access key. This is the request from the agent safety guide, with the level changed to send with approval, for a newsletter with the slug weekly:

The key is returned once. An account can have 20 active keys, which is the real ceiling on how many agents you can separate this way.

In Claude Code, add the same server once for each key, under its own name:

Claude Code lists each server's tools under that server's name, so you can tell it which newsletter to work on by naming the server. The Claude Code guide has the first-issue walkthrough. MCP setup has the other clients.

Pattern 2: one read only key for the whole account

A key that is not limited to a newsletter can use get_brand_fleet. It lists every newsletter in the account with its active subscribers, its last sent issue, the messages sent and the bounce and complaint counts over 7 days, its sending brakes and its warm-up. A read only key can call it and change nothing.

Which newsletter has the most bounces or complaints this week? Should I look at any of them before the next send?

The numbers matter because FlockStack acts on them. A campaign pauses past 2% hard bounces or 0.08% complaints, and the account is blocked past 5% or 0.3%. An agent that reads the fleet can warn you before a newsletter gets there.

A paused newsletter can be cleared with resume_newsletter_sending, which first rechecks the 7-day rates and refuses while they are still over a pause level. A send with approval agent has to ask you first. A paused campaign needs resume_campaign as well.

Pattern 3: a brief for each newsletter

get_agent_brief reads one newsletter: its recent issue results, scheduled sends, the next seven planned days, empty calendar slots and backlog. Where evidence is missing, it stays missing. get_best_send_time suggests a weekday and hour from completed sends in the last 90 days. It needs at least three campaigns and 100 sends in a slot, and answers insufficient_data otherwise. It never schedules anything: a time you pick goes to schedule_campaign, which asks you.

This is the part worth giving to an agent for each newsletter, on a drafts key: read the brief, propose three subjects, write the draft, run check_campaign. You send it yourself from the dashboard, and there is nothing to approve. The agent safety guide calls this the drafting assistant.

Starting a new newsletter from a brief

bootstrap_newsletter builds a newsletter from a private brand brief: an archive that is switched off, the welcome and link page, a signup form with confirmed opt-in, an editorial batch and four issue drafts that are not sent. It sends, schedules and publishes nothing. An externalId lets it resume safely after a partial failure, and it is limited to 20 calls an hour.

Two limits to plan around. It needs a full access key, and a new newsletter still counts against the plan's newsletter limit: one more answers conflict. Make a short-lived key for the job, and switch on Ask me before an agent sends for the new newsletter before anyone uses it.

What still waits for you

With several newsletters and several agents, the Approvals page is the one place you decide. It lists every request from every key and app, with the subject, who it goes to, how many and the exact input, and each request records its newsletter.

• A send with approval key's sends, schedules and deletes wait, and so do imports of more than 25 contacts in a call and more than 100 changed in a day.
• A key can have at most 10 requests waiting, an account at most 50, and each expires after 24 hours. With many agents, the account limit is the one you reach first.
• Ask me before an agent sends is a switch for each newsletter, on the Approvals page. With it on, sends and deletes by any key or connected app wait for you, full access included. Only you can turn it on or off, in the dashboard.
• The activity log shows what each key did, in which newsletter and how it ended, including calls that were refused. It keeps 90 days.

What goes wrong, and the limits

• The wrong newsletter. A call without newsletter goes to the first one. A key limited to one newsletter removes the risk.
• A shared plan. Newsletters draw on one plan's emails and subscribers. An agent that sends a big issue on one can leave the others short.
• Fleet tools need an account key. A key limited to one newsletter cannot call get_brand_fleet. That is the price of the isolation.
• Bulk domain setup is not yours to configure. onboard_brand_domains adds up to 10 domains at once, but only domains that the server's operator has assigned to your account. It is limited to 3 calls an hour.
• Rate limits. Each key gets 300 requests a minute across REST and MCP. More keys do not raise an account's per-action limits.

To drive these actions from a program instead of an assistant, use the newsletter API and its reference: MCP or API says when each fits. The MCP server page lists what an assistant can do.