Why our agents ask permission - and still run unattended

ChaseInTech — Fri, 14 Aug 2026 14:47:27 +0000

Every agent product is sold on how little you have to supervise it. That is exactly backwards.

There are two kinds of AI tool on the market right now, and neither of them is usable for work that matters.

The first kind makes you supervise every step. You paste context into a chat, it produces something, you paste the result somewhere else, and tomorrow you explain your own project from scratch again. Nothing accumulates. Nothing runs while you sleep.

The second kind promises to do everything for you. It is given broad tool access and told to go. It usually works impressively for a demo, and then does something you cannot inspect, to a system you cannot easily roll back, for reasons you cannot reconstruct.

We wanted the thing in the middle, and the middle turns out to be a governance problem rather than a model problem.

The constraint that makes autonomy usable

Ask yourself what actually stops you leaving an agent running against your real work. It is almost never capability. It is that you cannot answer three questions afterwards: what did it read, what did it change, and what did it try to do that it should not have.

So in ChaseOS every run is bounded before it starts, not judged after it finishes:

A runtime profile declares what a lane may read, draft, run and escalate.
A scoped task packet carries only the graph context relevant to that one job, not your whole workspace.
Sensitive actions — publishing, external sends, protected writes, changes to approved state — stop at an approval gate.
Every run writes an audit record: what it used, what it produced, and what it was blocked from doing.

Governance is not the limit on autonomy. It is the precondition for it.

Once those four things exist, leaving an agent running stops being a gamble. That is the point at which unattended work becomes reasonable rather than reckless.

What unattended actually means here

This is the part people assume is marketing, so to be specific: agents in ChaseOS tool-call and move across a project, and they run on a schedule you set. OpenClaw runs natively on Windows with its own cron plane. Hermes Agent runs in WSL, and Studio can start Ubuntu for you with your approval. Scheduled work is live on the Pro tier today.

They run on your machine. Not on our servers.

That last sentence is usually treated as a limitation to apologise for. We think it is the feature. Your project context is the most sensitive thing you own as a builder, and the default should not be shipping it somewhere else so that someone can bill you for compute.

What is not built: agent fleets, hosted runtimes, encrypted sync and GPU compute are on the roadmap, not in the product. The status page lists them as planned.

The uncomfortable trade

Approval gates cost you moments of friction. A fully autonomous agent that never asks is genuinely faster, right up until the first time it is wrong in a way you cannot see.

We took the friction. Not because autonomy is dangerous in the abstract, but because unaccountable autonomy is unusable in practice, and an agent you cannot audit is an agent you will eventually stop trusting with anything important.

The measure of a system like this is not how little you supervise it. It is how much you can safely let it do while still being able to prove what happened.

ChaseOS Studio is available now for Windows 10 and 11. The Community tier is free, fully local, and the whole local product rather than a trial.

Explore the workspace, see how approval-gated agents work, and download the signed Windows app: Start using ChaseOS Studio.

DEV Community: ChaseInTech

Why our agents ask permission - and still run unattended

The constraint that makes autonomy usable

What unattended actually means here

The uncomfortable trade