Why: Mutual exclusion alone does not preserve order. With parallel execution the host cannot keep order-sensitive tools (card streaming begin/append/commit, plan updates) correct by locking a mutex, because whichever goroutine grabs the lock first is not necessarily the first declared call - a real failure observed in the backend card-stream test. Evidence: go test ./... green; TestLoopSerialToolsKeepOrder asserts the serial calls execute in declaration order (s1->s2->s3) while parallel calls still fan out. Impact: New Config.SerialTools set. In parallel mode, matching calls run sequentially on the caller goroutine in model-declared order; others stay concurrent. Empty set keeps the previous all-parallel behavior; sequential mode is untouched. Refs: Dev task feature/agent-e1-parallel-fixes (F5).