Frequency caps for email agents: give every recipient one communication budget

A welcome flow, weekly newsletter, product announcement, and re-engagement campaign may each be reasonable. A subscriber experiencing all four in a short period does not see four carefully separate operating plans. They see one sender repeatedly asking for attention.

Agents can make this coordination problem worse when each optimizes its own goal. One assistant sees a new signup, another a product event, and a third a quiet subscriber. None should independently decide that its message deserves to bypass the others.

Use a shared recipient identity and communication history across the workflows in scope. Avoid merging distinct people just because they share a device or organization. If your policy spans brands or channels, document exactly what is counted and who can change that scope.

A cap needs a window, counted message classes, recipient scope, priority order, and exception policy. “Do not send too often” cannot resolve a race between two campaigns. “At most two marketing messages in a rolling seven-day window” can be evaluated, but the number here is illustrative, not a recommended default for every audience.

Define the event that consumes capacity. Reserving a queued message is different from provider acceptance, delivery, or a click. A practical design may count accepted messages while reserving slots for pending ones. State when reservations expire and how an uncertain provider response is reconciled.

Consent and suppression are prior checks. Someone being below the cap does not make them eligible for marketing. Document separately governed transactional messages without disguising a promotion as a receipt to evade the policy. Your message classification needs a clear owner.

Suppose a resource-delivery welcome email and a general announcement arrive together. Your team may give the requested resource priority. The announcement could wait, but only while it remains relevant. An expired event reminder should not be released tomorrow simply because capacity became available.

• Send: the recipient is currently eligible, capacity exists, and timing rules pass.
• Defer: a future slot is plausible and the message remains useful until its expiry.
• Drop: the message is stale, redundant, or superseded by a higher-priority communication.
• Stop: consent, suppression, unresolved approval, or another hard boundary blocks execution.

Set quiet hours using a reliable time zone or an explicit fallback. Re-check delayed messages before dispatch. A deferral is not a promise that a contact will remain eligible or that the copy will remain accurate.

If two workers read “one slot available” at the same moment, both can pass an ordinary check. The enforcement needs a transactional reservation or equivalent atomic operation against the shared ledger. Give each intended message a durable identity so a retry does not reserve another slot.

Keep the send decision and its evidence linked: recipient identity, message class, rule version, reservation, approval reference, and transport state. A timeout after provider acceptance should not immediately free capacity and start a fresh send. Reconcile the uncertain attempt first.

Release a reservation only according to documented state transitions. If a request is canceled before submission, release may be safe. If acceptance is unknown, treating it as definitely unsent can create duplicate messages. This is a suggested system design, not an implementation claim about every email provider.

A recipient cap asks how often one person hears from you. A provider rate limit asks how much traffic your infrastructure can submit in a period. You need separate controls: a slow send can still over-message a recipient, and a respectful recipient policy can still create a sudden infrastructure burst.

Google’s sender guidelines recommend consistent sending rates, avoiding bursts, and monitoring delivery feedback as volume increases. They do not establish a universal “two messages per week” audience policy. Choose your frequency rule from the subscription promise, message usefulness, preferences, and observed outcomes.

Keep unsubscribe and preference choices easy to use. The cap is a ceiling, not a target. Having unused capacity is not a reason for an agent to manufacture another campaign.

Report messages sent, deferred, expired, dropped, and blocked with clear reasons. Monitor complaints, unsubscribes, useful downstream actions, and queue age. Do not call every skipped send a lost conversion or every open proof that the frequency was welcomed.

Test concurrent workers, repeated triggers, consent changes while queued, reservation expiry, quiet-hour boundaries, and ambiguous transport responses. Include a case where the right outcome is no message. Give operators a way to inspect why a recipient was skipped without granting an agent a blanket override.

Begin with one shared policy and a few recognizable message priorities. Review it with the people responsible for lifecycle communication. Then use templates with clear message jobs and bounded agent briefs to make the next send worth the attention it consumes.

• Google: Email sender guidelines. Consistent transport rates, gradual volume changes, and delivery feedback. Recipient frequency policy and the ledger design are our separate editorial recommendations.

Sources checked 2 October 2026. Product behavior and documentation can change, so the linked primary source takes precedence if it differs from this article.