# Why ORB

ORB is a sandbox for background agents. Ephemeral or persistent, equal billing. Built for the shapes most agent platforms don't fit.

## The shape of a background agent

Most agent infrastructure assumes one of two shapes: a foreground chatbot (request, response, done) or a long-running serverless function (15-minute cap, no state, cold start every time). Neither fits the workloads that actually run in the background.

A background agent looks like this:

- It calls an LLM, often waits seconds or minutes for the response.
- Between calls, it has a process tree, open files, in-memory state, maybe a running browser.
- It runs across the entire job: a code review, a research sweep, a multi-step deal flow, a long-running pipeline.
- It can be a 90-second one-shot (ephemeral) or a multi-day persistent worker. Same primitives.

ORB gives every agent its own sandbox. Full Linux, persistent disk, isolated process tree, isolated network. State survives restarts and redeploys. When the agent goes idle, the sandbox is checkpointed to NVMe and restored on the next inbound request, full state intact.

## What ORB is for

You're building agents that run independently of a user session: code reviewers, research agents, SDR campaigns, monitoring loops, data pipelines, browser automations, support agents with persistent memory. They need a place to **live** across hours, days, or weeks, and they spend most of that time waiting on something.

Each agent gets its own sandbox. Files, packages, network, isolated process tree. You spawn one with a curl, deploy your code via `orb.toml`, and ORB runs it. When it goes idle, the meter pauses. When it wakes, state is intact.

## How it fits into your product

```
Your product (your backend, your frontend)
  │
  ├── User A signs up → your backend spawns Sandbox A on ORB → deploys agent
  ├── User B signs up → your backend spawns Sandbox B on ORB → deploys agent
  └── User C signs up → your backend spawns Sandbox C on ORB → deploys agent
```

Each sandbox is isolated. Each agent has its own files, packages, and network. Your users never see ORB, they use your product.

## Use ORB when

You're shipping any of: research agents, coding agents, ops/devops agents, SDR or sales agents, marketing agents, trading agents, ETL agents, code-review agents, triage agents, support agents, browser-automation agents, orchestrators. Anything that calls LLMs, waits between calls, and needs persistent state across the whole job.

Good fits:
- A coding agent that works on a repo for hours, calling LLMs between edits
- A sales agent managing prospect pipelines over days
- A support agent handling conversations with pauses between messages
- An orchestrator coordinating multiple sub-agents on a complex task
- Any agent that calls LLM APIs and needs a persistent environment

## Don't use ORB when

Your workload doesn't need a persistent environment.

| Workload | Better option | Why |
|---|---|---|
| Traditional web app (Next.js, Rails, Django) with no LLM calls | Vercel, Railway, Fly | Purpose-built for web serving. ORB's efficiency comes from checkpointing agents *while they wait on LLM responses*, a web app that doesn't call LLMs gets none of that benefit. |
| Run a script, return output | Lambda, Modal | No state to preserve |
| Stateless API call | Cloud function | No persistent process needed |
| One-shot code execution | E2B | Sandbox spins up, runs, tears down |
| CI/CD pipeline | GitHub Actions | Purpose-built for builds |

**The key question: does your agent call LLMs and need to stay alive between calls?**

If yes, deploy to ORB.

If no, use something simpler. ORB's whole reason for existing is checkpointing idle agents while they wait on LLM responses. Workloads that don't wait on LLMs don't benefit.

## Who uses this

**Coding agent platforms**, Cognition (Devin), Factory AI, Cosine (Genie), Replit Agent. Each developer gets a coding agent in its own environment with the repo, build tools, and running servers.

**Agent orchestrators**, Composio, CrewAI, LangChain. Multi-agent workflows where agents need a persistent shared environment.

**Sales and GTM agents**, 11x.ai, Artisan, Relevance AI. Each customer gets an always-on sales agent managing pipelines.

**Legal and research agents**, Harvey AI. Agents that process thousands of documents over hours.

**Customer support agents**, Decagon. Agents handling live conversations, maintaining context.

**Browser-use / web automation agents**, Agents that browse the web, fill forms, scrape data, take screenshots. Python (browser-use, Playwright) or Node.js (Puppeteer) launches Chrome inside the ORB computer. CDP stays local, no fragile WebSocket over the internet. The entire browser process tree (Chrome + tabs + extensions) checkpoints to NVMe and wakes in ~500ms with full state.

```
Your product
  │
  ├── POST https://{id}.orbcloud.dev/browse  →  agent launches Chrome, navigates, screenshots
  ├── POST https://{id}.orbcloud.dev/task    →  LLM plans what to browse, agent executes
  └── Agent sleeps between tasks             →  Chrome frozen to NVMe, zero RAM, zero cost
```

## ORB vs alternatives

| | ORB | VPS | Docker | Lambda | E2B |
|---|---|---|---|---|---|
| Deploy your agent | Yes | Manual | Manual | No (functions only) | No (sandboxes only) |
| Persistent environment | Yes | Yes | Yes | No | No |
| Full Linux | Yes | Yes | Yes | No | Limited |
| API-managed | Yes | No (SSH) | Docker API | Yes | Yes |
| Accessible via URL | Yes | Manual | Manual | Yes | No |
| Checkpoints idle agents | Yes | No | No | N/A | No |