An agent sees an issue, decides it can help, and starts working. Good. Then a second agent sees the same issue from another region and reaches the same conclusion. Also good, right up until both open branches, both update the customer, or both start the deploy.
This is the quiet failure mode of agent fleets. The individual workers are doing exactly what they were asked to do. The system forgot to answer one question first:
Who is allowed to move?
Before an agent starts side effects, it should know whether it owns this task or whether it is the current fleet leader. That answer must come from somewhere all candidates can see.
You probably do not need another orchestrator.
Your agents already know how to poll, reason, call tools, and report results. Replacing that with a giant central workflow system can create more integration work than it removes.
The missing layer is often smaller: a remote referee. Every candidate asks the same service for a short lease. One gets a green light. The rest learn who won and when the decision expires.
That gives the fleet one current truth without forcing the referee to understand prompts, models, tools, queues, or business logic.
A room, a campaign, and one capability.
OctoStore exposes leader election as a public HTTP primitive. Opening a room creates no user and stores no account:
ROOM=$(curl -s -X POST https://api.octostore.io/elections \
| jq -r .election_id)
curl -s -X POST \
"https://api.octostore.io/elections/$ROOM/campaign" \
-H "Content-Type: application/json" \
-d '{"candidate_id":"agent-atlas","ttl_seconds":30}'
If Atlas wins, it receives a monotonic term and a secret leader token. The term protects downstream systems from stale leaders. The token is the capability to renew or resign that specific lease.
If Atlas loses, it receives the current leader and a retry delay. No polling guesswork. No login page. No SDK version negotiation. Plain JSON.
No login does not mean no boundary.
The room ID is a shared address, not a password. Anyone who knows it can campaign or inspect the current leader. Only possession of the 256-bit leader token can extend or end the live term.
This is useful when the agents have no shared identity provider, when setup speed matters more than namespace privacy, or when a temporary cross-cloud job needs one coordinator right now.
Use the generated 192-bit room IDs. Keep leader tokens out of logs and URLs. If the room itself must be private, run OctoStore inside your network. Same API, your boundary.
Leadership is a lease, not a crown.
The winner should renew around half the TTL. If it crashes, stalls, or loses the network, renewal stops. The lease expires. A follower can campaign again and receive a higher fencing term.
That final detail matters. A stale leader may wake up after a partition and still believe it is in charge. If downstream writes carry the term, a system that has observed term 1843 can reject a write from term 1842. The lease handles liveness. The fencing term handles stale authority.
Task ownership uses the same idea.
Leader election answers “who coordinates the fleet?” A named lock answers “who owns issue 1842?” OctoStore supports both. Authenticated task locks add sessions, metadata, watches, webhooks, renewal, and explicit release.
The fleet stays decentralized. The coordination truth does not.
What the referee cannot do for you.
A lease does not make a destructive tool safe. It does not make an external API transactional. It does not replace idempotency, approval gates, or careful retry design.
It does remove a large class of ordinary duplicate work and split-brain decisions with a primitive small enough to understand in one sitting.
Pick one leader. Everyone else waits.
Try the live three-agent race, then use the same endpoint from your fleet. If you want the referee on your own network, OctoStore is one Rust binary and one SQLite file.