In Herald's monitor code, an agent that goes quiet for too long has not failed. _build_stall_event returns status="unknown", tags the event monitor_status="stalled", and passes record_native_status=False so the notification cannot overwrite the run's stored status or completion time.That one keyword argument carries most of this post. What the origin stopped seeing is not what the target did. Neither of them is what a person accepted.If the interface gives those situations a single status, somebody eventually makes the wrong recovery decision. A missing callback becomes a failed task. A completed task becomes an accepted artifact. A configured delivery mode becomes proof that the owner received the result.Herald connects Hermes profiles through dispatch and conversation tools. I have been reading its monitor worktree to see where it keeps those three things apart.
Losing observation does not establish failure
The same builder handles an approval wait that runs out. It reports monitor_status="approval_wait_expired" and leaves the pending approval in place, so the origin can still approve or cancel explicitly. The notification text says the run may still be active and points at check_dispatch.That beats making every notification look terminal. The origin can report that it stopped seeing activity and still admit it does not know the target's outcome.The test definition in test_monitor_outcome.py makes the intended boundary concrete. It builds a stall event, checks that the stored dispatch remains non-terminal, then supplies an actual completion update and checks that the update can still be recorded.Another test does the same kind of separation for a pending approval. A monitor's waiting period expiring must not silently resolve the real approval.The file describes itself as future monitor-boundary acceptance, to be copied into a candidate after handoff. These tests state a contract; they are not a result.
Query the run before commissioning another writer
Herald's reconnect logic includes a status lookup against the target run. That lookup matters because a final result may already exist even when the event stream is unavailable.The corresponding test supplies a missing event endpoint and a completed result from the status endpoint. Its expected behavior is to recover the persisted final result rather than conclude that no event means no result.For an operator, the next step is to preserve the original target profile and run_id, then use check_dispatch to inspect that exact run. If the local handle has been lost, dispatch_status is the history surface to consult before inventing another task.Do not start another writer just because the original callback is absent. The first writer may still be active, and an uncertain observation is a poor basis for creating concurrent work on the same target.The inspected handle_check_dispatch also treats a native not_found response carefully. It returns execution_status="unknown" and points to persisted Herald records. It does not claim that a gateway restart must have destroyed the work.Not every branch agrees. In the same polling function, a run reported as waiting_for_approval with no owned approval notice, or a not_found status, still produces a failed event. The non-terminal handling covers the stall, approval-expiry and lookup-unavailable paths. Those two other branches deserve a second look in review.
A completed run has not passed review
The local ledger implementation exposes artifact_acceptance separately from execution status. Without an operator receipt, the acceptance projection is unverified.That remains true when the native run has completed and returned nonempty text. The test named test_native_completion_and_callback_mode_are_not_acceptance_or_delivery checks exactly that for callback and detached modes.I like how little that lets the interface infer.An answer can contain a confident summary and a path that does not exist. A real file can exist but fail the requested constraints. A test can pass against a different revision from the one being reviewed.Execution status cannot settle any of them by itself. Acceptance requires checking the requested artifact against the actual commission.
Receipts name the basis of the claim
record_operator_receipt binds a receipt to a dispatch edge and a run. The implementation checks that the pair exists and belongs to the active origin profile. It records the kind, state, evidence reference and verifier, with the basis explicitly labeled operator_attestation.That label is doing real work.A receipt is not a verifier that opens the artifact and proves it correct. It is a record of a verification claim. Nor does a verified_by string establish authenticated human identity. The quality of the evidence behind the attestation still matters.The implementation rejects reuse of a receipt identifier with a changed payload. An identical retry returns the existing receipt. Test definitions cover that behavior, wrong-run and foreign-origin attempts, and persistence into a fresh reader process.Those checks make a more reviewable record. They do not make the recorded judgment infallible.For consequential work, the evidence reference should identify the exact artifact or revision that was checked, not a conversation in which the agent said it was finished.
Delivery is a separate claim again
The ledger also exposes owner_delivery, initially unconfirmed. An artifact receipt does not automatically confirm delivery, and a delivery receipt does not automatically accept the artifact.That split matters in a delegated workflow. A result may be correct but never reach the person waiting for it. A person may receive a result that still needs changes.A confirmed delivery receipt is rejected without a nonblank evidence reference. Callback configuration alone is not enough. It describes the intended route, not evidence that the owner received usable work through it.The final report should keep the same separation. Report the target's observed state. Report whether the artifact was checked. Report whether delivery is confirmed. Leave the unknowns visible instead of turning them into a reassuring sentence.The next time a dispatch disappears from the conversation, recover its handle before asking another agent to do the same job.
