Peer Task Details

Freshness and Carried Changes

For a peer with the same repository, the Send to Peer dialog shows how the peer's working copy compares with this one, for example win-vm: dev-beta at a1b2c3d4e5f6, 4 changesets behind; differs in launch-env.bat (named by the task) and 6 other files. The files counted include both unpushed commits and uncommitted changes here.

Include my changes sends this machine's changes to the differing files with the task. It is checked when the task names files that differ and their changes can be carried, and then sends only those; checked by hand, it sends the changes to every differing file. The peer applies them before the task starts, so they are not counted as the task's own changes, and reverts them once the task's work is back here or the task is taken back.

The changes can't be carried when the peer holds commits this working copy lacks, is on another branch, uses another version control system, or has uncommitted changes in the same files. The dialog then names the files and says why, and Send becomes Send Anyway, which sends the task without the changes. To run the task on current code instead, pull and update the peer's working copy first.

On the Receiving Machine

Wing checks each message before any agent sees it, and declines one that fails, as described in Trust Peer Machines in AI Agent Safety. It files each accepted request as a task in the inbox goal set in Peers..., as Ready or Draft. The task runs autonomously, as Decide and Report, with the receiving machine's own permissions. When it finishes, Wing sends its report back, with its changes for a Change task, and then reverts its changes and any carried ones here. Only a handoff's changes stay, to be reviewed and committed there.

Requests whose carried changes touch the same files take turns: a later one is filed as a Draft with a Held chip until the earlier one's changes are reverted. To apply its changes without waiting, click the Held chip and select Apply Carried Changes Now.

When the Work Comes Back

Wing applies a returned patch to this working copy with a three-way merge. The files it changes become the sent task's changes, and the task moves to the Review tab, where it is reviewed, tested, and committed as usual. The task's report names any file the peer could not carry back, for example because it is binary or too large.

When the patch conflicts with changes made here since the task was sent, Wing saves it as a .diff file and files a Ready task, in the sent task's goal, for an agent to merge it. The sent task goes to History once the merge task reaches Review.

When the patch can't be applied, for example because a file it touches has unsaved changes in the editor, the Questions tab lists it with Apply Again and these choices:

The .diff files are saved in the research notes directory, set in Tasks Manager Settings..., with names that start with peer-patch-.

Returned Files

When Return files to names a directory, the task on the peer writes the files it makes for you to .TASKS/peer-out/ in its working copy. The reply carries them, binary files included, and Wing writes them into the named directory here, for any kind of task and any peer. They become the sent task's changes, and go to Review with it.

Completing Tasks on Both Machines

Once its work has come back, a task can be on the Review tab on both machines: the requesting machine's copy with the report, and the peer's. By default, Mark Complete on either copy moves the other machine's copy to History too. A copy with changes to commit stays on Review, so the work is never lost or committed without you. A commit on one machine never completes the other's copy. To turn this off, uncheck Mark Complete closes the peer's copy too in Peers....

Peers with Other Repositories

A peer with another repository runs a task in its own working copy, so only Report and Hand off can go to it. No changes go to it or come back from it. Write the task for someone without this repository: what to do and find there, rather than which of this repository's files to change. When such a peer is chosen, the Send to Peer dialog shows its operating system, branch, and description in place of how fresh its working copy is.

Peer Chips

A teal chip marks each task that crossed machines. → win-vm marks a task sent from here, followed by where it is on the peer, such as Queued there, Running, or Returned. ← mac marks a task filed here from a peer's request. Hovering over a chip shows the task's whole exchange. The Classic look colors the text instead of drawing a chip.

These states need you: