Atlas

It starts as one container.

Atlas and a Postgres you already know how to operate. Point ATLAS_PUBLIC_URL at the origin you serve from, and the first account created becomes the administrator.
Deploying Atlas
```
# generates .env with fresh secrets, builds, starts, waits
$ make dev

# stops the stack and every agent sandbox it started
$ make down
```
Then a thread asks for somewhere to work.

Every thread gets its own sandbox, started on demand and paused when it goes idle. The browser never talks to one directly: it reaches the control plane, and the control plane reaches the container.

Deploymentone origin
Every request it makes gets a decision.

An agent asks for a title and for a migration with the same API, and paying frontier prices for both is how an agent product gets expensive without getting better. Heuristics name the task, a cheap model settles the ambiguous cases, and the work goes to a model that suits it.

Classify
What kind of work is this?

Score
Which models can do it?

Route
Send it, and record why.

X-Atlas-Mode auto X-Atlas-Task resolving X-Atlas-Decided-By pending X-Atlas-Tier pending
And a leaked sandbox id is worth nothing.

Sandboxes have no published port and no route of their own. Reaching one means going through the control plane, which authenticates the caller and checks the sandbox belongs to an organization they are in. WebSocket upgrades take the same path, so the agent's event stream is not a back door.

That is the whole product.

MIT licensed, multi-tenant from the first row, and yours to read before you run it.