The Operator’s Last Mile: Designing Agent Work That Can Be Verified

This article turns a recent Human Computer operating signal into a practical design pattern: how to make agent work legible at the point where an operator must trust, review, or continue it.

The problem is not activity; it is ambiguity

A recent autonomy digest showed a healthy-looking completion rate alongside a less comfortable signal: over a seven-day window, 68.6% of task rows were worker-verified, while 24.2% were proof-misses. The system was not simply failing to run. It was often running without leaving enough evidence for the worker check.

That distinction matters. A task can call an API, update internal state, or produce a response and still be operationally incomplete if nobody can identify the durable result. “Completed” describes an execution attempt. “Verified” describes an outcome that another process—or an operator—can inspect.

For operator UX, this means the primary screen should not ask only, “What did the agent do?” It should answer three narrower questions:

• What artifact or external result was expected?
• Where is it?
• What check proves it exists?

Those questions turn an opaque run into a handoff.

Start with an artifact contract

Before an agent begins, define the smallest durable outcome that counts. For an article job, that might be one Markdown file under COO-FILESYSTEM/articles/drafts/. For a review-queue digest, it might be a dated work log. For an outbound action, it might be an API result with an identifier and timestamp.

The contract should name the destination, not merely the intention. “Write an article” is too broad for reliable completion. “Write one new Markdown draft to articles/drafts/ and report its exact path” is testable.

A useful contract has four fields:

1. Expected result: the file, API effect, or review submission.
2. Allowed location: the exact directory or route.
3. Minimum evidence: existence, readable contents, HTTP success, or returned ID.
4. Safety boundary: draft-only, review-required, or externally visible.

This is not bureaucracy added after the agent works. It is the interface between the agent’s freedom to solve a problem and the operator’s need to know what changed.

Make proof part of the workflow, not the closing sentence

The strongest verification happens immediately after the write. An agent that creates a draft should read it back or list the containing directory. An agent that sends a request should inspect the response. An agent that changes a project state should confirm the state file contains the update.

That sequencing prevents a common failure mode: the agent reports success because its final tool call returned, while the durable result was never checked. A successful command is evidence about a command—not necessarily about the artifact the operator cares about.

The verification step should also be small. For a file, existence plus a readable header may be enough. For a structured output, parse it and confirm required fields. For a queued action, inspect the queue entry rather than assuming enqueue succeeded from a generic response.

The goal is not to create a second workflow that is as complex as the first. It is to choose one cheap, decisive check.

Show the operator the delta

Operators rarely need a transcript of every internal step. They need a clear delta from the previous state.

A useful completion record can be rendered as:

• Result: Draft created
• Path: COO-FILESYSTEM/articles/drafts/example-2026-09-27.md
• Verified by: read-back succeeded; required H1 and lede present
• External effect: none; draft-only
• Next gate: principal approval before publication

This format is calm because it separates accomplishment from permission. The agent can complete a draft without implying that publication happened. It can prepare an email without implying that it was sent. It can identify a blocker without hiding it inside a long narrative.

The same pattern helps scheduled jobs. A scheduler dashboard should distinguish “ran,” “artifact verified,” “review required,” and “failed.” Collapsing those into one green status creates the exact ambiguity that produces proof-misses.

Design the failure path as carefully as the success path

A verification-first workflow also makes failures actionable. If the expected file is missing, the agent should not improvise a success message. It should report the missing path, preserve any useful partial result, and identify the next safe action.

For example:

• Attempt: article generation completed.
• Failure: expected draft path was not found during read-back.
• Effect: no publication or external send occurred.
• Next step: inspect filesystem permissions or retry the write.

This is better than a generic “task failed” because it tells the operator whether the problem is content, transport, persistence, or policy. It also protects the review boundary: an unverified result does not silently advance to publication or an external channel.

A system can go further by recording proof-misses as their own operational metric. They are not identical to execution failures, and treating them separately points maintenance toward the right layer: completion contracts, tool return handling, or verification coverage.

A practical checklist for agent builders

When adding or repairing an operator-facing job, use this short sequence:

1. Name one durable result before writing the prompt.
2. Put the result in a predictable, inspectable location.
3. Keep external effects behind their existing review or approval gate.
4. Perform one direct verification immediately after the write or API call.
5. Report the exact path, identifier, or blocker.
6. Record whether the result was verified, not just whether the task ran.

This checklist is deliberately modest. Operator UX improves when the system removes uncertainty, not when it adds another dashboard full of activity counters.

Conclusion: make trust cheap to check

The lesson from proof-miss data is not that agents must explain every thought. It is that dependable automation needs a visible handoff from execution to evidence. A precise artifact contract, one immediate verification step, and a compact result record can make that handoff routine.

The next time you ship an agent job, begin at the end: decide what an operator should be able to point to when asking, “Did it happen?” Then make that answer durable, readable, and separate from any later approval. That is how an active system becomes an operable one.