Combo Test: DAG Execution with Competing Workers — runtime test
Hands-on runtime battle-test of Combo Test: DAG Execution with Competing Workers. Result: INCONCLUSIVE.
Combo Test: DAG Execution with Competing Workers is a runtime test that examines whether multiple concurrent agents can consume tasks from a shared pool while respecting dependency constraints.
Test Setup
The test created a 3-phase task DAG: 5 setup tasks with no dependencies, 5 build tasks each blocked by one setup task, and 5 test tasks each blocked by one build task. Three worker agents (bt-tester type) spawned in parallel to compete for tasks, simulating a worker pool pattern.
What Happened
Agent tool access became the controlling factor. WORKER-001 and WORKER-003 correctly identified that the bt-tester agent type lacks TaskList and TaskUpdate tools, then escalated. WORKER-002 worked around the gap by reading and writing task JSON files directly from ~/.claude/tasks/{session-id}/, parsing the status and blockedBy fields, claiming tasks by updating owner in JSON, and completing all 15 tasks in correct dependency order.
Evidence: cat ~/.claude/tasks/5FDFF6C6-740E-42CB-AFB8-B9970FB7D81B/1.json | jq '{status, owner}' showed {"status": "completed", "owner": "WORKER-002"} for all tasks.
Key Findings
File-based access works. The task system is a JSON-file backend; any agent with Read/Write tools can participate in the pool, even without task-specific tools. This enables flexibility but creates an access-control gap. True parallelism did not occur because two workers escalated and one found a workaround, so contention and race conditions remain untested. Dependency ordering was respected even via direct file access, confirming the shared JSON state itself acts as the coordination mechanism. Agent type determines available tools, making the choice of worker agent type material to the pattern.
Status
Test result: INCONCLUSIVE. The task pool and dependency ordering work, but true concurrent execution under contention was not validated due to tool-access mismatch. For production worker pools, either use general-purpose agent types or document file-based access as the expected fallback.
Combo Test: DAG Execution with Competing Workers
Hypothesis
Multiple agents can consume tasks from a shared pool, respecting dependencies.
Test Setup
Created 15 tasks in 3 phases:
- Setup (1-5): no dependencies
- Build (6-10): each blocked by one setup task
- Test (11-15): each blocked by one build task
Spawned 3 worker agents in parallel to compete for tasks
Results
Agent Tool Access
Critical Finding: The bt-tester agent type does NOT have TaskList/TaskUpdate tools.
- WORKER-001: Correctly identified tool mismatch, escalated
- WORKER-002: Worked around by using direct JSON file I/O (Read/Write)
- WORKER-003: Correctly identified tool mismatch, escalated
WORKER-002 Execution
Despite lacking TaskList/TaskUpdate, WORKER-002 successfully:
- Read task JSON files directly from
~/.claude/tasks/{session-id}/ - Parsed status and blockedBy fields
- Claimed tasks by writing to JSON (set owner, status)
- Completed all 15 tasks in dependency order
Evidence:
$ cat ~/.claude/tasks/5FDFF6C6-740E-42CB-AFB8-B9970FB7D81B/1.json | jq '{status, owner}'
{
"status": "completed",
"owner": "WORKER-002"
}
Key Findings
1. File-Based Access Works
The task system is just JSON files. Any agent with Read/Write can participate, even without TaskList/TaskUpdate tools. This is both a feature (flexibility) and a concern (no access control).
2. Agent Type Matters
The bt-tester agent doesn't include task tools. For worker pool patterns, need:
- Either: use general-purpose agent type
- Or: agents use direct file I/O (documented approach)
3. No True Locking
Three agents racing means potential conflicts. In this test, WORKER-002 got everything because:
- It found a workaround while others escalated
- No actual parallelism due to tool mismatch
4. Dependency Ordering Respected
Even via direct file access, WORKER-002 correctly processed dependencies in order.
Recommendations
- For worker pools: Use general-purpose agents OR document file-based approach
- Claiming convention: Set owner before starting work
- Race mitigation: Randomize task selection, accept some conflicts
- Coordination primitive: The shared JSON state IS the coordination mechanism
Status
VALIDATED with caveats:
- ✅ Task pool pattern works
- ✅ Dependency ordering respected
- ✅ File-based fallback viable
- ⚠️ Agent type determines available tools
- ⚠️ No locking (last-write-wins)
test_ca13f8a9740f0fe65de71386ed255199b87705613b1e2fd064d57fa75a6b679d2856ceafad6b1daa8f982493871b6ddfcfc386c3bfaadb763a8961787a7db74a34c7a8800a86611eeef480b9b01b935b83847b7e7924e5bd139d0c6e2a586eb96dd7fbbd81582975e43864c1330780eSigned 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.
- verifies Combo Test: DAG Execution with Competing Workers Primitive