Build a Local Operator Console That Tells You What Can Run

This article shows how to build that workflow around three states: ready, waiting for approval, and blocked. The result is a console an operator can inspect quickly, while external effects remain behind explicit review gates.

1. Start with a narrow operating question

Do not begin by copying your entire agent database into a dashboard. Choose one question the console must answer in under a minute:

> What work is safe to advance right now, and what is waiting on me?

That question naturally defines the first data model. Every displayed item needs:

• an identifier;
• a short commitment or requested action;
• its current state;
• the evidence supporting that state;
• the next permitted transition;
• an owner or approval requirement.

A minimal record might look like this:

``json { "id": "task-042", "summary": "Prepare the article draft", "state": "ready", "evidence": ["draft file exists", "format checklist passed"], "next_action": "review", "external_effect": false } ``

The important field is not summary; it is next_action. A console that reports history but cannot distinguish “inspect,” “approve,” and “repair” leaves the operator to reconstruct the workflow mentally.

2. Make state transitions explicit

Use a small state machine instead of free-form status labels. For a draft-oriented workflow, these states are enough:

1. 1. queued — the commitment exists but has not started;
2. 2. running — work is in progress;
3. 3. ready — the artifact or proposal is available for inspection;
4. 4. review — a human decision is required;
5. 5. blocked — progress requires missing input or repair;
6. 6. complete — the approved transition finished.

Then define allowed transitions in code or configuration:

``text queued -> running running -> ready | blocked ready -> review | complete review -> complete | blocked ``

Do not let a UI button silently move an item from review to complete if completion causes an external effect. Instead, make the approval action visible and record who performed it, when, and what evidence was reviewed.

This design also makes recovery calmer. A failed run does not disappear into a generic error stream; it becomes a blocked item with a repair instruction. Re-running should create a new attempt attached to the same commitment, rather than a duplicate commitment that competes for attention.

3. Separate evidence from activity logs

Self-hosted systems often expose an attractive but noisy event feed. Logs are valuable for diagnosis, but they are not proof that a commitment is complete. Keep two layers:

• Activity: what the system attempted, including retries and failures.
• Evidence: durable facts that satisfy a completion condition.

For a file-producing task, evidence can be concrete:

``text path: COO-FILESYSTEM/articles/drafts/example.md exists: true checked_at: 2026-08-31T15:30:00Z ``

For a review item, evidence might include the exact proposed payload and the policy gate it passed. For a blocked item, evidence should include the failing check and the human action needed next.

The console should show evidence first and offer activity as drill-down. This ordering prevents a common failure mode: mistaking a successful invocation for a successful outcome. “The worker ran” and “the requested artifact exists” are different claims.

4. Build the read-only view before adding controls

The first console screen can be plain HTML or a terminal table. It only needs three panels:

Ready

Items with verified artifacts and no unresolved prerequisite. Show the artifact path and a link to inspect it.

Waiting for approval

Items whose next step has an external effect, publication effect, or irreversible change. Show the proposed action exactly as it would be executed. Do not replace it with a vague “approve” label.

Blocked

Items that cannot proceed. Show one reason and one suggested next step. If several failures exist, rank them rather than presenting an undifferentiated list.

A useful row can fit in a few lines:

``text [REVIEW] task-042 Publish article draft Evidence: draft exists; checklist passed Effect: moves file to published/ and schedules site pickup Next: operator approval ``

Only after this read-only view is trustworthy should you add buttons. Controls amplify mistakes when the underlying state is ambiguous.

5. Add an approval gate as a recorded decision

An approval is not a boolean toggle. Treat it as a decision record containing:

``json { "decision": "approved", "item_id": "task-042", "approved_action": "move draft to published", "approved_by": "operator", "approved_at": "2026-08-31T15:42:00Z", "evidence_revision": "sha256:..." } ``

Binding the approval to an evidence revision matters. If the proposal changes after review, the old approval must not authorize the new payload. Requiring a fresh review is safer than trying to infer whether the change was harmless.

For a self-hosted console, this gate can remain local and simple: authenticated access, an append-only decision log, and a worker that refuses to execute an external action without a matching approval. The implementation can grow later; the invariant should not.

Conclusion: optimize for the next safe step

A good self-hosted console is not an observability wall. It is a quiet operating surface that turns agent activity into commitments, evidence, and explicit next steps.

To build one this week:

1. 1. Pick one operator question.
2. 2. Define six or fewer states and allowed transitions.
3. 3. Store evidence separately from activity logs.
4. 4. Ship a read-only three-panel view.
5. 5. Add approvals only when they bind to an exact proposed action and evidence revision.

If the console can tell you what is ready, what needs approval, and what is blocked—without making you parse a stream of retries—you have built the essential layer. Everything else is an increment on that foundation.