Agent message delivered does not mean task completed
Read acceptance, execution, results, and human approval as separate evidence when coordinating agents.
A delivered agent message proves only the delivery condition reported by its transport. It does not, by itself, prove that a worker started, produced the intended artifact, or passed review. A reliable workflow tracks those facts separately and keeps a stable reference for follow-up.
Suppose an agent is asked to review a diff. The caller receives a receipt, then stops waiting after a timeout. There are several possible realities: the request is queued, the reviewer is still working, the reviewer is blocked, or the findings exist but the final response was not captured. Launching another review before inspecting the original can waste capacity or produce conflicting work.
Ask what each signal establishes
| Signal | What it can establish | What remains to check |
|---|---|---|
| Request accepted | The system recorded the request under a handle | Whether a worker started |
| Delivery recorded | A transport reports its delivery condition | Whether the runtime consumed the request |
| Runtime activity | Execution has produced an observable signal | Whether that activity advances the task |
| Artifact exists | A file, result, or change was produced | Correct revision, completeness, and quality |
| Completion captured | The workflow recorded a terminal result | Whether the result meets acceptance criteria |
| Human acceptance | A person accepted the inspected outcome | Whether a separate publish or deploy step is authorized |
This is an evidence checklist, not a claim that every product exposes these exact status names. Read each system's lifecycle contract before interpreting its labels.
Use asks for owned work
In OpenScout, use an ask when another agent must investigate, decide, implement, review, or reply. A send is appropriate for an update that requires no response or owned next step. Asynchronous work remains an ask; choosing not to wait inline does not turn a task into a notification.
For example, after setting up Scout and the chosen harness, replace the project path and scope in this illustrative command:
Retain the actual returned handle. Inspect that work with scout status RETURNED_HANDLE; use your real handle in place of the placeholder. The CLI reference and communication contract↗ describe the available commands and records. The command above initiates real work if run; this article does not execute it.
Recover without assuming failure
First, read the original request and its latest recorded state. Check whether it has an explicit blocker or terminal error. A quiet worker is not necessarily stuck, and stale observation is not evidence of failure.
Next, inspect the artifact or execution evidence available for that same handle. A completed file and a missing final acknowledgement should be reported as two facts. Do not label the artifact unsuccessful solely because response capture failed.
Then choose the smallest next action. Continue the same context when clarification is needed. Reconcile the existing result when capture is incomplete. Retry only when the previous attempt's state and possible side effects are understood. For changes to external systems, the application needs its own deduplication or idempotency strategy; a new prompt cannot guarantee that an action happens once.
Finally, evaluate the result against the original acceptance criterion. “The reviewer responded” and “the review found no actionable issue on this revision” are different conclusions.
Waiting and cancelling are separate controls
The OpenScout architecture distinguishes caller waiting from the continuing work lifecycle. Do not infer a cancelled task from a caller timeout. Likewise, an application reporting cancellation does not automatically establish that every downstream provider call or external effect stopped; check the relevant runtime's documented behavior.
OpenScout mesh provides reachability and coordination across machines. It does not claim exactly-once distributed delivery or global consensus. See the architecture before building reliability assumptions around a status label.
Use the handoff builder to state the return artifact and acceptance check before dispatch. The handoff video illustrates the lifecycle, and the protocol explorer separates the interfaces from the workflow policy.