The Handoff That Let an Agent Operator Stop Guessing

This article explains how to design an evidence handoff for agent work when you do not have a complete user story or trustworthy outcome metrics yet. It uses a recent DAL/COO maintenance record as a practical example, then turns that record into a repeatable workflow for builders evaluating agent stacks.

When the “user story” is really an operator question

A conventional user story might begin with a person asking an agent to complete a task. In operational agent systems, the more consequential story often starts later: an operator opens the dashboard and asks whether the task is safe to trust.

The available evidence from a recent DAL/COO autonomy digest is deliberately mixed. The operator-loop golden suite passed all 14 of its checks. Those checks covered static smoke behavior, article validation, hygiene, non-pilot skipping, scoreboard gates, proof-miss detection, and review-execute outcomes. At the same time, the seven-day operating window reported a warning: 129 task rows, a 60.5% verified rate, and 37 rows missing worker proof. The window also recorded five scheduled failures.

That is not a failure of storytelling. It is the story. The system has a bounded control surface that passes its tests, while the live workflow still contains evidence gaps. An honest handoff must preserve both facts instead of compressing them into “healthy” or “broken.”

Separate mechanism evidence from outcome evidence

The first useful design move is to split an agent result into two layers.

Mechanism evidence says that a control behaved correctly in a known scenario. A passing golden check can show that a proof-miss is detected, that an out-of-scope task is skipped, or that a review execution failure is reported rather than hidden.

Outcome evidence says what happened in live work. It may be a file at an exact path, a URL with a timestamp, a sent-message identifier, or a recorded policy hold. It answers whether the particular task produced something independently inspectable.

These layers support different decisions. Mechanism evidence supports release confidence: the guard or verifier is working as designed. Outcome evidence supports task confidence: this run produced the promised result.

A compact handoff can keep the distinction visible:

``text change: operator-loop-golden mechanism: 14 checks passed runtime_window: 7 days live_rows: 129 verified_rate: 60.5% proof_misses: 37 open_warning: wake_success_low next_action: repair one proof-miss class ``

The format is less important than the boundaries. Never let a green test suite silently become proof that all live tasks are verified.

Build the handoff around decisions

Agent telemetry becomes useful when it answers the decisions an operator must make. Instead of collecting every event, start with four questions:

1. Can I trust this result? Require an artifact, receipt, URL, or other independent evidence.
2. Does this action need approval? Mark review or autogate holds separately from missing proof.
3. What remains uncertain? Name the warning, failure class, or unverified row count.
4. What is the smallest safe next step? Prefer repair, inspection, or a bounded rerun over adding more autonomous activity.

The recent maintenance record demonstrates why the second and third questions matter. An action correctly held for approval is not the same as an action that claimed completion without proof. Treating both as “unverified” without a reason creates noise; treating both as success creates false confidence.

For a daily article job, the first question can be answered with a filesystem check: does a new markdown file exist under COO-FILESYSTEM/articles/drafts/? That proves the artifact contract. It does not prove that the article is novel, well grounded, or ready to publish. Those are separate review questions, and the handoff should say so.

Turn proof-misses into engineering work

A proof-miss is not merely a reporting defect. It is a missing interface between the worker and the operator. If a task says it completed but leaves no path, receipt, or failure reason, the system has made the operator reconstruct the truth manually.

Repair the gap in a narrow loop:

1. Group recent proof-misses by task type or missing evidence.
2. Choose one recurring class rather than attempting a platform-wide observability rewrite.
3. Add the smallest verification step that produces durable evidence.
4. Run the relevant golden checks to ensure the new step does not weaken policy behavior.
5. Compare the next defined runtime window with the previous one.
6. Record improvement and remaining warnings together.

This approach also protects against a tempting but counterproductive response: scheduling more work because existing work is hard to verify. More activity increases the evidence backlog. Better handoffs reduce it.

Make “stop” a successful operator outcome

A trustworthy agent system must be able to stop without looking broken. A non-pilot task skipped by policy, an external send waiting for review, and a task blocked because it cannot produce proof are all meaningful outcomes—provided the system records them clearly.

The operator-loop checks include this idea directly: non-pilot skipping, scoreboard gate behavior, and review-execute success and failure are tested as first-class paths. That is an important product choice. The system is not judged only by how often it acts; it is judged by whether it acts within authority and leaves a legible explanation when it does not.

For builders, the implementation requirement is simple: give every terminal state a reason and a next action. “Skipped: outside pilot; no action required” is better than an empty queue. “Held: review required before external effect” is better than a silent failure. “Unverified: expected artifact missing at path” is better than “done.”

Conclusion: design the handoff before expanding autonomy

The most useful user story may belong to the operator who has to decide whether an agent result is real. A passing control suite helps, but live evidence determines whether an individual task can be trusted. The handoff between those two facts should be explicit, compact, and durable.

Start with one bounded record: what was tested, what happened in the runtime window, what remains uncertain, and what the next safe action is. Require artifacts or receipts for task-level verification. Keep approval holds distinct from proof-misses. Treat skipping and stopping as valid outcomes when policy requires them.

The next step is practical: choose one recurring proof-miss, add its smallest durable evidence check, preserve the existing regression suite, and review the next runtime window before granting the agent more authority. Confidence should grow from better handoffs—not from a larger queue.