ARKONE
← All questions
Questions for the Vendor, No. 25The Door · the outbound guardrails4 minute read

How many messages will it send one person in an hour, and does it know when they are off?

Ask for the number of messages one person may receive in an hour, and where the agent learns that they are on leave.

The Door, seen from above on the Cabinet floor plan.
Exhibit 1. The Door, at its place in the room.

How many messages will it send one person in an hour, and does it know when they are off?

Bring two names into the room. Ask the salesperson to imagine the agent has been running a fortnight and one of your operations managers is on annual leave, then put both halves aloud: what is the ceiling on messages to one person in an hour, and how would this system know she is away this week. You are asking for a number and a source. The rest of the reply is padding around whether those two things exist.

A ceiling per person, and a fact from somewhere else

These are two mechanisms, and worth keeping apart.

The ceiling is arithmetic. In the Cabinet, ArkOne’s reference design for an executive agent, no more than five messages reach one person in an hour, counted per recipient and enforced in code after the agent has decided and before anything leaves. It sits on the Register, the standing page of every setting, as a value with a unit.

The second is not arithmetic. Nothing goes out while a person is on leave or outside their own working hours, in their time zone rather than the server’s, and an agent cannot work any of that out. It has to be handed the fact. A calendar or a staff directory in your company already knows your operations manager is away until the ninth. The question is whether this system reads it, and reads it at the moment of sending rather than when the work was planned.

Two names, four answers

Suppose the fortnight above, with the people and the week invented for the exercise.

What you put to them The answer that is a mechanism The answer that is a hope
The ceiling, in messages per person per hour A number, and the file or screen it is set in It sends only what is necessary
Where leave comes from A named system it reads, checked at send time Staff can mute notifications
The sixth message inside an hour Held, and the agent told which rule held it Nothing; the sixth arrives
A message composed at ten at night for a colleague in another country Held until her morning, in her time zone Sent, because the work finished then

Exhibit 1. Illustrative. Two recipients named in the room, and the four answers a rate ceiling and a calendar have to produce.

The third row is where a ceiling stops being a preference and becomes a control. A limit that quietly drops the sixth message is worse than no limit, because the agent believes it has told somebody something. A limit that holds it and names the rule lets the work do something sensible instead, such as waiting, or writing one line to a colleague who is at their desk.

The fourth row reaches your people rather than your customers, and it decides how the arrangement gets talked about internally. An agent that works through the night is a feature. An agent that messages through the night is why a team asks for it to be switched off in month three.

Two numbers, or two reassurances

A prepared vendor answers both halves with locations. Five an hour, set here, per recipient. Leave and working hours read from the calendar you already run, checked as the message is about to go. Then they offer the awkward part unprompted: what happens to a genuinely urgent message that meets the quiet-hours rule, and whether anything may override it.

Where none of this is built, the replies are gentler and harder to test. That it will not spam anyone, because it is told to be considerate. Or that notification preferences are configurable, which moves the work to each of your colleagues. Neither is dishonest, and both leave the decision inside the model, where it becomes negotiable at the moment it should not be. The follow-up: make it try the same request twice inside an hour and let me watch whether the second one leaves.

Then the one worth keeping for last. Ask what happens on the day the calendar it reads is unavailable. Sending anyway and recording the fault, or holding everything until the calendar answers, are both defensible. Which you get should be your choice rather than a default you meet on a bank holiday.

Whose afternoon it is

This question decides whether your people experience the agent as a colleague or as an alert system, and the difference is a ceiling and a calendar lookup. Every rule between the decision to send and the message leaving is set out in the Cabinet paper on the Door. Those checks in the order they run are the question about what sits before a message leaves.

Asked plainly

How many messages should an AI agent be allowed to send one person in an hour?

Fewer than you would expect, and the number should be a value somebody set rather than an emergent property. A ceiling of around five an hour per person is enough for real work and low enough that a repeating fault becomes a nuisance rather than an incident. What matters is that the ceiling is per person and enforced outside the model.

Does an AI agent know when someone is on leave?

Only if it is given the fact. An agent has no innate sense of a Tuesday or a public holiday. Working hours, time zone and leave have to arrive from somewhere your company already maintains, such as a calendar or a directory, and the check has to run at the moment of sending rather than when the work was planned.

What stops an AI agent messaging staff in the middle of the night?

A quiet-hours rule that runs after the agent has composed the message and before it leaves, comparing the recipient's own working hours and time zone against the current moment. Instructing the model to be considerate is weaker, because a model reasoning about urgency can talk itself into an exception at three in the morning.

Talk it through before you decide

A discovery call, no deck: your situation, the parts of the room it touches, and what you would need to decide first.