CREW TASKS · ONE OWNER
Crew-style task assignment: name one owner before work starts
Post six tasks to a crew of agents and count customer emails: broadcast and racing claims send duplicates, a crash without a lease strands work.
Your experiment
Six support tasks arrive eight seconds apart, and each ends with one email to a customer. Two agents can do the role and every task is broadcast to both, so every customer gets two emails. Switch to racing claims, add compare-and-set, name an owner up front, then crash T4’s owner before and after its email.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Deterministic crew, not CrewAI: each task takes 6 s; racing agents poll every 2 s at fixed offsets (B 0.6 s after A, C 1.4 s after A) and a claim becomes visible to others 1 s after it is made; a crashed task waits for its lease to expire before it is re-run. No model, queue or email service is called.
Who owns a task with a side effect
Six tasks, T1 to T6, are posted eight seconds apart; each takes six seconds of agent work and ends by emailing a customer. Assignment decides how a task reaches the crew: broadcast to every agent that can do the role, a race in which agents claim tasks from a shared board, or a manager who names one owner before work starts. Agents that can do the role sets how many candidates there are, and Email tool deduplicates on task id decides whether a repeated send for the same task reaches the customer.
The opening run: every customer emailed twice
With broadcast and two capable agents, A and B both work every task: 12 emails for 6 tasks, 6 duplicates, and 72 agent-seconds spent on 36 seconds of real work. With three agents it is 12 duplicates. Tick Email tool deduplicates on task id and no customer sees a duplicate, but the verdict is DEDUPED, NOT OWNED: both agents still did the work, and a side effect without a dedup key, such as a payment at a provider that does not support one, would still happen twice.
Racing claims and compare-and-set
Set Assignment to Agents race to claim from a board. B polls 0.6 s after A, and a claim takes 1 s to become visible, so B claims every task A has just claimed: 6 duplicates again. Tick Compare-and-set claims on the board: the second claim fails because the task is no longer open, each task has one owner and work drops to 36 agent-seconds. Choosing Manager names one owner up front gives the same result without a race, and with a single capable agent there is nothing to race.
Failure boundary: crashes, leases and repeats
With a manager, set Owner of T4 crashes to Before sending its email: the 10-second Lease before reassignment expires at 41 s and T4 is re-run, done once. Set the lease to 0 s and T4 stays claimed by a dead agent forever: 1 unfinished task. Set the crash to After sending, before marking done: the lease returns T4 to the board and the re-run emails the customer a second time. Only the lease and the dedup key together make T4 both finished and sent once.
Reading the run and its limits
Play replays each task’s posting, owners, sends and delivered emails over sixty inspection seconds; the table lists owners, send requests and emails per task. Next event, Restart, Speed and Inspection time control the replay, and any input change recomputes it. Real crews add retries, timeouts and partial failures, and agent frameworks implement ownership differently; the model isolates the rule that every side-effecting task needs exactly one owner at a time and an idempotent effect.