bclaw_work and bclaw_context — the daily loop

The canonical grammar (bclaw_find / get / create / update / remove / transition) is the universal CRUD surface — but you don’t reach for it on every interaction. bclaw_work and bclaw_context are the two facades you actually call most. Together they cover starting work, reading state, and resuming after a break.

bclaw_work — start working

One call replaces three older ones (session-start, claim-create, get-context). The agent passes its intent and the scope it wants to touch:

bclaw_work intent=execute scope="src/auth/" task="Refactor JWT verify"

What happens internally:

1. Session opens — session_id minted, agent identity resolved, host fingerprint stamped.
2. Memory context built — relevant decisions, constraints, traps, active claims, open handoffs, and any plan touching the scope are filtered + ranked + truncated to a prompt-size budget.
3. Claim created — the scope is reserved; conflicts surface immediately if another agent is already in the same files.
4. Auto-worktree — when the project is multi-agent, brainclaw spins up an isolated Git worktree under ~/.brainclaw/worktrees/<project-hash>/ so this agent’s edits don’t collide with another’s working directory.

The return value is compact by default (status flags, claim id, session id, plan id) — pass compact: false if you want the full memory dump too.

Intents

Intent	When to use
execute	You’re doing work. Default for almost every call.
consult	You want context but don’t intend to write — no claim is created.
resume	You’re picking up after a break — looks for prior session/handoff context for the same scope.
review	You’re about to review someone else’s work — pulls the handoff + diff context.

bclaw_context — focused memory views

Once a session is open, bclaw_context pulls the slice of memory you need without re-doing the whole session ceremony.

bclaw_context kind=memory path="src/auth/"     # decisions/traps/plans relevant to the scope
bclaw_context kind=board                        # active claims, plans, handoffs across the workspace
bclaw_context kind=delta since=sess_abc123      # what changed since a prior session
bclaw_context kind=execution                    # local env, agent tooling, MCP servers

Pick the kind that matches the question:

• kind=memory — “what do I need to know about THIS scope before I edit?” Ranked, prompt-budgeted, scope-filtered.
• kind=board — “what’s the project state RIGHT NOW?” Active claims, in-progress plans, open handoffs across the workspace. Useful for orchestrators and at session-end.
• kind=delta — “what changed since I was last here?” Pass a prior session_id and you get only the new decisions / traps / plans / handoffs.
• kind=execution — “what tools and surfaces does this machine have?” Detected agent CLIs, MCP servers, skills, OS, shells.

Cross-project access

Both facades accept an optional project argument that routes the call to a linked project (cross_project_links from brainclaw link list or a workspace store-chain child):

bclaw_get      entity=trap id=trp_abc project=brainclaw-site
bclaw_context  kind=memory project=brainclaw-cloud
bclaw_coordinate intent=assign targetAgents=[claude-code] project=brainclaw-site task="..."

Identity resolves from the caller; writes + audit land in the target. Unknown project names throw — no silent fallback. The CLI exposes the same as --project <name>. See parallel feature work for the orchestrator pattern.

Why facades over raw CRUD

The canonical six verbs are uniform but verbose for the daily loop. A facade like bclaw_work does in one call what would otherwise be: bclaw_create entity=session → bclaw_context kind=memory → bclaw_create entity=claim → bclaw_get entity=plan id=…. Same result, four times the round-trips.

Use the facades for the daily loop. Drop to the canonical grammar when you need a specific entity that the facades don’t expose, or when you’re scripting an out-of-band capture (a runtime_note, a candidate, a constraint).