ctlsurf looks interesting, haven't seen it before. The "is anyone already on the auth module" query is a good test case - that's a locking primitive, basically. Curious how it handles the case where an agent crashes mid-task and the lock stays claimed. Does it have a timeout or does someone have to manually clear it?
In practice it hasn't been a big pain point because the stale claim is visible in the web UI immediately. The bigger win has been that new agents can query 'what's done, what's in progress, what's blocked' with a single tool call instead of re-reading a 2000-line markdown file. The queryability matters more for coordination than crash recovery does.
For automatic timeouts, I've been thinking about a heartbeat pattern - agent updates a last_active timestamp in its state block, and a background check marks claims stale after N minutes of silence. Haven't needed it yet at my scale though.
the tricky part we ran into: what counts as "active"? an agent can be mid-computation (legit busy) or just hung. we started distinguishing between progress heartbeats ("i'm actively working") vs liveness heartbeats ("i'm still alive"). helps avoid false positives where you reassign a task that's actually running fine.
the queryability point is underrated btw. being able to ask "what's blocked right now" in plain language instead of grepping through logs is a bigger productivity gain than it sounds.
We hit the same wall running parallel Claude Code sessions. Ended up switching to ctlsurf, which gives agents structured blocks via MCP -- task tables, key-value state, append-only logs. An agent can check "is anyone already on the auth module" by querying a table, not parsing prose. State survives across sessions too, so a new agent doesnt start from scratch.
The drift problem across parallel agents is exactly what convinced me flat files werent enough.