---
title: "Stop letting the agent guess which clone to touch"
canonical: https://dxdev.com/blog/2026-05-13_stop-guessing-the-clone/
datePublished: 2026-05-13
---
The platform runs on four parallel clones: clone two, clone three, clone four, and a base clone that carries no number at all. Different tickets get routed to different clones to keep work from colliding. When the agent picks up a fresh ticket and the routing is right, this works fine. When the agent guesses which clone to use before it has confirmed where the ticket belongs, it can walk right into the wrong directory and start editing with full confidence.

That is not a theoretical failure mode. The way the routing skill used to work, a fresh ticket would trigger the agent to look at what clones were available and pick one. If session context was ambiguous, the default tended toward the base clone, the one that carries no number. That clone is valid for some work. It is wrong for a ticket that belongs on clone three. The agent does not second-guess itself once it has a plausible answer, and "the clone is there and it is not locked" is a plausible answer.

The fix I shipped was a policy change, not a clever algorithm. Fresh tickets now default to read-only review. The agent reads the ticket, reads the relevant code, and surfaces a plan. It does not check out a branch or edit a file until the session has been explicitly attached to a clone and that attachment is confirmed. Write access has to be earned, not assumed.

## the routing landmine in session attach

The subtler problem was session attach. In the original design, when work was "unclaimed" (no session had declared ownership), the system needed a fallback. That fallback was the base clone, the one with no number. Not clone two, not the right clone for the current ticket, just the first plausible checkout matching the default name.

This is the kind of default that hides well. Most of the time, work that is unclaimed is also not being actively edited, so the wrong fallback never fires. But occasionally a session gets interrupted, or the session manifest does not get written correctly, or someone runs a command in a context the system did not anticipate. The fallback kicks in, the agent is now operating on the wrong clone, and it either catches the mismatch immediately (if it checks) or continues merrily (if it does not).

Hardening session attach means unclaimed work no longer silently inherits a clone. If the session does not have an explicit attachment, the system surfaces that gap and stops. The agent either establishes the right attachment before proceeding, or it tells me it cannot determine where to operate.

## the cockpit prototype was the proactive version of the same fix

While the routing policy was fixing the reactive failure, I built the cockpit orientation prototype to fix the structural cause upstream.

The cockpit is a per-session chrome layer. When a session opens, the browser lands directly on the session page with the vault key already prefilled. A strip under the header shows the current area, epic, and task, with a unified picker to set or change any of them. The agent does not have to infer context from environment state or file structure. The session starts with explicit orientation already in place.

This addresses a different layer of the same problem. The routing policy fixes what happens when the agent guesses. The cockpit fixes the conditions that made guessing necessary. If the session opens with area, epic, and task declared, the agent knows which clone the work belongs on before it reads a single file.

Phase 2 of the cockpit (inline pickers in the conversation stream, new-task and new-epic create flows) is not built yet. What shipped on the 13th was the session-start surface: chrome opening on the right page, vault key prefilled, orientation strip visible from the first prompt.

## the actual failure mode is confidence, not guessing

The way to state this precisely: the problem is not that the agent guesses. Agents always operate on incomplete information, and most guesses are fine. The problem is that the agent continues with the same confidence level after a guess as after a verified fact.

When I ask a human collaborator which directory a ticket belongs in, they say "I think it's clone three but let me check" or "I'm not sure, let me look at the session manifest." They signal the uncertainty. They do not disappear for five minutes and come back having edited files in a directory they were not sure about.

The routing policy and the session attach hardening are both ways of forcing the uncertainty to surface before the write happens. Read-only by default means the cost of a wrong guess is a plan that needs to be corrected, not a file that needs to be reverted. No silent fallback means the gap has to be filled explicitly, not papered over.

If your AI workflow guesses the repo before it proves context, it will eventually edit the wrong thing with confidence. The fix is not a smarter guesser. The fix is removing the path where the guess is enough to proceed.