Hiring and Configuring a Worker

Hiring a worker is the same act as onboarding a teammate: you give it an identity, decide what it may touch, tell it its job, and set its hours. The hire wizard and the per-worker editor share one layout, so what you set at hire time you also revise later in the same place. This guide walks every section, persona, runtime, operating instructions, and schedule, so a worker starts with exactly the identity, reach, and working hours you intend. After this page you will be able to hire a worker, place it under a manager, give it a mailbox, and set its shift and holidays.

Hiring and configuring workers is a permissioned action, governed by your organization's roles and permissions. A worker never gains a permission the person configuring it does not already hold; see Security and Governance.

The Identity: Name, Job, and Role

After this section you will be able to give a worker an identity and decide what it is allowed to touch. Under Persona you set who the worker is:

• Name. Required. This is how the worker appears on the roster, in transcripts, and in the audit trail. Give it a real, person-like name so its work reads clearly in your history.
• Job title. A short description of what it does, for example Customer Support Agent or Build Engineer.
• Permission role. One of three roles that decides the worker's reach: Support Agent for help-desk and reply work, Developer for project and code work in a container, and Inbox Manager for triaging mail. The role is the ceiling on what the worker can do; you choose the smallest one that covers its job.

A worker's underlying identity is created the moment you hire it. It is a non-login identity: it cannot sign in, cannot be phished, and holds no password of its own. That is what lets the worker own its settings, its mailbox, and its linked accounts as a first-class member of your organization while never being a door an attacker can walk through. The three roles are deliberately narrow: a worker can never hold organization administration, billing, or identity-and-access management. That boundary is covered in Security and Governance.

Reporting and Email

After this section you will be able to place a worker under a manager and give it an address to work from. Still under Persona:

• Manager. Choose whether the worker reports to a person or to another worker, then pick that manager. The manager is who reviews the worker's approvals and is accountable for its output, so every worker has a clear line of oversight.
• Timezone. The zone the worker's shift is read in. Leave it blank to use your organization's default, or set it to cover a particular region's hours.
• Email mailbox. Assign the worker a Backbuild Mail mailbox so it can work an inbox and, once you allow it, send from a real address. You can assign a mailbox at hire time or hire now and assign one later.

The Runtime: Size and Execution Mode

After this section you will be able to choose how much computer a worker gets and how it runs. Under Runtime you decide the machine and the mode:

• Container size. Small, Standard, or Large. This is the size of the on-demand container a worker operates when it does hands-on work. Larger sizes draw more credits while running; start Small and raise it only when a task needs it.
• Execution mode. How the worker carries out a task:
  • In-app assistant. The worker runs on the platform's AI over your usage credits, with no container to configure. This is the simplest mode and the right default for support and inbox work.
  • Coding agent (container). The launch target lets the worker run Claude Code, Codex, Gemini CLI, Kimi Code, Cursor Agent, or Devin CLI inside a real container, using the exact account paired and stored in the chosen vault item. This expanded matrix and restore workflow is being completed and verified on the development environment; it is not a claim that every connection is released yet. This is the mode for hands-on code work. Pair every available agent the worker may use; the launch-target relaunch flow restores all paired agents and leaves the rest unconfigured. See AI Connection and Budgets.
  • Hybrid. The worker can do both: light in-app work and container-backed coding work, choosing per task.

Operating Instructions

After this section you will be able to tell a worker how to do its job. Under AI settings, the Operating instructions field is an optional system instruction the worker follows on every task, up to twenty thousand characters. This is where you set its tone, its boundaries, and the specifics of your process: how to greet a customer, what it must never promise, when to escalate to a human rather than answer, and which of your policies apply. Clear operating instructions are the single biggest lever on whether a worker's drafts read the way you want, so write them the way you would brief a new hire.

The Schedule: Shift and Holidays

After this section you will be able to set a worker's working hours and days off. Under Scheduling you give the worker human-style hours:

• Work days. Toggle the days Monday through Sunday the worker is on shift.
• Start and end. The daily hours it works, read in the worker's timezone. Off those hours the worker is off shift and does nothing unless a task was explicitly scheduled.
• Start and end offset. An optional small randomized jitter (exact, or plus or minus five, ten, or fifteen minutes) so the worker does not begin at the same instant every day.
• Holidays. Add specific dates, each with an optional label. On a holiday the worker is off shift for the whole day.

Shifts are how a worker gives you off-hours coverage without acting at times you did not intend. A support worker on an evening shift picks up tickets after your human team logs off; a worker with the weekend switched off simply waits until Monday. Work that arrives off shift is not lost: it queues and the worker takes it up when its next shift begins.

Sharing a Worker's Configuration

After this section you will know who else can see and manage a worker. Under Access controls, an owner or administrator shares a worker with the people and groups who should be able to view or manage it, using the same sharing scopes as the rest of the platform: a specific person, a group or department, a project, the whole organization, or a product package. Each share is either view or manage. This is how you let a support lead configure the support workers without handing them the keys to every worker in the organization.

Revising, Pausing, and Firing

After this section you will know that nothing here is permanent. Every field above is editable later in the same per-worker editor. From the editor you can also pause a worker, or fire it. Firing does not destroy a worker: it moves to the Deactivated tab and can be re-hired later with its configuration intact, so letting a seasonal worker go and bringing it back is a two-click act. Pausing, firing, and the approval controls are covered in Autonomy and Approvals.

Where to Next

• AI Connection and Budgets: connect the worker to usage credits or a provider account, and cap its weekly spend.
• Autonomy and Approvals: decide, per capability, what the worker may do on its own and what always needs a person.
• Support Workers: put a hired worker to work on your help desk.
• Developer Workers: put a hired worker to work on code in a container.