Every session gets its own computer.
Your project and tools are ready from the start, so the agent can work without using your laptop.
A session starts. A machine boots.
Your project, tools, and setup are ready before the agent begins.
- 00
The machine comes up
A Linux machine boots from the sandbox image your project declares. It is its own isolated machine: its own filesystem, its own process table, its own network. Nothing is shared with another session.
- 01
The repo clones
The machine clones the project repo into /workspace. Your agents, skills, memory, connectors and triggers arrive with it, because all of them are files in that repo.
- 02
A fresh branch is cut
The machine cuts a branch named after the session. Every edit, commit and stray file the session produces lives on that branch and nowhere else.
- 03
Nimind Code starts
Nimind Code runs inside the machine as the agent harness, with your models, your tools and your secrets injected at runtime. The machine is ready. The agent begins.
Install anything. Run anything. Break anything.
Your agent can use the tools it needs, just as it would on a regular computer.
It is disposable
Nothing on the machine is precious. A bad install, a wrong migration, a wiped directory — the machine goes away and takes it with it. Only what the agent commits survives.
It arrives ready
The repo is cloned, the tools are installed and the dependencies are resolved before the agent starts. There is no setup step, and no local machine is involved at any point.
It keeps running
Long work does not depend on your tab. Close the laptop and the machine keeps going; open the session tomorrow and the work is where the agent left it.
Hundreds of thousands of computers. One main.
Run many agents at once without mixing up their work. You review every result before it joins your main project.
- 9f4c2b7e…rewrite the pricing pagechange request
- 2a71d0c4…reconcile the july invoiceschange request
- c83e5f19…draft three launch threadsdiscarded
- 5db60a37…triage the support backlogrunning
and every other session you start, each on its own machine
Two agents edited the same file? git has handled that for twenty years. It is a merge. Nothing reaches main without a person approving it.
The machine is a file in your project.
Choose the tools and resources each agent needs once. Every new session uses that setup automatically.
# the machine every session of this project bootsnimind_version: 2runtime: nimind code sandbox: default: python templates: - slug: python name: Python 3.12 image: python:3.12-slim cpu: 2 memory: 4 disk: 20 agents: researcher: # this agent gets the python machine sandbox: python# the repo is already here. nothing to set up.$ pwd/workspace # the branch is named after the session$ git branch --show-current9f4c2b7e-1d83-4a6f-b0c2-5e71a9d4c188 # root on a real machine — install whatever the job needs$ uv pip install pandas duckdb$ python analyze.py > report.md # only what it commits survives the machine$ git commit -am "add the q3 revenue report"$ nimind cr→ change request opened toward maingrep your whole company.
Your agents, instructions, and shared knowledge stay in files you can read, change, and track.
- your-company/
- nimind.yamlsandbox image, triggers, channels, connectors, secrets
- .nimind/nimind code/the runtime your agents think in
- agents/one Nimind Code agent per file
- skills/how this company does a specific job
- commands/the shortcuts everyone shares
- plugins/the tools you wrote yourself
Every change has a diff
An agent rewriting its own prompt shows up the same way a code change does: a commit, on a branch, in a change request someone reads.
The company is clonable
The repo is the company. Fork it, branch it, roll it back, or hand it to a new machine — the whole configuration comes with it.
Walled off by default.
Each agent works separately, so one session cannot interfere with another.
- One machine per session
- Sessions never share a filesystem, a process table, or a network namespace. On Nimind’s own Platinum compute the boundary is a Cloud Hypervisor microVM; Daytona and E2B are also supported, and we will tell you which one you are on.
- Two gates on every secret
- A runtime secret reaches a session only through the intersection of the agent’s declared grant and the role of the person who started it. Once delivered it is a real environment value, because that is how a tool uses it — we would rather say so than call it invisible.
- Connectors brokered server-side
- 3,000+ apps in a click, plus MCP, OpenAPI, GraphQL and raw HTTP, reached through one scoped token brokered outside the machine.
- Nothing merges itself
- Work reaches main only through a change request a person reviews and approves. The machine can propose. A human decides.