Agent computer

Every session gets its own computer.

Your project and tools are ready from the start, so the agent can work without using your laptop.

Boot sequence

A session starts. A machine boots.

Your project, tools, and setup are ready before the agent begins.

  1. 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.

  2. 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.

  3. 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.

  4. 03

    OpenCode starts

    OpenCode 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.

Full control

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.

Parallelism

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.

main
  • 9f4c2b7erewrite the pricing pagechange request
  • 2a71d0c4reconcile the july invoiceschange request
  • c83e5f19draft three launch threadsdiscarded
  • 5db60a37triage the support backlogrunning
  • and every other session you start, each on its own machine

change requestmain

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.

Declared in the repo

The machine is a file in your project.

Choose the tools and resources each agent needs once. Every new session uses that setup automatically.

singulacomp.yaml
# the machine every session of this project bootssingulacomp_version: 2runtime: opencode 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
inside the agent computer
# 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"$ singulacomp cr→ change request opened toward main
Everything is files

grep your whole company.

Your agents, instructions, and shared knowledge stay in files you can read, change, and track.

  • your-company/
  • singulacomp.yamlsandbox image, triggers, channels, connectors, secrets
  • .singulacomp/opencode/the runtime your agents think in
  • agents/one OpenCode 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.

Isolation

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 SingulaComp’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.

Run your whole company from one repo you own.

Start with one job and grow from there.

Get started