Builder vs Office
How builder and office workflows differ on the platform.
Office is knowledge work. Builder is code work. Same Queen Bee, same agents, different default tooling.
When you start a task in Busy Bee, the chat input quietly picks between two modes, Office and Builder. The mode determines what tools agents reach for, whether a sandbox spins up, and which approvals are required before work ships. For 90% of cases, the inferred default is right; the other 10% are worth knowing about.
Office mode
The default for most non-code work: research, writing, design briefs, analysis, ops.
What agents have access to:
- Web search, web fetch, image generation.
- Knowledge bases and uploaded documents.
- Datasets via SQL (DuckDB).
- All connector-backed tools (Slack, Notion, Google Workspace, etc.).
- Task and workflow tools.
What doesn't happen:
- No sandbox is provisioned per task.
- No GitHub write operations.
- No code execution beyond the daemon's own data tools.
Office mode is light, fast, and cheap. Most chat input requests default to it.
Builder mode
The mode for code-touching work: feature builds, bug fixes, refactors, deploys.
What agents have access to:
- Everything Office mode has, plus:
- A provisioned sandbox per task - a real Linux container with a writable filesystem, package manager, and network access.
- GitHub tools - read repos, open branches, push commits, open PRs, leave reviews.
- Code execution inside the sandbox.
- Live preview - the sandbox serves the work-in-progress at a URL you can click.
What's required:
- The task's project must have a linked GitHub repo.
- Production deploys require an explicit approval (see Deployment).
- Sandbox time consumes credits while active.
Builder mode is heavier, slower to start (sandbox provisioning) and more credit-intensive, so Busy Bee only switches into it when the work needs it.
How the mode gets picked
When you submit a request, the chat input looks at:
- The selected starter chip - chips like "Build a feature" force Builder; chips like "Research" force Office.
- The prompt content - code-shaped requests ("fix the bug in...", "add an endpoint to...") trigger Builder mode.
- The project's defaults - projects with a linked GitHub repo lean Builder; others lean Office.
You can override the picked mode in the task creation modal if the default is wrong.
A side-by-side
| Office | Builder | |
|---|---|---|
| Default for | Research, writing, analysis | Code, deploys, refactors |
| Sandbox | None | Provisioned per task |
| GitHub writes | Read-only | Full access |
| Live preview | No | Yes |
| Cost per task | Lower | Higher |
| Approval gates | Standard task approval | Plus deploy approval |
When to think about it
Mostly you don't have to. The picker is right almost all the time. The two cases where it matters:
- You're asking an Office agent to do something code-shaped and it's struggling. Switch to Builder mode - it'll have the tools.
- You're asking a Builder agent to do something pure-knowledge and it's spinning up sandboxes you don't need. Switch to Office mode - it'll be faster and cheaper.
What's next
For the deploy half of Builder mode, see Deployment. For more on tools each mode unlocks, see Tools.