DEV Community

Cover image for Why Agent Interfaces Need Visible States Before More Autonomy
ChaseInTech
ChaseInTech

Posted on

Why Agent Interfaces Need Visible States Before More Autonomy

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:

  1. What state is the agent in?
  2. Why is it in that state?
  3. What evidence or decision caused the transition?
  4. 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

Top comments (0)