brainclaw exposes 66+ MCP tools and a canonical grammar across 17 entities , so the moves below work for any MCP-compatible agent.
The pain
Without shared coordination, two agents take the same task in parallel. They both touch the same files. The second agent discovers the conflict at merge time — long after both have spent compute and tokens producing diverging implementations. One side gets discarded.
The pattern repeats whenever a feature spans multiple surfaces (API, frontend, docs, QA, migrations) and you’d like to fan agents out instead of running them serially.
The brainclaw move
- Create a plan for the slice. A single feature lives as one shared plan with sub-steps, owners, and dependencies. Every agent reading the workspace sees it.
- Claim the scope before editing. Each agent calls
bclaw_work(intent='execute', scope=...)before touching a file set. The claim is an advisory lock — overlapping claims surface immediately, not at merge time. - Pull ranked context per step.
bclaw_context(kind='memory')produces a compact, prompt-sized snapshot of the constraints, traps, decisions, and active work that bear on the current scope. Each agent gets a fresh frame, not stale prompt history. - Release with a handoff. When the slice is ready for QA,
bclaw_release_claim(planStatus='done')closes the claim and writes a handoff capturing what was done, what’s pending, and how to verify.
What changes
| Without brainclaw | With brainclaw |
|---|---|
| Two agents discover overlap at merge | Claim conflicts surface before edits |
| Stale prompt history drifts from real state | Live context per step |
| Handoffs depend on commit messages | Structured handoff with pre/post-conditions |
When to skip it
If a feature genuinely fits a single agent in a single sitting, the coordination overhead is just overhead. brainclaw earns its keep when the work is wide enough that fanning out matters — usually when 2+ agents could legitimately work in parallel.