What happens if two copies of it run at once?
You will ask it after somebody forwards you a client thread with two identical chasers in it, a second apart, both signed by your company. Nobody wrote them twice. Something woke, found a task waiting, and ran it; something else woke at the same instant and found the task still waiting. Ask before that morning rather than after, because the answer separates a rule from an arrangement.
A gap between seeing and taking
The part of an agent that acts unasked is a scheduler, called the Clock in ArkOne’s reference design for an executive agent, the Cabinet. It wakes on an interval, reads a list of jobs, and starts whatever has fallen due; in the reference design it wakes every thirty seconds, a setting on the Register.
The failure lives between two actions. A copy sees a job is due. Then a copy takes it. If those are separate steps, a second copy can look in between, see the job still unclaimed, and run it too. Where the job drafts a document, the waste is money. Where the job sends something, your client receives it twice.
The answer makes seeing and taking one indivisible step, which the Register calls the claim. The second copy finds the job held and does nothing. The reference design also runs a single Clock, though that is housekeeping rather than the guarantee: the claim makes once mean once, and the single instance merely avoids paying two machines to race. The mechanism sits in the paper on the Clock.
The three answers you will hear
Suppose the question is asked in a fortnight of meetings, of vendors with working products and honest sales engineers.
| What a good answer sounds like | What you will be offered instead | What that hides |
|---|---|---|
| Taking the job and marking it taken are one database write, so a second copy finds nothing to take. Here is the line | We only ever run one instance | Today’s deployment, not a rule. A restart that overlaps, or a second region, and the sentence stops being true with no code change |
| We start two on purpose in testing and assert that one message leaves | Our infrastructure handles that automatically | A hosting property nobody on the call can name. Ask which property, and the answer moves to a different team |
| A job that fails halfway is released and retried, and the send is guarded separately | It has retries built in | Retries without a claim are the duplication. The safeguard named is the mechanism causing the fault |
Exhibit 1. Illustrative. Three replies to one question, and what the weakest of them leaves unsaid.
The middle column is not a vendor caught out. Each reply is true on the day it is said, which is what makes it poor protection: none is a statement about the code, and code is the part that survives a change of arrangement.
Read the third row twice, because retries sound like diligence. A job retried after a timeout, with no claim beneath it, does the same thing twice whenever the first attempt was slow rather than dead. What then stands between that second attempt and your client is whatever guards the send, which is the next question on the list.
The follow-up that separates them
Ask this: have you ever started two copies on purpose and watched what happened?
The reply divides cleanly. A team that has done it describes the test rather than the theory, and usually volunteers the result of the first attempt, which was probably two messages. A team that has not will tell you it would not happen. You are buying the difference between a tested rule and a prediction.
Where the answer names a claim, ask what a job does if it dies halfway through, and who notices. Once means at most once, and a scheduler that has stopped fires nothing and complains to nobody, because the part that would raise the alarm is the part that is down. Duplication is loud. Silence costs you a quarter before anyone sees it.
Where the answer is a deployment fact, do not treat it as disqualifying. Treat it as a line item: ask for it in writing, ask what changes when they add a second region, and put the duplicate send into the pilot as a test somebody has to pass. The night before the vendor call sets out how to carry several of these into one meeting.
One answer describes what the software does. The other describes how it is deployed this month. Both are given in good faith, and only one is still accurate the week your vendor moves you to a second region without mentioning it.
component: answer-card
Asked plainly
Why would an AI agent send the same message twice?
Usually because two copies of its scheduler both saw the same job fall due and both ran it. Between seeing a job and taking it there is a gap, and a second copy can reach through that gap. The defence is a claim: taking the job and marking it taken happen in one indivisible step, so the second copy finds the job gone and does nothing.
Is it safe to run more than one copy of an AI agent?
It is safe when the design assumes it will happen. A system whose jobs are claimed in one step tolerates a second copy, which simply loses the race and wastes a little effort. A system that relies on nobody ever starting a second copy is safe only until a deployment overlaps or a restart runs long.
What should I ask a vendor about duplicate actions?
Ask what in the code stops the second copy, and whether they have ever started two on purpose to watch what happens. An answer about their deployment describes today's arrangement. An answer about a claim describes a rule that holds whatever the arrangement becomes.