The Core Operating Model: Isolated Work, Visible State, Deliberate Choice

Orca becomes most intelligible when its worktree and session features are judged together. This checkpoint connects three ideas already established: separate files make parallel attempts comparable, session evidence makes their progress visible, and the developer still decides what the output means. Applying those ideas to a three-agent race gives you a practical test for any Orca workflow: can you tell which attempt changed which files, whether the process evidence is current, and what remains before a human can accept the result?

Three layers, three different questions

Consider the login-race task from the earlier example. Three agents receive the same problem and begin from the same starting point. One proposes a lock, another changes the request lifecycle, and a third concentrates on tests. Orca gives each attempt a separate worktree and branch, then places each agent in a session associated with that workspace. The separation and the visibility are not redundant. They answer different questions.

The worktree answers: where are the changes? Each attempt has its own files and Git history. If the lock-based implementation adds a new synchronization helper, that edit belongs to one directory and branch. If the lifecycle-based implementation changes a request boundary, that change belongs to another. The operator can inspect either without first undoing the other. A branch name alone would identify a line of history, but it would not give two simultaneously running processes two independent directories in which to work.

The session answers: what is the agent doing? A worktree can be clean because its agent has not started, because setup failed, because the agent is waiting for a permission, or because it finished without making an edit. A nonempty diff can belong to a still-working process, a completed turn, or an exited agent. Status signals and terminal context attach process evidence to the right workspace, so the operator can see that one attempt needs an answer while another is ready for inspection.

Human choice answers a third question: which result deserves to move forward? Orca can expose three finished sessions and three diffs, but it cannot infer the project’s real acceptance criteria from the existence of those artifacts. The best patch may combine an idea from one agent with a test discovered by another. All three may be wrong. One may have modified a shared service or copied a local configuration in a way that invalidates the comparison. The human decision is not an interruption to the system; it is the step that converts parallel generation into an accountable engineering action.

The three layers also fail differently. If isolation fails, edits can collide or the diff can no longer be attributed to one attempt. If observation fails, the operator may restart a live agent, overlook a waiting question, or misread old status as current. If judgment fails, the operator may ship a fluent but untested patch simply because it was the first one marked done. Orca’s design is strongest when these failure modes remain visible instead of being collapsed into a single “agent workspace” state.

This gives a compact evaluation model for a worktree card or dashboard row.