Link a worker machine

Use this when you want background work to spread across more than one machine, and to see in one place which machine can take what. Linking makes another installation a worker of your owner machine, the installation that holds each run’s state and history and decides where each step runs. The owner machine is not the user that barry owner shows.

Before you begin

You operate both machines, and Barry runs on each.
The owner machine publishes its workflow service on a private HTTPS route with no interactive sign-in.
You have read Add a second machine for heavy jobs, which walks through the route, the invite, labels, and capacity step by step.

Link the machine

On the owner machine, invite the worker by a name you choose. The command prints a join token once:

barry workers invite studio-mac

On the worker, join with that token and restart its runtime:

barry workers join <token>
barry service restart workflows.runtime

Add --jobs to the invite to limit which versioned jobs the worker may claim. The owner machine enforces that scope at every step, and the worker cannot widen it.

See your workers

Background work lists each worker by its name. Each is in one of four states, Ready, Busy, Offline, or Needs setup. Each worker shows the capabilities Barry verified on it. When a worker cannot take some work, it says why, and names the missing piece: code, a model, a workspace, a credential, or capacity.

Know where work runs

The owner machine places each step in layers, and a later layer never overrides an earlier one:

Eligibility. A step runs on a worker only when that worker can enforce everything the step requires: its credentials, its workspace, its runtime, and its bounds. Otherwise the step stays on the owner machine, or shows as blocked with the reason.
Capacity. The worker, and the model endpoint it would use, must both have room.
Preference. Locality, an already loaded model, and your stated preference break ties.

Where an agent runs and where its model runs are separate choices, and each work item records both. Barry never swaps in a different model after a failure on its own. Work on a worker sends its changes back as artifacts or a patch, never as a silent overwrite of a shared repository.

Verify

The new worker appears in Background work as Ready. On the worker, barry workers status lists the jobs it offers to the owner machine and why it withholds any. A work item placed on it names the worker as its execution host in the item’s details.

If it fails

The worker shows Needs setup. Read the missing piece it names, then install the code, model, or credential on that machine.
The worker shows Offline. A worker that stops advertising drops out within seconds. Check its services and its route to the owner machine; see Check installation health.
You need to remove it. barry workers revoke studio-mac on the owner machine refuses the worker’s next call and stops its running work. Barry keeps that capacity reserved until it sees the work stop.