# How often should an AI agent email the same person?

**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.