Kevin Kern coordinates parallel coding agents with file ownership

• Parallel workers have a file-level gate: Kevin Kern's integrator checks changed paths before cherry-picking and escalates ownership violations.
• Review and QA use fresh sessions: reviewers inspect the integrated diff, while QA tests the running app without fixing it, according to his role diagram.
• Work leaves the laptop through a shared /machines skill that routes jobs by task and available capacity, as Kern describes in his walkthrough.

Earlier runs included lost drafts and retries that reported success without saving changes, according to the Split Orchestrator README. Users retain approval over pushes, merges to main, deployments and publishing in the plugin's example prompt.

Kern attaches ownership to the checkout, so switching accounts does not change it. His integration policy has three steps:

1. Each Sol worker gets its own clone or worktree, branch and list of owned files.
2. One Sol integrator checks each commit's changed paths against that worker's ownership list before cherry-picking.
3. Any commit touching files outside that list goes to the orchestrator for conflict handling, the design's smartest guardrail.

A linked worktree belongs to the same repository and allows another branch to be checked out simultaneously, as Git's documentation explains. Split Orchestrator's README specifies a local clone with installed dependencies for every implementer, budgeting several gigabytes per worker.

Isolation policies vary. In a separate discussion, @marktenenholtz argued that ten agents in one repository might benefit from just one extra worktree for special separation, and often need none.

Kern credits Opus 5.5 with making nonstop orchestration across multiple projects practical for him, including management of Codex workers. His hierarchy separates six jobs:

• Orchestrator, Opus: planning, scope and decisions with Kern.
• Stream lead, Opus: briefs, handoff checks and final acceptance.
• Worker, Sol: builds its assigned slice.
• Integrator, Sol: merges changes and runs CI suites.
• Reviewer, fresh Opus: reviews the integrated diff; Astra takes this role if Opus built it.
• QA, fresh Sol: tests the running application and fixes nothing.

Workers receive their own prompts and can run in parallel. Farcall returns results to Opus, which can resume the same worker sessions for corrections.

Farcall documents the transport mechanics and their limits:

• Batching: one run_batch call supports 1-5 parallel workers in separate checkouts.
• Waiting: the delegated MCP call remains pending until its result arrives, avoiding the need for parent-side status polling.
• Claude Code configuration: the documented launch sets CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS=0 and MCP_TOOL_TIMEOUT=7200000, a two-hour timeout.
• Scope: an open call does not guarantee the host never polls. Farcall does not control wait loops inside native Codex subagents started by a worker.

Kern keeps his MacBook focused on orchestration. A shared /machines skill supplies connection instructions and dispatch choices based on the task and available capacity.

His working-machine layout assigns different workloads:

• X3: agent workers in micro VMs.
• A8 workspace server: projects, agent sessions and jobs.
• Gaming PC: local AI, Blender and Unity.
• Cloud VM: external builds and end-to-end tests.

Kern counts heavy jobs rather than relying on load average, giving three concurrent builds or test suites as an example cap per machine. Spotlight indexing had raised load average enough to stop work during an earlier experiment; the heaviest work goes to cloud VMs.

Claude's weekly allowance remains a hard dependency. Kern says in a follow-up that exhausting it stops the farm, even though he considers the Sol workers cheap.