Configuring a Worker: The 8-Step Wizard

Once a worker is hired, the Configure tab is where you turn it into a teammate you can trust to run unattended. It is an eight-step wizard, in prerequisite order: identity, runtime, permissions, credentials vault, AI accounts, autonomy and workload, vault access and scheduling, then review and activate. Each step is a small, plain set of choices, and Back and Next both save as you go, so configuring a worker is a checklist you can complete in one sitting and revise any time. After this page you will be able to walk every step, bind the worker's credentials vault, link its AI accounts, set exactly what it may do on its own, and activate it with confidence about what it can and cannot touch.

Configuring a worker is a permissioned action governed by your organization's roles and permissions. A worker can never be granted a permission the person configuring it does not already hold, and it can never hold organization administration, billing, or identity-and-access management. See Security and Governance.

How the Wizard Works

After this section you will know how to move through the wizard and how it saves. The eight steps run along the top as numbered circles. Move with Back and Next, or click a step to jump to it. Both Back and Next save the current step before they move, and a page-level Save lights up whenever there is an unsaved change and switches off once everything is saved, so you never lose a setting by navigating away. One step is gated: AI accounts and pool stays locked until you have bound the worker's credentials vault, because a worker cannot store a linked account until it has a vault to keep it in. That is the only lock; everything else is always reachable.

Step 1: Identity and Status

After this step you will be able to say who the worker is and whether it is working. The first step shows the worker's name, job title, and timezone, lets you assign it an email mailbox, and sets its lifecycle status.

Step 1 of the Configure wizard, Identity and status, for the worker Nova Reyes. The eight-step stepper runs across the top; step 5 shows a lock because the vault is not bound yet. A Basics block shows the name, job title, and timezone as facts. An Addressing block assigns an email mailbox. A Lifecycle status block (marked) offers a segmented Active, Paused, Archived control.
Step 1 sets the worker's identity and its lifecycle status. Active means it is working; Paused keeps it configured but takes no new work; Archived retires it without deleting its configuration. Note the lock on step 5 in the stepper: account linking stays locked until the vault is bound.
  • Name, job title, timezone. Shown here as facts; they are set when you hire the worker. The timezone drives the working-shift clock in step 7.
  • Email mailbox. Assign a Backbuild Mail mailbox so the worker can handle tickets that arrive by email.
  • Lifecycle status. Active, Paused, or Archived. Pausing keeps everything configured but hands the worker no new work; in-flight tasks finish. Archiving retires the worker; its configuration is kept so you can bring it back later.

Step 2: Runtime and Slots

After this step you will be able to size the worker's computer and control how often it re-checks its AI usage. A worker runs in exactly one container. Its size is the ceiling on how many concurrent slots it can run at once.

Step 2 of the Configure wizard, Runtime and slots. A Container size selector (marked) sets the one container the worker runs in. A Usage re-check block sets how often to re-check each linked AI account's provider usage while running and while idle, and which container size the idle check uses. A Slot layout note explains that per-tool slot counts are configured in step 5, bounded by the container size.
Step 2 sizes the one container the worker runs in and sets how often it re-checks each AI account's usage so the failover pool can spot a maxed account and an early reset.
  • Container size. The single container the worker operates. A larger size allows more concurrent slots; it is the ceiling on total capacity, and larger sizes draw more credits while running. Start small and raise it only when a task needs it.
  • Usage re-check cadence. How often the worker re-checks each linked AI account's provider usage and limits. The while running check piggybacks on a container that is already up; the while idle check briefly wakes a small container just to probe, then shuts it down. Set the idle-check container size to the smallest available to keep that probe cheap.

How does container size map to cost? The size sets the compute a running worker draws from your usage credits. Only active work is metered; an idle worker between tasks is not. Pick the smallest size that covers the work, and use the schedule in step 7 to keep it off when you do not need it.

Step 3: Permissions

After this step you will be able to see exactly what the worker is allowed to touch. A worker uses the same identity and access model as a human member: your organization's existing IAM roles, groups, departments, and policies. This step picks its role and shows the permissions that resolve from it.

Step 3 of the Configure wizard, Permissions. An Organization role selector (marked) chooses the worker's IAM role from Support Agent, Developer, or Inbox Manager. An Effective permissions block (marked) shows the read-only set of permissions that resolve from the role, group and department memberships, and direct grants.
Step 3 assigns the worker an IAM role from your existing role set and shows the effective permissions that resolve, the same resolution a human member gets. A worker can never hold your organization's owner or administrative authority; the server refuses regardless of who asks.
  • Organization role. One of your existing IAM roles, scoped to virtual-worker use: Support Agent, Developer, or Inbox Manager. Choose the smallest role that covers the job.
  • Effective permissions. Read-only. This is the net of the worker's role, its group and department memberships, and any direct grants and policies, resolved exactly the way a human member's permissions are. You manage group, department, and policy membership from your organization's existing IAM screens.

Two boundaries are worth stating plainly, because a security reviewer will ask. A worker is bound by least privilege: you grant it the narrowest role that does its job, and its permissions are scoped to your organization, so it cannot reach another tenant's data or escalate its own access. And a worker can never be granted a permission the person configuring it does not themselves hold, which is why the wizard shows you the resolved set rather than asking you to trust it. The reserved authority roles, organization administration, billing, and identity-and-access management, are off limits to a worker no matter how it is configured.

Step 4: Credentials Vault

After this step you will be able to give the worker a place to store its own linked-account credentials, safely. This is the step a security reviewer scrutinizes hardest, and it is designed to pass that scrutiny. You bind one zero-knowledge vault to hold the worker's own credentials.

Step 4 of the Configure wizard, Credentials vault. A binding card (marked) binds one credentials vault to the worker and shows it as bound, which is the precondition that unlocks step 5. The step header notes that account linking stays locked until the vault is bound.
Step 4 binds the one vault that stores the worker's linked-account credentials. It is a zero-knowledge vault: the credential is encrypted so that neither the model nor the platform reads it in plaintext, and binding it is the precondition that unlocks step 5.

The vault is zero-knowledge. When the worker later signs in to an AI provider, the resulting credential is captured and encrypted into this vault; the model never holds it in plaintext, and neither does the person who configured the worker. At run time the credential is made available to the worker's session under a grant, not by handing the plaintext to the model, so a prompt-injection attempt has no plaintext secret in the model's context to exfiltrate. Binding a vault is required before you can link any account, which is why the next step stays locked until this one is done.

Where are the AI credentials stored, and can they leak? In this bound zero-knowledge vault, encrypted so the model and the platform never read the plaintext. The worker signs in through the provider's own flow and the credential is captured into the vault directly; it is never pasted into a form the model can read, and it is not exposed to the operator. See Password and Secrets Vault.

Step 5: AI Accounts and Pool

After this step you will be able to connect the worker's AI accounts and choose how it uses them. This step links one or more accounts per coding tool and sets how the worker draws on them: one at a time with automatic failover, or all at once in parallel. It is unlocked once the vault in step 4 is bound.

Step 5 of the Configure wizard, AI accounts and pool. Each coding tool has its own panel; the Claude Code panel already has one linked account listed in its pool (marked), with a Link another account button (marked), a Failover-versus-Parallel usage policy toggle, and an effective-capacity readout. The stepper shows step 5 as unlocked now that the vault is bound.
Step 5 links accounts per coding tool. Each tool, Claude Code, Codex, Gemini CLI, and Kimi Code, has its own Failover or Parallel usage policy, per-account slot caps, and a live capacity readout. Accounts you have already linked are listed and managed right in the pool, and you can keep linking more, so several accounts survive a provider rate limit instead of stalling the worker.

The worker links its own accounts for the supported coding tools:

  • Claude Code, Codex, Gemini CLI, and Kimi Code each get their own panel. Cursor Agent and Devin CLI are supported here too. You bring your own provider accounts, so you are not locked to a single AI vendor.
  • Usage policy: Failover or Parallel. Failover runs one account at a time; if it hits its provider usage limit, a standby account takes over and the maxed one auto-resumes at reset. Parallel runs every non-maxed account at once, each up to its own slot cap, for the fastest throughput when you have several accounts.
  • Per-account slot cap. The maximum concurrent slots each account runs. The effective capacity readout shows how the tool's slot count in the container (from step 2) and the accounts' caps combine, and warns when the container size is the limiting factor.

Linking an Account

After this section you will be able to start a native sign-in for any tool — as many times as you need. Select Link <tool> account and a large linking dialog opens over the page with a choice of methods. The dialog is always an add-another-account surface: the accounts you have already linked stay listed and managed in the pool behind it, so you can keep adding a second, third, or tenth account for the same tool. It never collapses just because one account is already connected.

The Link Claude Code account dialog, a large modal over the Configure page. It reads Add another account, then a method picker with four cards: Backbuild container (marked, recommended) to sign in with the provider's own CLI in a temporary container terminal; a connected desktop app; a connected IDE extension; and API key (marked) as an alternative to native sign-in. The account pool with an already-linked account is visible behind the dialog.
Linking opens in a large dialog whose only job is to add another account. Because the accounts already linked are managed in the pool behind it, the add flow is always available — you are never blocked from linking a second account for a tool. The recommended path signs in with the provider's own CLI inside a temporary Backbuild container terminal; a provider API key is offered as an explicit alternative.

Choose Backbuild container and the provider's own sign-in flow launches in a temporary terminal: the worker's account is signed in with the real provider CLI, and the resulting credential is captured straight into the vault you bound in step 4. Each completed sign-in adds a new, distinct account to that tool's pool rather than replacing the last one, so a worker can hold several accounts per tool and fail over between them. You complete the provider's own sign-in, and nothing about the credential is ever shown as text in the browser or sent to an application. An API key is available as an alternative for tools that support it. The same launched sign-in surface is used for every tool:

The launched Claude Code native sign-in surface inside the Link Claude Code account dialog, noting the credential is captured directly into the worker's vault and never shown here, and that this adds a new account rather than replacing the existing one.
Claude Code sign-in.
The launched Codex native sign-in surface inside the Link Codex account dialog.
Codex sign-in.
The launched Gemini CLI native sign-in surface inside the Link Gemini CLI account dialog.
Gemini CLI sign-in.
The launched Kimi Code native sign-in surface inside the Link Kimi Code account dialog.
Kimi Code sign-in.

Do multiple linked accounts multiply the cost? No. Pooling accounts adds rate-limit headroom, not a multiplied bill: in Failover only one account works at a time, and in Parallel each account works only up to the slot cap you set. You use the accounts you link, and the per-account slot cap is your lever on how much runs at once.

Step 6: Autonomy and Automatic Workload

After this step you will be able to decide, per capability, what the worker does on its own, and which help-desk work it picks up automatically. This is the step that answers the question everyone asks first: will it act on its own?

Step 6 of the Configure wizard, Autonomy and automatic workload. Per-capability Supervised-versus-Autonomous toggles (marked) for reply to tickets, resolve tickets, and fix bugs. Send external email and Push code are shown as always-supervised with a lock and an explanation. Below, a Help Desk stage assignments block plus minimum-priority and product-area filters scope the automatic workload.
Step 6 sets autonomy per capability and scopes the automatic help-desk workload. Two high-risk actions, sending external email and pushing code, are always supervised and cannot be switched to autonomous in any setting.
  • Autonomy per capability. For each capability, choose Supervised (the worker drafts and a person approves) or Autonomous (the worker acts on its own). Set reply-to-tickets, resolve-tickets, and fix-bugs independently, so you can loosen one queue while keeping another under review.
  • The always-supervised floor. Two high-risk actions, sending external email and pushing code, are always supervised and cannot be made autonomous. This floor is enforced by the platform's approval policy, not by a setting you can toggle off, so a worker can never email a customer or push code without a person in the loop.
  • Automatic workload. Choose which help-desk workflow stages the worker automatically claims, and narrow it with a minimum priority and specific product areas. This is the same stage-worker binding the help desk uses, so the worker only ever picks up work in the lanes you scope it to, and a filtered SaaS package keeps the stage and area lists to what that package exposes.

The recommended way to adopt a worker is to start it fully supervised, watch its drafts, and loosen autonomy one capability at a time only on the queues where it has earned your trust. Because the high-risk floor holds regardless, even a worker dialed to autonomous cannot cross the two lines that matter most. Autonomy, the approval queue, and the pause and fire controls are covered in Autonomy and Approvals.

Will it push code or email a customer on its own? Not unless a person approves it. Sending external email and pushing code are always supervised and cannot be set to autonomous, so those two actions always route through a human, whatever else you configure.

Will it grab tickets it should not? It only auto-claims the stages, priorities, and product areas you scope it to in this step. Anything outside that scope stays with your people.

Step 7: Vault Access and Scheduling

After this step you will be able to grant the worker any additional read vaults it needs and set its working hours. This step combines two things: extra vaults the worker may read for its tasks, and the shift and holidays that keep it to human-style hours.

Step 7 of the Configure wizard, Vault access and scheduling. An Additional vault access block grants extra read vaults. A Working shift block (marked) selects work days Monday through Friday, a start and end time, and a randomized offset. A Holidays list holds dated entries the worker will not work.
Step 7 grants any additional read vaults and sets the worker's shift, its randomized clock-in offset, and its holidays. Off shift, the worker does nothing unless a task was scheduled; work that arrives off shift queues for its next shift.
  • Additional vault access. Vaults the worker may read for its tasks, separate from the credentials vault in step 4. Granting a sensitive or production vault widens what the worker can reach, so it is a high-privilege choice; grant only what a task needs. A grant to a production vault steps up with any configured second factor.
  • Working shift. The days and hours the worker is on shift, read in its timezone, plus an optional randomized offset so it does not clock in at the same second every day.
  • Holidays. Specific dates, each with an optional label, when the worker is off for the whole day.

Scheduling is also a cost lever: a worker with nights and weekends switched off draws nothing while it is off shift, and simply takes up queued work when its next shift begins.

Step 8: Review and Activate

After this step you will be able to confirm every choice and put the worker to work. The final step lays out everything you set, identity, runtime, permissions, vault, autonomy, stage assignments, product areas, and shift, on one screen, so you can read the whole configuration before you commit it.

Step 8 of the Configure wizard, Review and activate. A summary lists identity and status, runtime, permissions, credentials vault, autonomy, stage assignments, product areas, and working shift. An Activate worker button (marked) saves everything and puts the worker to work.
Step 8 summarizes every choice on one screen. Activate saves the whole configuration and puts the worker to work; if the credentials vault is not bound, the summary flags it, because a worker cannot activate without one.

Reviewing the summary is where you confirm the worker holds exactly the reach, accounts, autonomy, and hours you intend. When it reads right, Activate worker saves everything and moves the worker to active. Nothing here is permanent: every step is editable later in the same wizard, and you can pause or fire the worker at any time without losing its configuration.

What Gets Recorded

After this section you will know that the worker's work is attributable. Everything a worker does runs under its own named identity and is written to your organization's audit trail and transcript history, so a supervisor can read exactly what it did and why. That, together with least-privilege permissions, the zero-knowledge vault, and the always-supervised floor, is what makes a Virtual Worker something you can put in front of an auditor. The full model is in Security and Governance.

Where to Next