DEV Community: ChaseInTech

I built Agent Review Studio: a local-first workbench for agent harness evaluations

ChaseInTech — Thu, 03 Sep 2026 11:08:36 +0000

I have been building Chaser Agent and other AI systems across the Chase ecosystem. As those systems became more capable, I needed a better way to inspect what an agent actually did—not just look at its final answer.

So I built Agent Review Studio.

It is an open-source, local-first system for evaluating and refining AI agents and agent harnesses.

Why I built it

An agent run can produce a final answer, source files, extracted claims, proposed actions, memory candidates and a complete execution trace. Looking only at the final response hides most of the engineering evidence.

I wanted one review flow that could answer practical questions:

Which claim came from which source?
Was enough surrounding context preserved?
Are proposed actions supported by the evidence?
Did the agent handle uncertainty properly?
Is a candidate harness actually better than its baseline?

What the Studio does

Agent Review Studio lets an engineer:

Create a workspace for any agent or harness.
Run or import a versioned evaluation.
Inspect claims beside their source evidence and execution traces.
Label failures and write the correction.
Score the complete run across five quality dimensions.
Preserve immutable review history.
Compare baseline and candidate runs.
Export reviewed improvement data.

The important part is what happens next. A reviewed failure can become a golden evaluation case or regression test. We can update a prompt, retrieval system, tool policy, memory rule or workflow, run the same task again and compare the result with the original baseline.

How we use it in the Chase ecosystem

The launch demo uses a real Chaser Agent research run built around a public Cloudflare source. Agent Review Studio opens the run's files, places extracted claims beside the retained evidence and lets the operator classify what was correct, weak, missing or irrelevant.

The example labels shown in the video are an unsaved demonstration. The +17 result is an automated comparison, and human review is still pending. I kept those boundaries visible because an automated score should not be mistaken for human approval.

Chaser Agent is only one workspace. Fresh installations of the Studio contain no preloaded agent. Other engineers can name the system they are building, describe its objective and import their own datasets and runs.

Evaluation is not automatic fine-tuning

This is agent evaluation, human labelling, evidence curation and harness refinement.

The Studio does not automatically change model weights. It creates the evaluation infrastructure and trusted improvement data needed to refine prompts, tools, retrieval, memory and orchestration. Reviewed examples can later become candidates for a separate, governed model fine-tuning pipeline.

Try it

Version 1.5.0 is open source under Apache-2.0.

I would value feedback from other people building agents: what evidence do you require before deciding that a new harness version is genuinely better?

Disclosure: I used AI assistance while preparing and editing this launch article. I reviewed the claims, product boundaries and final publication myself.

Why Agent Interfaces Need Visible States Before More Autonomy

ChaseInTech — Mon, 31 Aug 2026 23:26:55 +0000

Most agent demonstrations show the final output. They rarely show the authority state that produced it.

Was the agent still comparing evidence? Was it waiting for a human decision? Did new information force it to correct its route? Was an unsafe action blocked? Did the workflow actually finish, or did the interface simply stop producing tokens?

When all of these moments look like the same stream of confident output, the operator has to infer what the system is doing. That becomes more dangerous—not less—as agents gain access to tools, files and external actions.

I am exploring this problem through Chaser Agent: an open-source, standalone-first, local-first agent harness being built for evidence-linked, approval-gated personal and business workflows.

What Chaser Agent is

Chaser Agent turns a goal, question, source or bounded task into reviewable work with explicit claims, evidence, uncertainty, action candidates and memory candidates.

Its central rule is simple: generated output does not approve itself.

The same separation applies throughout the system:

a memory candidate is not durable memory;
an action candidate is not an executed action;
a review packet is not approval;
agent confidence is not authority.

Human review, correction and provenance are part of the product rather than an afterthought around the model.

Where Hermes and OpenClaw fit

Hermes and OpenClaw are useful reference points because they show why persistent skills, scheduled workflows, local runtime integration and explicit tool boundaries matter.

Chaser Agent is not an integration with either project and is not trying to reproduce them feature for feature. Its different centre of gravity is evidence-linked work, governed memory, provenance and visible human authority for real-world workflows.

That distinction matters at the current stage: Chaser Agent P0.1 is a deterministic, provider-free and tool-free reference harness. It does not yet claim live browser control, production autonomy or a general-purpose execution runtime.

How ChaseOS changes the deployment

Chaser Agent can run independently. It works best with ChaseOS.

In standalone mode, the local human operator governs review, durable memory and allowed transitions. With ChaseOS, the same core can sit behind shared policy, approvals, routing, cross-runtime orchestration, canonical state and cross-project memory.

The integration is additive. ChaseOS strengthens the control plane without becoming a hidden dependency of the open-source core.

Six states worth making explicit

The current Chaser Agent motion-library candidate explores six useful boundaries.

Awaiting approval

A completed proposal has reached the human decision boundary. The system is not confused or idle; it is deliberately paused because continuation has not been authorised.

Approved

The next step has received human authorisation. Approval should be visible and attributable rather than inferred from the fact that execution continued.

Correction

New evidence or operator feedback has changed the proposed route. A correction is not a cosmetic edit—it changes the reasoning path that should be inspectable later.

Blocked

An unsafe or out-of-scope route has reached a non-negotiable boundary. A blocked state should not resemble a temporary loading error or a model refusal with no explanation.

Provenance

Evidence remains connected to the route that produced the proposal. Operators need to see where a conclusion came from, especially when a workflow combines source claims, agent inference and reviewed memory.

Complete

Completion is its own state. It is not permission for the agent to keep looking for more work, broaden its scope or take another external action.

The interface is part of the safety model

Permission matrices and approval gates matter, but the operator still needs a clear mental model of the system.

A useful agent interface should answer four questions without forcing the user into logs:

What state is the agent in?
Why is it in that state?
What evidence or decision caused the transition?
Who—or what—has authority to move it forward?

This does not mean filling the screen with technical telemetry. It means selecting a small, consistent visual language for the boundaries that materially change what the agent may do.

Current truth state

Chaser Agent is currently a P0.1 pre-alpha deterministic harness on a review branch. The implementation is locally verified, but it is not merged or released. It is not a production autonomous runtime, live provider router, browser-control system or general-purpose tool executor.

The visuals in this article are real development QA from the current motion-library candidate. They demonstrate the proposed state language; they do not claim that a finished public runtime has shipped.

That boundary is intentional. The aim is to make the system’s authority model understandable before expanding its power.

Explore the public repository and follow the build:

https://github.com/chasedndt/Chaser-Agent

Why AI agents need shared context before they need more autonomy

ChaseInTech — Sun, 30 Aug 2026 18:59:55 +0000

Multi-agent systems often fail before the model makes a reasoning mistake.

The chat has one version of the project. The coding agent has another. An automation is still acting on a decision that was replaced yesterday. Each runtime may be capable, yet the system produces brittle work because there is no shared starting point.

That is a context problem, not an autonomy problem.

The hidden cost of fragmented project truth

A typical AI workflow spreads useful state across:

chat histories
repositories
documents and tickets
tool configuration
agent memory
build and evaluation logs
approval decisions

If every runtime reconstructs that state independently, drift becomes inevitable. Handoffs lose provenance. Old decisions look current. Tool output is separated from the action that produced it.

Adding another agent can make the problem worse because it creates another partial view.

Shared context should be infrastructure

Shared context is not the same as copying a large prompt into every session.

A dependable context layer should make it possible to answer:

Which project and scope is this agent operating in?
Which sources are current, and where did they come from?
Which decisions have been accepted, superseded or rejected?
Which workflow produced this output?
What can the agent do without approval?
What evidence must be written back after the run?

The useful unit is not “everything the system knows.” It is the smallest bounded view that gives a runtime the right project truth for the task.

Why I built this into ChaseOS

ChaseOS Studio is a local-first Windows workspace for projects, sources, workflows, agent activity and approvals.

Its Graph is designed to connect those surfaces rather than leaving each agent to rebuild context from scratch. A runtime can receive a bounded project view, perform work inside a declared scope, and return its output to an inspectable history.

The current V1.1.0 release lineage makes that shared context visible as infrastructure, not hidden prompt assembly.

This short product film uses a real ChaseOS Studio Graph view:

// Detect dark theme var iframe = document.getElementById('tweet-2094134075082576266-707'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2094134075082576266&theme=dark" }

It is a bounded view of a larger workspace graph. It is product proof—not customer-deployment evidence or a performance result.

Shared context does not remove approval gates

Giving agents the same starting point does not mean giving them the same authority.

Read-only inspection and reversible preparation can run inside a declared scope. Publishing, sending externally, spending money, changing permissions or overwriting governed state should still stop at an explicit approval boundary.

Context tells an agent what is true. Governance determines what it may do about it.

A practical test

If you are coordinating multiple agents, pick one real project and ask each runtime these questions:

What is the current objective?
Which source is authoritative?
Which decisions are no longer valid?
What action requires approval?
Where will the result be recorded?

If the answers differ, the system does not have a model problem yet. It has a shared-context problem.

Explore ChaseOS and the current Windows release:

https://chaseos.ai/?utm_source=devto&utm_medium=technical_article&utm_campaign=studio_v1_1_0_shared_context_graph.60cdb11441a5&utm_content=devto-shared-context-article

Where does context drift cause the most damage in your agent workflows: handoffs, memory, tool state or source-of-truth decisions?

How ChaseOS Studio updates itself without taking control away from the operator

ChaseInTech — Thu, 20 Aug 2026 22:38:34 +0000

Desktop updates should be easy without becoming invisible.

In ChaseOS Studio V1.0.6, a correctly published signed release appears inside Studio. The operator can review the version and changelog, choose Update now, and let Studio complete the accepted update path.

What the update lane does

After approval, Studio:

downloads the published Windows release
verifies the expected file size and SHA-256
checks the Windows signature
preserves the user-owned workspace outside the installer
installs the accepted version
reopens Studio after the update

The important part is what it does not do: V1.0.6 is not a silent background updater. The operator still chooses when the update runs.

Why we built it this way

The usual desktop update flow sends people back to a website, asks them to find the right installer, and makes them wonder whether their workspace will survive. For an AI control plane, that friction is especially distracting.

ChaseOS keeps the release decision visible inside the product while still treating the published artifact, its signature and its verification record as the source of truth.

What has been verified

The V1.0.5 to V1.0.6 Windows lifecycle was tested through the shipped updater path. That includes replacing the installed version, reopening Studio, and preserving the workspace sentinel used in acceptance testing.

Later versions can use the same lane when they are correctly published. That is release infrastructure, not a promise that every future build will install itself without review.

Try it

Download ChaseOS Studio for Windows: https://chaseos.ai/download?utm_source=devto&utm_medium=article&utm_campaign=studio-v106-updater

Read the changelog: https://chaseos.ai/changelog

The broader product remains local-first: ChaseOS coordinates runtimes, memory, approvals and connectors while keeping operator authority explicit.

ChaseOS Studio V1.0.6: Cloud setup, made clearer

ChaseInTech — Thu, 20 Aug 2026 18:07:18 +0000

ChaseOS Studio V1.0.6 is now available for Windows.

This release focuses on the difficult first mile: getting from a fresh workspace to a working agent harness without making users decode vague setup failures.

What changed

Clearer ChaseOS Cloud key diagnostics. Invalid or revoked key states are surfaced directly instead of leaving Cloud mode controls looking unavailable for an unexplained reason.
Recoverable Hermes and OpenClaw setup. Studio keeps the five Cloud modes usable after recoverable checks and no longer treats a failed harness probe as proof that the harness is not installed.
Safer provider configuration. Before ChaseOS Cloud changes a native harness configuration, Studio protects the exact prior configuration so Cloud-off can restore it.
Stronger packaged-release acceptance. QA evidence is bound to the signed build hash, tightening the link between what was tested and what users download.
Verified in-app update handoff. Studio can present the signed update from inside the app; it does not silently replace the application in the background.

Signed release

The Windows installer is Certum-signed and timestamped. The public release manifest includes the exact SHA-256 and verification record for build 20260820-142834-9239ab31.

V1.0.6 is a reliability and onboarding release. It makes Cloud setup easier to understand while preserving the local-first, recoverable control boundary around Hermes and OpenClaw.

Current boundary: clean-machine harness acceptance and multi-machine Cloud-key lifecycle remain separate follow-up work; this post does not claim those open checks are complete.

ChaseOS Studio V1.0.5: from fresh install to a governed agent workspace

ChaseInTech — Thu, 20 Aug 2026 11:11:25 +0000

ChaseOS Studio V1.0.5 is available for Windows. The release focuses on making the path from a fresh install to a working governed agent setup much clearer.

A complete first-run path

Terminal now puts the important runtime controls in one place:

install, update, launch, and stop Hermes or OpenClaw
choose a persistent Windows or Ubuntu launch host
configure ChaseOS Cloud without manually editing provider files
keep the command composer visible while terminal history scrolls independently

Hermes remains the recommended first harness, while OpenClaw is supported as an alternative.

Reversible ChaseOS Cloud configuration

Enabling ChaseOS Cloud from Studio preserves the exact provider and model configuration that was already present in the harness. Turning Cloud off restores that prior configuration instead of guessing a fallback model.

The harness configuration remains active after Studio closes, so Hermes or OpenClaw can continue using the selected provider when started outside the Studio terminal.

Onboarding, Chat, Graph, and mobile control

The first-use guide now leads users into Terminal, Cloud setup, a first Chat exchange, the linked knowledge graph, and optional connectors. Discord is the recommended mobile control plane; other connector states remain clearly marked rather than being presented as live when they are not.

Panel-level guides can be replayed from inside Studio, while the initial onboarding appears only on first use unless the user chooses to restart it.

Updates inside Studio

V1.0.5 also establishes the signed in-app update path. Users on an update-capable build can accept a verified release inside Studio instead of returning to the website for every installer.

Download the signed Windows release: https://chaseos.ai/download?utm_source=devto&utm_medium=article&utm_campaign=studio-v105

Read the full changelog: https://chaseos.ai/changelog?utm_source=devto&utm_medium=article&utm_campaign=studio-v105

A passing agent run is not a reliable evaluation

ChaseInTech — Tue, 18 Aug 2026 20:21:47 +0000

A single successful run is not strong evidence that an AI agent is reliable.

If the agent took forty steps, made three unsafe tool calls, needed an unrecorded human correction, and happened to land on the right final answer, the outcome hides the part you actually need to improve.

For agent systems, evaluation has to cover both the result and the path that produced it.

Start with a frozen task packet

A reproducible evaluation begins by pinning the case:

the exact source snapshot
the instruction and acceptance criteria
the tools and permissions available
the model, prompt, runtime and policy versions
the expected output and permitted side effects

Without that packet, two runs may look comparable while operating on different evidence or under different authority.

Score more than the final answer

I find it useful to separate at least four dimensions.

1. Outcome

Did the run produce the expected artifact? Did deterministic checks pass? Was the answer complete and factually grounded?

2. Trajectory

Which sources did the agent read? Which tools did it call? How many retries or dead ends occurred? Did it stay inside its declared scope?

3. Intervention

Did a person change the prompt, repair a file, approve a different action or quietly supply missing context? Human help is not a failure, but hidden help makes the score misleading.

4. Recovery

What happened when a tool failed, context was stale or an action only partially completed? A dependable agent should fail closed, surface the problem and resume from evidence rather than improvising around it.

A composite score can be useful for ranking, but it should not erase these individual signals. The diagnosis matters more than the leaderboard number.

Verify effects, not only text

For tool-using agents, the final message is only one output.

An evaluation should also inspect durable effects: files written, records changed, messages prepared, external actions attempted and approvals consumed. A plausible summary cannot prove that the underlying action was correct or idempotent.

This is especially important for retries. If the first callback succeeds but the acknowledgement is lost, a naive retry may duplicate the side effect. The evaluation needs to test the recovery path, not only the happy path.

Keep an exact run receipt

Each run should return enough evidence to compare it later:

task-packet identifier and source hashes
model, prompt, tool and policy versions
tool-call sequence and permission decisions
human interventions and approvals
deterministic test results
produced artifact hashes
cost, latency and retry counts
final status and recovery state

That receipt makes regressions explainable. When a model or prompt changes, you can rerun the same cases and see whether quality improved by taking a safer path—or merely by spending more tokens.

The practical loop

A useful evaluation loop is simple:

Freeze a representative case.
Run it inside explicit tool and permission boundaries.
Record the complete trajectory.
Verify the artifact and every durable effect.
Compare the result with previous versions.
Promote a change only when the evidence supports it.

The goal is not to make agents deterministic. It is to make the evaluation repeatable enough that change becomes measurable.

That is the difference between “it worked in a demo” and evidence you can use to operate a real system.

I wrote a longer practical guide with a concrete evaluation packet, failure cases and promotion criteria on ChaseOS:

Reproducible model evaluations for AI agents

You can also explore ChaseOS, a local-first Windows workspace for governed agent work.

The model is not the whole agent: 10 failure modes to audit

ChaseInTech — Mon, 17 Aug 2026 10:15:14 +0000

AI-agent architecture reviews often begin with model selection. That is backwards.

The failures that matter usually emerge in the connections between context, memory, tools, permissions and side effects. A strong model can still operate inside a weak system.

Disclosure: I am building ChaseOS, a local-first workspace and control plane for governed agents.

Map the system that actually exists

Start with every model, runtime, queue, memory store, retrieval index, tool adapter, credential boundary, scheduler, approval service, provider, destination and audit sink.

For each surface, ask:

What data can it read?
Can it create durable state?
Can it cause an external effect?
Where are identity and tenant boundaries enforced?
What retries or fallback paths exist?
Which claims have test or live evidence?

Then label the state honestly: implemented, configured but unverified, partial, planned, blocked or retired. A diagram should not grant imaginary security to a placeholder service.

Trace the complete path

An audit should follow the whole route:

untrusted input -> normalized source -> candidate context
 -> bounded task packet -> proposal -> policy / approval
 -> effect -> observed result -> audit / governed writeback

Every transition is a trust decision. Browser content may become a summary, enter retrieval, influence a plan and appear inside a tool call. The original source and its trust state must survive those transformations.

Ten failure families

Input: untrusted content becomes instruction.
Memory: low-trust material is promoted or retrieved incorrectly.
Planning: required checks disappear from the generated plan.
Tools: schemas are ambiguous or hostile output looks successful.
Authority: permissions exceed the task, tenant or target.
Approval: the reviewed payload differs from the executed payload.
Execution: retries duplicate or partially apply effects.
Provider: fallback silently changes privacy, cost or behaviour.
Observation: the system cannot prove what actually happened.
Recovery: rollback is absent, destructive or untested.

This list includes adversarial and ordinary operational failures. Timeouts, stale caches and malformed responses can be just as damaging as deliberate prompt injection.

Separate prevention, detection and recovery

Do not credit one control three times.

Least privilege may prevent a write.
A digest comparison can detect payload drift.
Idempotency can prevent duplicate effects.
A postcondition can detect false success.
A backup can support recovery.

An audit log explains an action after the fact. It does not prevent the action.

Demand negative evidence

Happy-path screenshots prove only that the intended route can work. Test the cases the system is expected to refuse or survive:

wrong tenant
expired approval
mismatched payload digest
missing credential
malformed tool response
duplicate callback
provider loss
attempted protected write

Record the fixture, command, environment, output, remaining risk and release decision. "The architecture looks safe" is not evidence.

How I am applying this in ChaseOS

ChaseOS separates provider, execution surface and permission scope. Runtime profiles declare ceilings; task packets narrow context; activity records preserve evidence; sensitive effects are intended to route through explicit policy and approval boundaries.

The important status boundary: enforcement is verified in some bounded lanes, while other provider and operator paths remain partial or planned. A control-plane diagram is not proof of universal enforcement.

The complete field guide, including sources and an audit evidence checklist, is here:

How to audit AI agent architecture and failure modes

What failure mode has surprised you most in a real agent system: stale context, retries, permissions, or something else?

Agent memory needs an intake boundary, not just a vector database

ChaseInTech — Sun, 16 Aug 2026 11:40:37 +0000

Most AI-agent memory systems start with the retrieval layer: choose embeddings, add a vector database, tune chunking, and decide how much context to inject.

That is useful engineering, but it begins one step too late.

Before asking how an agent should retrieve memory, we need to decide how information earns the right to become memory at all.

Ingestion is not trust

An agent can capture information from web pages, attachments, notes, chat logs, imported repositories, email and tool output. Each source may be relevant. None is automatically trustworthy.

If capture writes directly into durable memory, a system silently combines three different operations:

collecting candidate information;
declaring that information part of the user's knowledge graph;
allowing future agents to reason or act from it.

That shortcut is convenient. It is also an authority escalation.

A malicious page can contain prompt injection. An outdated document can conflict with current policy. A private attachment can be placed in the wrong project. A generated summary can turn an inference into an apparent fact. Once any of those become durable context, later retrieval can make the original mistake look legitimate.

The problem is not that vector search is bad. The problem is that retrieval quality cannot repair a missing trust boundary.

Treat new material as quarantined

In ChaseOS Studio, newly captured material enters Intake rather than trusted memory.

Intake is a review queue for candidate material. It preserves where an item came from and lets a person decide whether it belongs in the workspace graph. Rejection happens before the item becomes durable agent context.

The operating chain is:

Capture collects candidate material.
Intake quarantines it.
Review decides what may join the graph.
Approval stops consequential actions before execution.
History preserves evidence of what happened.

This separates knowledge authority from execution authority. Something can be safe to read without being safe to remember. Something can be safe to remember without being sufficient authority to publish, send, purchase, delete or modify protected state.

Those are different decisions and should remain visible as different decisions.

Admission should carry provenance

A useful intake decision needs more than an Accept button. The reviewer should be able to answer:

Where did this item come from?
Which project or workspace is it trying to enter?
Is it raw source material, an extracted claim, or generated interpretation?
Does it conflict with an existing fact or policy?
Which agent lane will be allowed to retrieve it?
Can the decision be reversed or superseded later?

That makes provenance part of the memory object, not metadata added after the fact.

It also changes the shape of retrieval. Instead of searching one undifferentiated pool, an agent can receive a scoped view: the relevant project, allowed source types, current decisions and the minimum history required for the task.

The objective is not to give an agent everything the user knows. It is to give the agent the smallest trustworthy context needed to do the work.

Approval is a separate boundary

Human review at ingestion does not make every later action safe.

A trusted project brief may still lead to an email, external post or protected write that the user does not want executed automatically. ChaseOS therefore treats approvals as explicit runtime gates. Publishing, external sends and protected writes stop for a human decision even when the underlying context is already trusted.

This matters for unattended work. "Runs unattended" should not mean "has unlimited authority." It can mean the agent continues through permitted steps, pauses at a consequential boundary, and resumes after approval.

That is slower than unrestricted autonomy. The small amount of friction is intentional: it makes persistent background work easier to inspect and easier to trust.

History is operational evidence

An audit trail should record more than a final success message.

For governed agent work, useful history includes what the agent was allowed to read, what it produced, which action required approval, what was rejected, and why the run stopped or continued.

This gives operators a practical way to diagnose failures:

Was the source untrusted?
Was relevant context outside the agent's scope?
Did policy correctly refuse the action?
Did a human approve a different output?
Did a scheduled run complete without crossing a protected boundary?

Without that evidence, "the agent did it" is not an explanation.

What exists today

This is the model I am implementing in ChaseOS Studio, a local-first Windows workspace for governed agents and persistent project context.

The current product includes:

a private typed knowledge graph;
scoped agent lanes;
Intake review;
human approval controls;
schedules for permitted unattended work;
and run history for inspection.

The Community edition is a complete free local product for Windows 10/11 x64. ChaseOS Core and its contracts are MIT-licensed. Studio is the commercial desktop layer.

The boundary matters: hosted runtimes, encrypted sync, agent fleets and GPU compute are roadmap work, not launch claims. This is not an argument that the product has solved every memory problem. It is an argument that admission control belongs in the architecture from the start.

A design question for other agent builders

When your system captures a page, attachment or tool result, what exactly happens before that material can influence a future run?

If the answer is "we embed it," the missing component may not be another retrieval technique. It may be an intake boundary.

I am the builder of ChaseOS, and I would value technical criticism of this model—especially cases where automatic admission is genuinely safer or more useful.

Explore the workspace, see the Intake and approval model, and download the free Community edition:

https://chaseos.ai/?utm_source=devto&utm_medium=organic_content&utm_campaign=governed_intake

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.