The Local to Cloud handoff is convenient to picture as a continue in the cloud button: press it and the same work rolls on, only on another machine. The strength of the technique lies elsewhere, and it is easy to skip past. The strong route is to explore the task locally in Plan mode, agree on the decision, and then in one action hand the already agreed plan to the Cloud for implementation. The value is not that the work continues but that an agreed plan, not a raw idea, is what goes to the cloud.
The naive move is to press the handoff early and fill in the details as you go, as in an ordinary local dialogue. It seems faster: do not spend time on wording, just correct the agent with remarks when it veers off. Locally this sometimes works, because you are nearby and see every step. But what saves you locally - your presence beside it - is unavailable in the cloud, and the technique stops working exactly when the work leaves your sight.
It breaks at two boundaries at once. The first is already familiar: the cloud does not see your uncommitted state or your train of thought - it knows only what was passed. The second is tempo: a cloud session runs long and without you, and you can no longer fix it with a remark as promptly as you do locally. So everything the agent will need must be in the handoff at the moment of transfer, not appear later.
The professional mechanism is to make the handoff a self-contained contract. It includes a fixed commit or branch, the agreed plan, explicit prohibitions, required checks, the expected PR structure, secrets and network policy, a stop condition and a known failing baseline. It is convenient to keep this as a single template filled in before each transfer. Each of these fields answers a question that would otherwise surface at an inconvenient moment: from which state to start, what to count as success, what not to touch, and where to stop and ask a human.
Why a contract rather than free correspondence. Each field of the contract is uncertainty removed in advance that would otherwise have to be removed in the middle of a long session when you are not there. The line do not change turns a wish into a boundary; required checks turns the word works into a verifiable fact; known failing baseline separates an inherited breakage from one introduced by the agent. The contract costs a minute on the way in and saves hours of untangling on the way out.
It is worth understanding separately how the message queue in the cloud is arranged, because it provokes that very naive mistake. The Cloud send queue lives on the server and syncs with the web app; Cmd/Ctrl+Enter queues a message rather than sending it immediately. Since the queue is server-side, it survives a reload and shows up in the web. Using it correctly means editing the queued correction, not sending contradictory additions on top from which the agent would have to assemble your real intent itself. Several conflicting messages in the queue are not a clarification but an instruction to the agent to guess which one is the main one, and it does not always guess the way you meant.
Such a handoff is justified where exploration and implementation split naturally: the scope has cleared up locally, the decision is agreed, and the work itself is long and does not need your machine. The sign of readiness to hand off is that you can fill in the whole contract without leaving fields of it will figure it out as it goes. If such a field stays empty, the task is not yet ripe for the cloud and asks for the plan to be refined locally.
You should judge the result by the PR's conformance to the contract, not by the fact that the agent sent something. Did it pass the required checks; was the do not change section respected; did the PR structure match the expected one; did the agent stop where the contract told it to stop and ask. A known failing baseline is especially valuable here: it prevents blaming an old red check on the agent's work and the reverse.
Hence the engineering conclusion: the handoff contract is not bureaucracy but verification moved forward. Everything you did not fix in it you will be clarifying after the fact from an external diff, already without the context of the agreement. So the plan is agreed locally, where it is cheap, and only what can be checked on return is sent to the cloud. This is discipline, not a product requirement: the system will accept even an empty idea, its implementation is what turns out expensive.
The typical failure is contradictory additions to the queue and an incomplete contract. The symptom is recognized like this: the PR comes back as almost it, the agent clearly understood part of the task its own way, and the queue history holds several messages that argue with each other. Before sending yet another remark, edit the one already in the queue and check the handoff against the contract - most often the discrepancy grows from a missing field, not from the agent's error.
Handoff contract
Repository/branch:
Approved plan:
Do not change:
Required checks:
Expected PR structure:
Secrets and network policy:
When to stop and ask:
Known failing baseline: