One Task, several executions

What travels with the Task

The useful handoff is a bounded record of the objective, current owner, relevant decisions, blockers, resource claims, and a route to the next execution. It is not a copy of hidden reasoning or a demand that every provider share its private transcript. The human still sees one Task and the sequence of executions that performed it.

A handoff should name the target computer and provider explicitly. If the selected host is offline or lacks the required capability, the route must be refused or queued with a visible reason; silently choosing a different host would change the user's decision.

Why branches and receipts matter

Parallel agents can touch the same repository. Separate branches or worktrees and resource claims make their overlap visible before a merge conflict. A handoff receipt records that the next execution accepted the work. It does not prove that the next agent understood every decision or that a code change passed verification.

When a Task finishes, inspect the outcome, tests, and any remaining unknowns. A process printing text is not evidence of success if the process failed. GrantTap should keep delivery, execution, and verified result as separate facts.

Use the phone for decisions

The phone is best at answering a specific question, approving or denying a bounded action, and checking where the Task is now. It should not need to own every byte of the coding runtime. The execution stays on a computer; the controller carries the authority and the concise history needed for the next step.

A Task is the durable story

Imagine asking an agent to repair a failing test, then leaving the desk. Its native session may inspect files, delegate a narrow search to a child agent, and stop when it needs permission to run a command. Those are events within one user request. If a provider window closes, the user's objective has not become a new objective. A stable Task lets the phone present the same work, its next decision, and its execution history without treating every session boundary as a fresh assignment.

This distinction matters most when a second provider or computer enters the picture. The new execution should know which Task it serves and which facts were deliberately carried forward. It should not be asked to inherit invisible reasoning or assume that a summary is a full transcript. The human-visible record can preserve the objective, decisions, blockers, and evidence references, while the provider keeps its own native session semantics. Continuity is a claim about traceable work, not identical internal state.

Build a handoff that can be inspected

A useful capsule names the source execution, intended target, repository and revision, relevant constraints, and the work still open. It distinguishes observed facts from the previous agent's interpretation. For example, ‘test command exited with code one’ is stronger than ‘the tests look broken’; the command, exit result, and time let the next person verify the statement. A short handoff can be safer than a large transcript if it is explicit about what it omits.

The destination should acknowledge acceptance rather than silently appearing to continue. Acceptance means the route reached a compatible session; it does not mean the destination understood every detail or completed the task. If it cannot start because the machine is offline, the provider is unavailable, or the target checkout differs, the Task should keep the failed or pending route visible. This prevents a queued action from masquerading as productive work.

Repository state is part of the route

A task about code depends on more than its title. The next execution needs to know which repository and checkout it is entering, whether the branch has uncommitted changes, and whether another agent claims the same files. A path alone is ambiguous across computers; a branch name alone does not guarantee identical contents. Attach revision and resource context to the route, and require the receiving execution to report what it actually sees before it edits.

Consider two agents preparing changes to the same module. Separate worktrees isolate their files, but do not settle the product decision about which result to keep. Resource claims make likely overlap visible, and a later review resolves it. A receipt that merely says ‘accepted’ is therefore not a merge result. The Task should expose the chain from routing to code review and verification, with room for conflict and uncertainty.

What the phone can decide

The phone is useful for small, well-scoped choices: continue this Task on a named computer, answer an approval request, or inspect the latest result. It should show the action's target and consequences before a tap. A vague button saying ‘continue’ is insufficient when several computers and providers are available. The person needs to know whether they are resuming an existing execution, starting a supported new one, or only queuing a message for later delivery.

The phone is not a replacement for checking a diff, rerunning a failing test, or reviewing a security-sensitive operation on the computer when those steps require more context. A compact status can link to the right evidence and make the next human action clear. It should also be able to say ‘unknown’: no observed invocation is different from an observed failure, and both differ from a successful verified change.

A realistic end-to-end check

For a trial run, choose a modest Task and write down its objective before starting. Let one provider investigate it, record a decision or blocker, then request a supported handoff to a specific second execution. Inspect the capsule and the receiving receipt. Confirm that the second execution sees the intended repository state and can explain its next action. Finally, examine the code change and rerun the relevant test. Each step tests a different promise.

If the provider or host does not support the requested remote start, stop at that boundary and use the supported continuation path. GrantTap's current handoff coverage is provider and target dependent; a concept diagram cannot expand it. The editorial image above illustrates successive workstations, while the in-app screenshot below uses deterministic demonstration data. Neither replaces the real receipt and code evidence from your own Task. The durable outcome is a decision trail a person can revisit.