How often should an AI agent email the same person?
Last updated
Nobody can tell you the number, and the reason that matters is that nobody currently knows what the number already is. Three systems and two people can each be sending politely and inside their own limit while the person on the other end gets five things in a week — because no single system can see the other four.
So the first useful thing is not a cap. It is one total, across everything that touches a person, including the work your agents do and the work your people do.
The total nobody has
Every touch ought to count against several things at once, and only one of them is the person:
| counted against | what it tells you |
| the person | where the damage actually lands |
| this deal | the only place where touches genuinely compete, so the only sensible place to enforce |
| the company | the do they think we are disorganised view |
| the group above it | the same, for companies that roll up |
Enforce at the deal, show the company total. Capping at company level starves one region because of activity in another — and the person running that region will be right to complain, which is how a control gets switched off.
Support and service sit outside all of it. Rate-limiting a reply to somebody's problem is absurd.
You set the numbers, on five things
Not one cap, because a first touch into a cold segment and a follow-up on a live deal are not the same act. The dimensions are the motion, the stage the relationship is at, the channel — weighted, because a call costs more of somebody's attention than an email — the seniority of the person, and the segment.
We supply the dimensions and the total. The numbers are yours, because they are a fact about how your business sells and we would only be guessing.
Four numbers that are not yours or ours
These are published by other people, they are not settings, and no configuration overrides them:
- Complaints. Google require bulk senders to stay under 0.10%, with hard failure at 0.30%. That is a circuit breaker, not a budget.
- Bounces. Sustained high bounces damage your sending reputation on their own, independently of complaints. Around 5% is where trouble starts.
- Domain age and ramp. A new domain cannot send what an established one can, whatever your plan says.
- SPF lookups. Ten DNS lookups, and exceeding it fails the whole record — entirely, not partially, with every authorised sender failing at once.
You choose what happens as you approach one: warn, throttle, or stop. You do not choose where the cliff is.
What you get before anything is connected
Two of those four are readable from public DNS with no permission from anybody, which means the SPF and reputation half says something useful on day one. The how many times has this person been contacted half genuinely needs your systems connected, and until they are, the total says so rather than presenting your agents' own traffic as the whole picture.
A total made only of what we can see, presented as the total, is the exact mistake this is for. So it reports what it is missing.
And it says what it would have stopped, not what it might have
Once something is connected, the honest sentence is this many things went out while that person was already past your limit — which is a fact about what happened. Replaying a world where the limit had been on is not available: in that world the first stopped message never goes, so nothing after it is the same.
/agent-promise-register.md is the other half of this — what the agent may say, as opposed to how often. /trust.md is what we hold.