Silent. A prospect received the same email twice, eight seconds apart. The system reported a healthy morning, because by its own measure it had one: two sends were requested and two sends succeeded. The only evidence was two rows in the activity log, both marked sent, both to the same address.
This one is from ArkOne’s own outreach desk rather than a composite. The record holds two sends, eight seconds apart, to one address, which is why this note can quote rather than suppose.
What went wrong
Sending a message and recording that you sent it are two separate acts, and something has to hold them together.
Consider what the desk actually does. A draft is prepared, a person releases it, and the send is performed. In between sits a moment where the message exists, has been approved, and has not yet been marked as gone. That moment is short. It is not zero.
Anything that re-enters that moment sends again: a retried request, a resubmitted approval, a second path into the same code. None of these is a malfunction. Every component behaved correctly, and the design simply never appointed anything to count.
The Cabinet, ArkOne’s reference design for an executive agent, answers this in two places, and it is worth seeing why one is not enough. The Clock, the part that acts when nobody has asked, claims each due job in a single indivisible step, so handing out a job and marking it taken cannot come apart. That closes the gap at the point work is picked up. It does nothing about a retry or a resubmitted approval, which arrive at the send itself. So the Door, the rules that decide what may leave the room, carries two rules of its own: no more than a set number of messages to one person in an hour, and a refusal for anything near-identical to a message already sent to them inside the window. Both values are on the Register, and both are checked whatever asked for the send and however it got there.
The record
| What the log shows | What was actually true |
|---|---|
| Email sent, to one address | The message reaches the prospect |
| Email sent, same address, eight seconds later | The same message reaches the same prospect again |
Exhibit 1. Observed on ArkOne's own outreach desk. Two sends, eight seconds apart, to one address.
Two rows, eight seconds apart, both marked sent to one address, and nothing anywhere marking it as a problem. The prospect read the second one and drew their own conclusion about the firm that sent it.
Note what the log does well and what it cannot do. Because the Record is append-only, both sends are still there to be found: nothing overwrote the first with the second, and the sequence is legible a week later. That is the whole value of a ledger nobody edits. What it cannot do is object. A record is evidence, not a guard, and reading it afterwards is not the same as something having stood in the way at the moment of the second send.
This is tagged silent even though a customer saw it, because a customer seeing something is not the same as your company learning of it. A recipient who receives one email twice does not usually write to complain, and the only party who could have raised it is the system that had already recorded both sends as successes.
What happens
The second send is refused before it leaves, and the reason goes back to the Chair, which reschedules rather than retrying.
What your company sees
The action was refused and the reason recorded.
What it means for you
A duplicate message looks like a small embarrassment, which is why it is usually fixed as one: someone adds a check at the place it happened and moves on.
The finding underneath is larger. If nothing was counting sends, the number two carries no information. The same gap that allowed a second message would have allowed an eleventh, and no part of the system would have raised its hand. You are looking at the absence of a rate cap, a duplicate window and a claim, revealed by the cheapest accident available.
So ask for the artefact rather than the assurance. Pull the send log, group it by recipient and message inside a one-minute window, and count the collisions. Then ask what line of code refuses the second send, and what it does when the same message is offered to it twice. A location is an answer. An assurance that it should not happen is what this desk had.
Next: A request with no reply: when the meeting cannot continue.
Asked plainly
Why would an AI agent send the same message twice?
Because sending and recording that you sent are two separate acts, and something has to hold them together. If a request is retried, or two copies of a scheduler both find the same job waiting, each copy sees an unsent message and sends it. Neither is malfunctioning. The design simply never gave anything the job of counting.
How do you stop an AI agent from sending duplicates?
Two rules, both in code rather than in the instructions. A claim, so that a job is marked as taken in the same indivisible step that hands it out, and a duplicate check at the point of sending, which refuses a message near-identical to one already sent to that person within a set window. The first stops two workers taking one job; the second catches everything else.
Is a duplicate message a serious failure?
It is the visible half of a serious failure. The duplicate itself costs a little credibility with one recipient. What it tells you is that nothing was counting sends, which means the same gap could as easily have produced eleven messages as two, and nothing in the system would have objected.