Roles & the Master

When several people share the same hubs, somebody has to be in charge of the irreversible actions — chiefly, permanently deleting a shared Company or Worker. askTheodor handles this with an instance role you set on each machine, plus one designated ⭐ Master Command Center that holds the delete authority. Everyone keeps working; only the dangerous, can’t-undo operations are funnelled through the Master.

The role model

Each instance declares what it is in the Fleet screen, on the “This machine” card:

• Master Command Center (⭐) — the one desktop in charge. The only instance allowed to permanently delete shared Companies or Workers off the hubs, and the instance that approves or rejects everyone else’s delete requests.
• Secondary Command Center — a teammate’s full desktop. It can create, edit, sync, and delegate freely; it just can’t permanently delete shared things on the hubs.
• Team-Hub — a headless runner. It applies what it’s told and runs its own work, but never initiates deletes of shared Companies or Workers.

When you actually need a Master

With one Command Center, you don’t designate anything — that single desktop is implicitly the Master. You only pick a Master once a second Command Center joins the same hubs. See the topology cases in the overview.

Setting this machine’s role

1. Open Fleet (or Settings → Peers).
2. Find the “This machine” card at the top.
3. Choose this instance’s role, and — on the desktop you want in charge — mark it ⭐ Master.

There is meant to be exactly one Master across the whole team. The Master role is reassignable by the account owner: if the Master desktop is retired, hand the star to another Command Center.

Least privilege for teammates

A Secondary Command Center is intended to pair with the sync and delegate capabilities only — not full — unless you deliberately promote it. That way a teammate can do their job without holding keys or delete power they don’t need.

The delete rule (why it matters)

Sync mirrors everything across machines, which makes one operation genuinely dangerous: a delete. If any teammate could hard-delete a shared Company and have it vanish everywhere, a single mistake — or a delete racing someone else’s edit — could wipe shared work. So deletes are gated:

• From the Master: a delete is authoritative. It finalizes across the fleet and the rows are removed everywhere.
• From a Secondary: a delete becomes a soft-delete. The item disappears from that teammate’s lists immediately, but it stays live on the hubs, and a delete-request is sent to the Master.

The approval queue (the Secondary flow)

1. A Secondary operator deletes a shared Company or Worker. It’s marked pending and hidden locally — but still running on the hubs.
2. A delete-request notification reaches the Master.
3. The Master operator approves → the item is permanently removed everywhere. Or the Master rejects → the item reappears on the Secondary, untouched.
4. Every step is recorded — who requested, who decided, and when — as an audit trail.

This is the same human-in-the-loop idea as the tool-approval gate, reused for deletes.

Secondary CC: "delete this Company"
      │
      ▼  soft-delete — hidden locally, still live on hubs
  delete-request ──────────▶  Master CC
                                 │
                  approve ◀──────┴──────▶ reject
                     │                      │
          removed everywhere      reappears on the Secondary

Status: partly shipped

Shipped today: declaring an instance’s role and marking the Master in the Fleet screen. In progress: the soft-delete tombstones, the cross-instance delete-request queue, the Master’s approve/reject UI, and — importantly — server-side enforcement (a hub rejecting a destructive change that wasn’t signed by the Master, rather than trusting each app to limit itself). Until enforcement lands, treat the role model as a strong convention rather than a hard guarantee, and keep deletes to the Master desktop.

A note on people vs. machines

The role here is about instances (which machine is the Master). That’s separate from, and layers on top of, the org roles you give workers inside a Company (their titles, departments, and reporting lines). Over time the same model is meant to cover human teammates too — owner / admin / editor / viewer over a shared Company — so people and AI workers share one way of being assigned work and permissions.

In practice

Skip all of this while you’re the only operator. One Command Center is implicitly the Master; there’s nothing to declare and no queue to work. The role model only starts mattering the moment a second desktop pairs to the same hubs — and the right time to set it up is before that pairing, not after the first accidental delete.

The scenario the delete rule exists for is mundane rather than malicious. A teammate tidies up what looks like a stale Company; sync faithfully propagates the removal to every machine; the work someone else was mid-way through is gone. Routing deletes through one designated desktop turns that from a data-loss event into a request somebody declines.

Grant Secondaries sync + delegate, not full. A teammate needs to mirror the workspace and hand work to hubs; they rarely need to hold your provider keys. Since changing scopes means removing and re-pairing, it’s worth deciding at pairing time — and least privilege here costs them nothing in day-to-day work.

Reassign the star when a machine retires. There should be exactly one Master, and a Master on a laptop that’s been replaced leaves nobody able to finalise deletes. Handing it to another Command Center is the fix; it isn’t tied to hardware.

Until server-side enforcement lands, treat this as convention. Declaring roles and marking the Master is shipped; hubs rejecting unsigned destructive changes is not. Practically: keep deletes on the Master desktop by agreement, and don’t rely on a Secondary being prevented from doing something it shouldn’t.

Instance roles are not worker roles. The ⭐ Master is about which machine may finalise deletes; the titles and reporting lines inside a Company are about which worker may delegate to whom. They’re independent, and confusing them leads to expecting permissions neither one provides.

Terms in this page

• Instance role — what a given machine is in the team: Master Command Center, Secondary Command Center, or Team-Hub. Set on the “This machine” card in Fleet.
• Master Command Center (⭐) — the single designated desktop allowed to permanently delete shared Companies/Workers and to approve or reject others’ delete requests.
• Secondary Command Center — a teammate’s full desktop that can create, edit, sync, and delegate, but whose deletes become soft-deletes needing the Master’s approval.
• “This machine” card — the panel at the top of the Fleet screen where you declare this instance’s role.
• Soft-delete — hiding an item locally and marking it pending, instead of removing it, so a Master can approve or reject the removal first.
• Tombstone — the marker left on a soft-deleted row (who deleted it, when, and its pending/approved/ rejected status) so the deletion can be finalized or undone fleet-wide.
• Delete-request — the notification a Secondary sends the Master asking to permanently remove an item.
• Approval queue — the list of pending delete-requests the Master reviews.
• Audit trail — the recorded history of who requested, approved, or rejected each cross-instance action.
• Server-side enforcement — the receiving instance checking a change against the sender’s role and rejecting unauthorized destructive operations, rather than trusting the caller. (Planned.)
• Least privilege — granting each machine only the capabilities it needs (e.g. a Secondary gets sync+delegate, not full).
• Org roles — the titles/departments/reporting lines given to workers inside a Company; distinct from an instance’s role, and the basis for future human-teammate permissions.