Working with your Clone

You should feel you are talking to one Clone. It coordinates concurrent work behind the scenes and brings progress, questions and results back to the original conversation. You should not need to route requests between workers or assemble their responses.

The prototype contract includes steering a task with a new instruction and cancelling a task independently. A changed instruction invalidates pending decisions based on the old one. Cancelling one task is intended to leave unrelated work running.

A cancellation request is not the same as a confirmed stop. Cancellation is acknowledged only after the task’s workers stop dispatching actions. Effects that already happened remain recorded; cancellation cannot promise to undo them.

Work may be queued, running, waiting for approval or waiting for your input before it completes, fails or is cancelled. A task waiting on other work is not complete. The intended event history lets clients reconnect and resume without presenting duplicate progress as new work.

Results should return to the original conversation with enough evidence for you to check the outcome. A declaration that a task is done is a proposal that still needs an outcome check. If an action’s external outcome is unknown after a failure, the system must inspect it before retrying.

The first build must demonstrate concurrent tasks, independent cancellation, reconnecting and verifiable results together. These documents describe that intended behavior, not proof that the full experience is ready.