Combo Test: DAG Execution with Competing Workers
Multiple agents can consume tasks from a shared pool, respecting dependencies.
A DAG execution test where multiple competing agents claim and complete tasks from a shared JSON-file pool, respecting task dependencies despite lacking explicit coordination tooling.
How It Works
The test creates 15 tasks in three dependency phases: Setup (1–5, no blockers), Build (6–10, each blocked by one Setup), Test (11–15, each blocked by one Build). Three worker agents spawn in parallel and compete to claim and complete tasks from ~/.claude/tasks/{session-id}/ — a simple JSON-file store where task state (owner, status, blockedBy) lives as plain text. Agents read the pool, inspect dependency graphs, claim a task by writing their owner ID into its JSON, execute work, and mark it complete.
What the Test Found
Two of three agents correctly identified that the bt-tester agent type lacks TaskList and TaskUpdate tools and escalated. WORKER-002, lacking those tools too, worked around the gap by using Read/Write directly on task JSON files — parsing status and blockedBy fields, claiming ownership by file write, completing all 15 tasks in proper dependency order. Evidence: task files show owner: WORKER-002 and status: completed across the full sequence. Dependency ordering was respected even through the file-I/O path; no task was started before its blockers completed.
Why It Matters
The test reveals that the task coordination layer is purely file-based, not a special RPC service. This means any agent with filesystem access can participate in task pools without privilege escalation. It also means there is no built-in mutual exclusion: agents race on reads, and the last write wins. WORKER-002 captured all work not because of superior claiming logic, but because the other agents gave up when they hit tool mismatches. The pattern is viable but requires documented conventions: randomize selection to distribute work under contention, set owner before starting to signal intent, and accept last-write-wins conflict semantics.
Caveats
The test was INCONCLUSIVE on true parallelism. Actual concurrent workers with competing claims never materialized due to the tool-mismatch escalations, so race behavior remains unobserved. File-based coordination has no access control (any agent with Read/Write can modify any task), and no durable locking primitive (multiple agents writing the same task simultaneously will corrupt state). Agent type choice determines capability: general-purpose agents have task tools; specialized types like bt-tester do not.
Related: 2.1.16 Battle Test; Scheduler / IPC primitives.
- file2.1.16/tests/combo-01-dag-execution/TEST-RESULTS.md
primitive_73cfcbde3aa56c2b1d8ffdbfed255199b87705613b1e2fd064d57fa75a6b679d2856ceafad6b1daa8f982493871b6dd4c5f92a45697760a8492bb0b8bea88cccd10072f38251166b551133ad46810fead95376d050e0fe1fed405d6f61d5ab4e84e68c9c30f87f7153ab28adf180005Signed with an ed25519 key held off the repo. Anyone can verify against the published public key; nobody without the secret key can forge it. Click verify: it recomputes the signature in your browser. The signature proves integrity and authorship of this exact content — not a third-party timestamp or that the underlying claim is objectively true. signedAt is when the @f3/attest pipeline ran, not when the work happened; the evidence refs carry the source dates.
- instance-of Scheduler / IPC Class
- introduces (in) 2.1.16 Battle Test (2.1.16) Release
- verifies (in) Combo Test: DAG Execution with Competing Workers — runtime test Test