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. That is the whole setup for an agent that writes campaign alerts through AgentiSend, and this is the order we recommend.

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

A scheduled report and an agent-written alert 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. Pick the number from how many alerts the account could plausibly need in a day. A daily count is the right period 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

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 of any new alert, have a person read the held rows. Do not automate that read.

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