Planning, Subagents, and Background Work.

The question: When do planning, delegation, and background work help rather than create races?

Start from first principles

Adding subagents is like adding cooks to a kitchen. Speed improves only when stations, ingredients, timing, and the head chef's integration step are explicit.

Long tasks fail when one conversation holds every search result, decision, test log, and monitor stream.

Plan mode separates design from approval. Subagents separate context. Worktrees separate repository writers. Background tasks separate process lifetime from a model call.

Those mechanisms create obligations: self-contained delegation, conflict control, result integration, and certainty that no child is still acting when the parent stops.

Build the smallest useful mental model

Use plan mode for decision uncertainty, subagents for bounded reasoning, worktrees for write isolation, and background tasks for long process lifetime.

The child tree stays flat: only the top-level session can spawn. This bounds recursive explosion and keeps ownership visible.

Plan mode is a user-review protocol. Its edit gate has documented shell and child-session boundaries, so it cannot replace capability or OS controls.

Now open the hood

Only after the idea is clear does Mira open the source. She ignores most of the workspace and follows the few boundaries that must exist for this part of the story to work.

1. The next clue — Enter planning for genuine ambiguity

Mira now needs one small mechanism: Agent or user can activate planning when design choices need review.

She follows that responsibility into the repository. The guide documents enter_plan_mode, /plan, state transitions, and exit_plan_mode. The important point is not the Rust syntax. It is ownership: this is where the system decides what crosses the boundary.

Then she tests the unhappy path: Planning trivial changes adds latency and can create false confidence. If the model, operator, and saved session do not receive the same honest outcome, the mechanism is not yet trustworthy.

Source: User guide 19-plan-mode.md. Verified against Grok Build c68e39f60462f28d9be5e683d9cbe2c57b1a5027.

2. The next clue — Persist and review plan.md

Mira now needs one small mechanism: The plan must survive feedback and compaction inside the session.

She follows that responsibility into the repository. Plan mode writes plan.md, opens preview, accepts comments, and preserves active state through compaction. The important point is not the Rust syntax. It is ownership: this is where the system decides what crosses the boundary.

Then she tests the unhappy path: An empty plan can reach approval; UI must make that absence explicit. If the model, operator, and saved session do not receive the same honest outcome, the mechanism is not yet trustworthy.

Source: Plan guide plan-file and approval sections. Verified against Grok Build c68e39f60462f28d9be5e683d9cbe2c57b1a5027.

3. The next clue — Know the edit gate boundary

Mira now needs one small mechanism: Plan-file edits are allowed; other edit-tool calls are rejected in active mode.

She follows that responsibility into the repository. The shell applies the gate before normal execution, independent of permission mode. The important point is not the Rust syntax. It is ownership: this is where the system decides what crosses the boundary.

Then she tests the unhappy path: Shell writes are not inspected and write-capable children use fresh trackers; add capability/sandbox controls. If the model, operator, and saved session do not receive the same honest outcome, the mechanism is not yet trustworthy.

Source: Plan guide lines 126–135 and tool_calls.rs. Verified against Grok Build c68e39f60462f28d9be5e683d9cbe2c57b1a5027.

4. The next clue — Give children independent context

Mira now needs one small mechanism: A child receives a bounded task and separate context, then returns a summary.

She follows that responsibility into the repository. spawn_subagent starts an agent-type/capability-selected child session. The important point is not the Rust syntax. It is ownership: this is where the system decides what crosses the boundary.

Then she tests the unhappy path: Unstated acceptance criteria lead to locally plausible but unusable output. If the model, operator, and saved session do not receive the same honest outcome, the mechanism is not yet trustworthy.

Source: User guide 16-subagents.md. Verified against Grok Build c68e39f60462f28d9be5e683d9cbe2c57b1a5027.

5. The next clue — Separate agent type and persona

Mira now needs one small mechanism: Agent definitions control model/tools; personas add behavioral instructions and IO contracts.

She follows that responsibility into the repository. The guide applies persona overlays during child resolution, not via a direct spawn parameter. The important point is not the Rust syntax. It is ownership: this is where the system decides what crosses the boundary.

Then she tests the unhappy path: Assuming a nonexistent persona parameter leaves intended behavior unapplied. If the model, operator, and saved session do not receive the same honest outcome, the mechanism is not yet trustworthy.

Source: Subagent guide agents-versus-personas. Verified against Grok Build c68e39f60462f28d9be5e683d9cbe2c57b1a5027.

6. The next clue — Filter child capabilities

Mira now needs one small mechanism: Children can be read-only, read-write, execute, or all in addition to type defaults.

She follows that responsibility into the repository. capability_mode is documented; explore/plan are read-oriented and general-purpose is broad. The important point is not the Rust syntax. It is ownership: this is where the system decides what crosses the boundary.

Then she tests the unhappy path: Coarse labels do not isolate credentials or all shell reach. If the model, operator, and saved session do not receive the same honest outcome, the mechanism is not yet trustworthy.

Source: Subagent capability table. Verified against Grok Build c68e39f60462f28d9be5e683d9cbe2c57b1a5027.

7. The next clue — Isolate writers with worktrees

Mira now needs one small mechanism: Overlapping write-capable children should use separate Git trees.

She follows that responsibility into the repository. isolation: worktree returns the child path and is mutually exclusive with cwd. The important point is not the Rust syntax. It is ownership: this is where the system decides what crosses the boundary.

Then she tests the unhappy path: The parent must integrate; worktrees do not isolate external systems. If the model, operator, and saved session do not receive the same honest outcome, the mechanism is not yet trustworthy.

Source: Subagent worktree section. Verified against Grok Build c68e39f60462f28d9be5e683d9cbe2c57b1a5027.

8. The next clue — Manage background lifecycle

Mira now needs one small mechanism: Long commands, monitors, schedulers, and children need IDs plus get/wait/kill.

She follows that responsibility into the repository. The background guide defines task APIs, persistence, volume control, and the tasks pane. The important point is not the Rust syntax. It is ownership: this is where the system decides what crosses the boundary.

Then she tests the unhappy path: High-volume monitors stop; unfinished tasks can outlive the visible answer. If the model, operator, and saved session do not receive the same honest outcome, the mechanism is not yet trustworthy.

Source: User guide 20-background-tasks.md. Verified against Grok Build c68e39f60462f28d9be5e683d9cbe2c57b1a5027.

Mira runs the experiment — research, implement, and test without conflicting writers

Reading source gives her a hypothesis. A small experiment tells her whether that hypothesis survives contact with a real workspace. Decompose a migration into reviewed plan, read-only exploration, isolated implementation, and background verification.

1. Enter plan mode with acceptance criteria.
2. Spawn a read-only explorer for call sites.
3. Review summary and approve plan.
4. Spawn one writer in a worktree.
5. Start tests in that worktree in background.
6. Poll through task output rather than shell sleeps.
7. Review child diff and evidence.
8. Kill leftovers and remove worktree.

Plan the API migration. Delegate call-site discovery to a read-only explore subagent.
After approval, implement in an isolated worktree and run package tests in the background.

What she learns. Natural language lets the agent emit source-defined tool payloads rather than relying on invented internal JSON.

That last check matters. Grok Build can expose a mechanism and report an observation; the repository, operating system, CI platform, and reviewer decide whether those observations prove the actual task succeeded.

The whiteboard test

Before Mira explains the chapter to her team, she reduces it to three questions: what owns the decision, what evidence comes back, and what changes when the mechanism fails?

Review question	Source-backed answer	Operational consequence
Need a decision record?	Plan mode.	Add containment if needed.
Need reasoning isolation?	Read-only child.	Provide full task context.
Need parallel writes?	Worktrees.	Integrate deliberately.
Need long process?	Background task.	Own ID, timeout, cleanup.

This is not a feature scorecard. A mechanism can work exactly as implemented and still be the wrong control for a particular threat. Defaults also change, so recheck the pinned source path before copying configuration into production.

Signals Mira keeps

• Plan transitions, digest, comments, approval identity.
• Child type, model, capability, cwd/worktree, parent, status.
• Task command, ID, volume, polls, completion, kill.
• Which results entered parent context and which stayed as artifacts.

Together, those signals tell a complete story: the model proposed an action, the harness admitted and routed it, the environment performed something, and a verifier measured the result.

Limits and uncertainty

The public repository is unusually detailed, but it is not the complete deployed product. The snapshot has one visible public commit, so it cannot support a rich historical explanation of why every boundary evolved. Hosted xAI model serving, account systems, and production topology remain outside this study. Where code and guide differ, this series gives the pinned implementation priority and marks documentation-only behavior instead of silently merging versions.

FAQ

Can children spawn children?

No. Maximum documented depth is one.

Does a persona change tools?

No. Agent type and capability mode do.

Is plan mode repository read-only?

No. Use capabilities and sandboxing for stronger enforcement.

When should commands be backgrounded?

For long one-shot work; use monitors for streams and schedulers for periodic work.

Can a child resume?

resume_from continues a completed compatible child under documented constraints.

What changed for Mira

Mira designs tasks around ownership, isolation, dependency order, and a single integration point.

Next: Then her laptop crashes, forcing the team to ask what work survives.

Key takeaways

• Planning, delegation, isolation, and backgrounding solve different problems.
• Plan mode is not a complete write sandbox.
• Subagents are independent and flat at one level.
• Worktrees isolate files, not services.
• Every background task needs integration and cleanup.

References & source notes

• Pinned Grok Build repository — default branch snapshot researched July 16, 2026.
• Grok Build README — first-party overview and source-build entry points.
• Subagent guide — capabilities and worktrees.
• Plan guide — planning lifecycle.

Freshness boundary. Grok Build claims in this article are pinned to c68e39f60462f28d9be5e683d9cbe2c57b1a5027. Pi comparison claims, where present, are pinned to 97f9978fa66685f78d2da19ae22e20c46d125f74; Hermes claims are pinned to c9c9bb33fcc6ab479846a1c496a6e9efe2c1c7d4. Recheck paths, symbols, commands, and defaults if those branches advance.