
The day you let an agent write to a customer, you decide something you may not notice deciding. A message will go out that nobody in your company wrote, and the customer will read it first. The question worth your attention is what stands between its decision to send and the message leaving, and whether the agent writes well hardly bears on it.
Six rules stand there, run in code, after the Chair, the one voice that speaks for the room, has decided to send and before anything leaves. They are called the Door, one of the eleven parts of the Cabinet, ArkOne’s reference design for an executive agent. The whole of it fits in a sentence: the Door decides what may leave, to whom and when, and when it says no it says why.
Six rules, in the order they run
The fourth paper set apart the kind of tool that acts on the world outside: the sent email, the posted message, the moved money. Every tool of that kind passes through the Door, checked against rules a person wrote down, each with a value on the Register, the standing page of every setting in the design.
The first rule is the audience. A message may go only to a person the room knows: one entry in the Directory, the roster of real people the Cabinet may address, which the twentieth paper takes up. Never a group, never a list, never an address the model composed. What stops the agent texting your whole company is that your whole company is not an address it can form.
The second is quiet hours: nothing is sent while a person is on leave or outside their working hours, in their time zone rather than the server’s. The third is the rate cap, no more than five messages to one person in an hour.
The fourth is the duplicate rule: a message near-identical to one already sent to the same person in the past six hours is refused. The room may reach a conclusion twice; it may not say it twice.
The fifth is the reason returned. When any rule refuses, the Chair is told which and why, so it can reschedule or rephrase rather than retry blind, the habit the third paper described for a tool that does not exist. The sixth decides what happens when the deciding machinery itself breaks, and its argument comes after the exhibit.
One reply, a signature and six rules
Suppose the renewal that runs through this programme, its figures invented for the exercise. The Chair’s reply, holding the list price and offering the volume tier, left at ten past ten on a Tuesday. Forty minutes later the buyer copies a colleague and asks whether anyone has looked at it. The Chair reaches the same position and drafts a reply to both. Every Seat, one of the room’s specialists, ships at propose and wait, so a Signature, the step where a run stops until a person answers, took those words before the Door saw them.
| Step | The check | The answer |
|---|---|---|
| Signature | Has a person approved this reply? | Yes: the Seat proposes and waits; the account owner approved the words |
| Audience | Is every recipient a person on the roster? | Yes: the buyer, and the colleague who was copied is on it too |
| Quiet hours | Are they at work? | Yes, late morning their time |
| Rate cap | How many this hour? | One, forty minutes ago; well under five |
| Duplicate | Said to this person in the past six hours? | Yes, near-identical to the reply of ten past ten. Refused |
| Reason returned | What is the Chair told? | The duplicate rule refused it; the earlier reply named; the window stated |
| Fail-open | Did the Door itself fail? | No; the rules answered, so this one was never reached |
Exhibit 2. Illustrative. One approved reply meets the Door's six rules in order; the duplicate rule refuses it, and the reason goes back to the Chair.
Told why, the Chair does not retry. It writes one line to the colleague alone saying the morning’s reply stands, and that passes. The client’s side saw one position, said once.
Now the last row, and the limit it names. When the Door itself errors, the reference design lets the message through and writes the fault down, which means that for a moment an unchecked message can leave. The reasoning is what each failure looks like from your chair. A Door that fails closed makes an outage look like a quiet day, and the client who wrote on Tuesday hears nothing until Thursday. A Door that fails open leaves an entry in the Record, the ledger of every action and its reason, naming what went out unchecked. An unchecked message is the failure you can see; an unsent one is the failure you cannot.
That judgement holds for messages and fails for money. A payment that went out while the guard was down cannot be apologised for, so the Register carries a second setting beside the first: a buyer may set the Door to refuse rather than allow for a named class of tools, payments and filings among them, everything else staying allowed and logged. Put a Signature in front of those same tools, and a broken guard is never the last thing between the model and the bank.
Fifteen is the cap on the Register, not a target. Press run and count them.
A meeting has not been run yet. Press run to watch one count, fan out to the specialists, come back, and stop.
What this arms you to ask
Ask what sits between the model deciding to message someone and the message leaving.
A good answer is a list: each item with a value, a place where it runs, and what the model is told when it refuses. The thinner answer locates the limit inside the model: the agent is instructed not to send too much, the limits are configurable. Two questions separate a list from an instruction. How many messages will it send one person in an hour, and does it know when they are off? Then make it try the same request twice inside an hour, and watch whether the second one leaves.
Keep one for the end. When the guard itself breaks, does it allow or refuse, who chose that, and may I choose differently for payments?
Next paper: The step that waits for a person, and the ledger that never blocks the meeting.
Asked plainly
What stops an AI agent from sending too many messages?
In the reference design, a set of rules that run in code after the model has decided to send and before anything leaves: the recipient must be a known person, they must be at work, no more than five messages may reach one person in an hour, and a message near-identical to one sent in the past six hours is refused. The model cannot argue with these rules, because it never sees them run; it is told the result.
Does an AI agent know when someone is on leave?
Only if the surrounding code checks. The reference design keeps a roster of the people it may address, with their working hours and leave, and holds any message for a person who is away or outside their hours until they are back. A model instructed to be considerate has no way to know the hour in someone else's time zone; a rule that reads the roster does.
What happens when an AI agent's safety check fails?
It depends on a design choice the buyer should know. The reference design lets the message through and writes the fault down, on the reasoning that a guard which blocks everything when it breaks makes an outage look like a quiet day. That is the default, and it is a default a buyer may change: the design lets a company set a named class of tools, such as payments and regulatory filings, to refuse rather than allow when the guard itself errors, and to place a human approval step in front of the same tools.
Ask the vendor
The questions this part arms, each with the good answer and the answer that arrives instead.
