Why build another agent workspace

Open any model provider’s page and you get a box you can chat with. The box was never the problem.

Real work looks like this: read a few files, run the tests, see the failure, change the code, run them again, then paste the log to a model and ask what happened. Every step can be accelerated by AI — but the context keeps getting lost in transit. What you copy and paste and what the model actually needs to see are different things.

The missing half is execution

A text-only assistant leaves execution to you: run the commands, manage the working tree, clean up temp files, remember where you were. “AI writes my code” becomes “I execute code for the AI”.

A workspace fills that half:

• Sessions hold state. Messages, tool calls and artefacts share one context, so you are not re-explaining yourself.
• Tools have real side effects. Reading files, running commands, starting servers and taking screenshots happen in an isolated environment.
• Failures can be retried. Errors enter the context with real exit codes and stderr, not your paraphrase of “it seemed to break”.

Why a sandbox, not your machine

The cheapest option is to run commands locally. We did not, for three reasons in order of importance:

1. Safety. Model-generated commands should not inherit your home directory.
2. Reproducibility. Same image, same dependencies, same result on any machine.
3. Disposability. When a task goes wrong, throwing the environment away is usually the correct move.

Sandboxes start on demand and are reclaimed when the task ends; a session owns its files, and the files follow the session’s retention window. That is a different product from “a long-lived dev box”.

Why we kept the no-sandbox path

Not every task deserves a container. Looking up docs, editing a paragraph, explaining a stack trace — if those wait thirty seconds for an environment, the product is unusable.

So both modes coexist: a session may or may not bind a sandbox. When to escalate should be decided by the task, not by a wizard.

What we deliberately skipped

No visual workflow editor. Drawing agents as a DAG is beautiful, but real tasks branch while they run: tests fail, you go back, they fail differently. A fixed graph ends up with twelve nodes where each run uses three.

No plugin marketplace for skills. A skill is a file first: instructions, a few scripts, optional assets. It lives in a repo, it diffs, it gets reviewed. A marketplace solves distribution, not execution.

No hidden tool calls. Every step shows input, output, duration, exit code. Trust comes from inspection, not from “the AI handled it”.

So what is it now

A self-hosted multi-agent runtime: sessions, agent configs, skills, MCP servers, sandboxes and an exchange space in one backend; the UI is just one view onto it. You can run the whole flow on the free public pool, or bring your own key and keep both the cost and the model choice.

The next job is making multi-tenancy real — isolation, quotas, auditing — because a workspace that only works for a single user is a demo.