Workflow · 2026-09-24 · 5 min read

One Task, several executions

How a stable Task keeps its history when work moves between a provider, a computer, or a native session.

A coding agent's native session is useful, but it is a fragile unit for human coordination. The session can end, the provider can change, and a second computer can take over. GrantTap presents the Task as the stable unit you follow on your phone.

Each execution is one provider session working on that Task. Child agents remain nested under that execution. This structure keeps an agent handoff from looking like an unrelated new request.

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.

Demo handoff screen. A real transfer depends on target and policy readiness at the time of execution.

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.