Production agents need a gate, not a free loop
A clear mission is not enough if the agent can write, shell, and finish work you cannot undo. How to narrow grants, pull dangerous steps out of the loop, and read soot check --show before you run.
A clear job is the right start. It is not enough. If the agent can write files or run a host shell, a bad step can finish while you are still reading the stream. You can Stop a run. Completed actions stay completed.
That is the production problem, not “the model was slightly wrong.”
A free loop is a bad shape for anything you cannot undo
Amatya Joshi argues that an autonomous loop is brittle once it sits on a real system, and that work should move through controlled steps instead of an unsupervised run. You do not need a productized state machine to take that seriously. You need a human at the step that deletes, overwrites, or ships.
Sweden’s TV4 postponed The Challenge until 2027 after a technical failure erased edited footage. The report names a technical failure, not a product. The operator lesson is still blunt: once the erase finishes, there is nothing left to Stop. Hacker News treated it as a warning about tools that can destroy work faster than a person can intervene.
Soot does not ship a built-in state machine. What it does give you, today, is a place to draw that line yourself.
What Soot actually lets you control
Soot is a preview. One Soot is one mission plus the tools you explicitly allow. You choose the access. You can Stop a run; finished work is not rolled back. The workspace is not an OS sandbox. Host tools run with the host’s OS rights.
That last point matters more than the mission text. Default soot spawn creates a general Soot with write and host-shell grants. It is not read-only. If you spawn first and think later, you already handed the agent a way to change the machine.
Narrow it, or start empty:
soot spawn my-work --empty
cd my-work
soot check --showRead the grant list before the first soot run that can touch a real file. Use --secrets only when you need to verify how credentials are wired — and do not paste that output into a ticket or a chat.
If check --show lists write or host-shell and this run does not need them, take them off. A planning Soot does not need a shell. A review Soot does not need write.
Pull the dangerous step out of the loop
Keep the autonomous part on work you can throw away: read, summarize, draft a plan, list the files it *would* change. Put the apply step in a separate Soot — or in your own hands — that you start after you have read the plan.
A practical split:
- Scout. Empty or read-only grants. Mission: list the files this change would touch and the command you would run. Do not write. Do not execute.
- You. Read that list. Reject it, trim it, or approve it.
- Apply. A second Soot with write/shell, or you, running only the approved command. Short mission. No “and then clean up whatever looks unused.”
soot run "List the files this change would touch and the exact command you would run. Do not write. Do not execute."That is the approval gate. It is not a feature name. It is you refusing to let delete, overwrite, or deploy live inside an unsupervised loop.
If you only remember one Soot fact: Stop does not undo a delete that already landed.
After it is live, “the run finished” is not a test
Agents that crash are easy to notice. Agents that only fail in production are worse: the run looks fine, the file is wrong, and the wrong file is already the source of truth. Check the artifact, not the exit. Diff the files. Keep a copy you did not hand the agent.
If you are choosing a first real workflow, keep it narrow enough for one week and give it a review criterion you can apply without trusting the agent. A wide “operate production” mission has no such criterion.
Before you run it near real files
- One Soot, one job, written as an outcome — not “help with the server.”
soot check --showuntil you can name every write and host-shell grant.- Dangerous commands live outside the unsupervised loop.
- You accept that Stop will not roll back a finished action.
Soot is preview. If you want the installer list as it stands today, see trysoot.com/download (unsigned desktop builds). For how missions, grants, and soot check fit together, start at the docs.