Introducing Duetmany hands, clear direction
A worker told us a failing test was pre-existing. It had compared the change with an earlier commit on its branch, and that comparison supported its explanation.
The manager checked the same test against several commits in isolated checkouts. That exposed the missing distinction: the earlier branch state was not the agreed baseline. The test was clean on the relevant base and failed later in the work.
The correction came from changing the comparison. Having a separate session question the premise made it easier to see what the first explanation had missed.
That is one reason we use Duet. A worker can stay close to implementation while a manager keeps enough distance to inspect the result and preserve what the project learned.
A manager for each stream of work
Duet pairs a manager session with a worker session. The manager scopes the assignment, holds the agreed review gates, and keeps the project record. The worker plans, builds, tests, and reports back.
A manager can hold several pairings at once. Each worker has its own arrangement, scope, questions, and return route. The manager coordinates dependencies between them.
Start with the number of workers the work needs and the manager can review carefully. Extra sessions are useful when their assignments can move independently and their results still receive attention.
Work that comes back with evidence
In our own run, the loop looked like this:
Clear assignment → reviewed plan → failing test → implementation → independent code review → manager's review of the actual diff → authorized landing → recorded outcome.
The assignment did more than name a story. It carried the context, intended change, acceptance criteria, and traps already found in earlier work. That gave the worker something precise to build against.
The review package named the code being reviewed and the checks that had actually run. The manager could inspect the diff and output before accepting the result. When it needed more work, the question and next obligation stayed with the assignment.
This is how we run it on ourselves. Our field notes describe changes that needed several rounds of review, and defects the manager found after an independent reviewer had approved the work. Those findings included a regex that would have hidden the issue under investigation, a missing security check, and an omitted harness step.
Those are observations from our work, not a benchmark or a promise about another project. They show why we keep independent review and the manager's inspection as separate steps. They can notice different problems, and either can still miss something.
The decision belongs to the project
A useful result includes what changed, what was checked, what remains uncertain, and what the next session should do. Storybloq records the pair's identities, assignments, pending questions, obligations, and result history. The arrangement also keeps a checkpoint for recovery. Handovers preserve decisions and evidence references needed after a session ends.
Where configured gates require an acknowledgment, it can be tied to the exact plan bytes or a staged Git tree and parent commit. In plain language, the decision points to a specific version of the work. The record also distinguishes an acknowledgment with independent-review evidence from one made on inspection alone.
In our landing procedure, we captured the reviewed patch and checked the landed code against the accepted result. That is a practice we used to preserve the reviewed work; Duet does not automatically land every approved package for you.
One worker in the field report crossed a compaction boundary mid-task and continued from a written summary. The important part was what survived: the allowed work, the checks still owed, and the result the manager was waiting for.
A pairing needs a return route
An arrangement is a project record. Messaging comes from the client or a separately configured transport. Before dispatching, both sessions check their actual capabilities and demonstrate a matching return.
A worker can reply directly when it has a sender, or the manager can collect its final output when that route is available. If neither works, the pairing is not ready to take an assignment.
Completion handling differs too. A supported Claude Code harness may provide a worker-turn-end notification that the manager must re-arm. Codex Desktop coordination uses bounded completion waits while assignments remain open. A message arriving once does not prove that an idle session will wake later.
Around an interruption, the manager reads the durable obligations, collects outstanding results, and restores the return route before starting new work. Storybloq Bus is another transport with its own setup and endpoint requirements; a Duet arrangement does not silently enable it.
Start with one useful pairing
Choose one small story. Give the manager responsibility for scope and the project record. Give the worker a clear outcome, a proved return route, and a next review gate.
Keep the roles specific enough that both sessions know what they owe. Add workers when the work can move in parallel and the review can keep up.
Pairing does not grant new permission to spend, change protected state, or release software. Model-provider costs and usage limits still apply. Duet helps organize the work and keep its evidence and decisions available to the next session.