What are the three calls before an agent sends a campaign alert?

Create a key that can only send, put a daily ceiling on it, then send. We have not pointed a live Admaxxer alert at those three calls yet. This is the order we will use, written down before the first alert leaves, so we cannot later describe a plan as a result.

Admaxxer already sends operational mail that a person did not compose sentence by sentence. A campaign drifts, a pixel goes quiet, a spend pace breaks a rule someone set, and something has to tell the person who owns the ad account. The something is increasingly a job that decides the condition is true and writes the email. That job is an agent in the only sense that matters here: it chooses the moment, and it can choose the moment again a minute later because the condition is still true.

A person does not do that. A person notices they already sent the note. A job does not, unless something under the job refuses the next copy.

Why the alert does not get our sending key

Our own alerts and any future agent-written alerts are not the same risk, even when the words look similar. A scheduled digest has a person who can stop the schedule. An agent that re-fires because a campaign is still over pacing will send until the condition clears or until something else stops it. If that agent holds the same credential as the rest of our mail, the rest of our mail is the blast radius.

So the agent does not get our key. It gets a key created for that job, named for that job, and scoped so the only thing it can do is send. It cannot edit the ceiling. It cannot mint a second key. It cannot change a domain. The ceiling is the blast radius, not a billing feature. We have not picked the number. A daily count is the period we want for an alert, because a runaway that waits until next month has already done the damage. A per-minute rate sits beside the daily count so a tight loop cannot spend the whole day in sixty seconds.

When the ceiling is spent, the send is refused. Nothing queues behind the refusal. Nothing in the agent's own requests can raise the number. Raising it is a person's decision. The refusal says a retry will not succeed, which matters because the agent that hit the ceiling is the one most likely to retry.

The three calls

They are the whole setup. Everything else is what we do when one of them answers no.

First, create the key with permission to send and nothing else. We keep the credential that created it. The agent never sees that credential. If the agent can create keys, the ceiling is theatre.

Second, set the ceiling on that key: a count per period, and a rate per minute. Send only the fields we mean to change. Read the ceiling back before the key is placed anywhere the agent can reach. A key that leaves our hands with no ceiling is the failure this order exists to prevent.

Third, the agent sends, and only the agent sends, with the key from the first call. The message is one alert to the people on that account who asked to hear about it. It is not a list of people who never asked. We are not building a path for that, and we will not point this key at one.

The interesting behaviour is not the third call when it works. It is the fourth identical alert inside 60 minutes. That is the published line for the loop guard. The send is held for a person instead of delivered. The agent is told the send is waiting, and told which call a person uses to release it. If our detector is still right, a person lets the one held copy go and then fixes the loop. If our detector is wrong, the held copy is the bug report.

A person can also stop the key, or every key on the account, with one request. Only a person turns that stop off. We want that for the hour when an alert job is wrong in a way the ceiling has not caught yet, because the emails are different enough to miss the loop and few enough to miss the daily count.

What the ceiling will not fix

AgentiSend is built by the same team as Admaxxer, so treat this as how we are wiring our own alerts, not as a recommendation to anyone else. The product is live, it has customers, and real sending has been on since 6 September 2026. Our campaign alerts have not moved onto it. We have no count of refused alerts to publish, because the count is zero for the boring reason that we have not sent any.

The honest negative is the one we would be tempted to skip. A daily ceiling on an alert key does not make the alert true. If the detector is wrong, the ceiling only limits how many wrong emails go out before a person notices. The held copy helps only if someone reads it. A queue nobody opens is a delay, not a control. For the first month after we do turn a live alert onto this key, a person will read the held rows. We are not automating that read.

The three calls, and the refusal each one can return, are on the guardrails page. The product is at agentisend.com.