POSITROM AI 如何使用專屬 Linux 桌面和終端完成任務

Most assistants stop at text. They answer, you copy, you paste, you do the work. We wanted the opposite: an agent that gets its own computer and does the task itself. This is a walkthrough of how that works in practice: how an agent operates a private Linux desktop and terminal, and how it proves that it actually finished.

Why text-only wasn't enough

Ask a chat assistant for "a Word report from these three websites" and you get a wall of text. The real task has more parts: open the pages, extract what matters, write a file in the right format, check that the file exists and opens, then tell you where it is. Those are actions on a machine, not sentences.

So the agent gets a machine. One private Linux computer per user, with a graphical desktop, a terminal and a file manager.

The workspace: four tabs

The user watches the agent through four views of the same machine:

• Agent: the conversation and the step-by-step log.
• Terminal: the shell the agent types into.
• Files: the agent's working folder, where results land.
• Computer: the live graphical desktop, in the browser.

The Computer tab matters more than we expected. A log tells you what the agent claims it did. A live desktop lets you see it. Trust comes much faster from the second.

The loop: plan, act, verify, report

Every task runs through the same four phases.

1. Plan. The agent splits the request into small steps and picks the tool for each one: browser for reading pages, shell for scripts, a document library for Word/Excel/PDF output.

2. Act. It executes one step at a time on the desktop or in the terminal. Each step has a hard cap, and the whole run has a step limit (25 steps per run) so a confused agent can't spin forever.

3. Verify. This is the phase that separates an agent from a chatbot. After writing a file, the agent doesn't say "done". It checks:

ls -la ~/results/report.docx          # does it exist, is the size plausible?
python3 -c "import docx; d = docx.Document('report.docx'); print(len(d.paragraphs))"

If the file is missing, empty or unreadable, the agent goes back to the act phase instead of reporting success.

4. Report. The final message says what was produced, where it is, and anything it could not do. The file is in the Files tab, ready to download.

Long outputs: write in chunks

Our first version tried to write a ten-chapter document in one go. Long generations got cut off in the middle, and the file was silently truncated. The fix was boring and effective: write the document in parts, appending each chapter to the file, then run the verify step on the whole thing and retry any part that is missing. Chunked writing plus verification turned a flaky feature into a dependable one.

Isolation as a principle

Each user's machine is theirs alone: their own disk space, their own processes, their own files. A user only ever sees their own machine, and the agent can only touch what is inside it. We treat that as a product rule, not an optimization. If an agent can run arbitrary commands, the blast radius of a mistake must be one user's sandbox.

Mobile

Not every task starts at a desk. There is an Android app where you give orders by text, voice or attachment and then check the result later, from the same files the desktop sees.

What we learned

1. Verify outputs, don't trust them. Checking the file is cheaper than apologizing for a broken one.
2. Chunk anything long, and retry on failure.
3. Show the real desktop. Visibility is the cheapest trust feature there is.
4. Keep the chat input pinned and the header collapsible; the conversation needs the screen.

Try it and tell us what breaks

This is the idea behind POSITROM AI: a bot that gets its own private Linux computer and finishes tasks there while you watch. If you want to try it, it's at positrom.com. I'm on the team, and I'd like to know which task you'd hand it first and what would stop you from trusting it.