05 · Keep track of agent work
Use Scout's broker-visible work records to identify the next actor, inspect blockers, and prepare results for review in a trusted-team pilot.
Goal
Inspect work already visible to Scout, identify the next action, and carry the result into a review or handoff.
You need
Scout set up, access to the relevant local broker, and a returned work reference from an earlier ask. Start with your first ask if you have no tracked work yet.
By the time a small team has several agents working, a status update can require visiting several sessions. One person knows why a task stopped; another knows which change is ready. A useful coordination view brings the task, its current evidence, and the person responsible for the next action together.
OpenScout currently supports high-trust local developer pilots. The commands below inspect the current broker's snapshot. They do not establish an organization-wide dashboard, poll every remote machine, or grant a teammate access to files, provider accounts, or sessions.
Start with work already in progress
These commands read status without acknowledging, retrying, or resuming work:
Each record includes a handle, recorded state, summary, and next actor when known. --blocked selects explicit waiting/review states and unanswered questions. It does not infer a blocker from a quiet terminal or an old message. Unknown next actors stay unknown; deciding who should act is a coordination step for the team.
Use an existing handle to inspect one task. Replace RETURNED_REF with the exact reference from your receipt:
Related flights and work items can appear as separate records. Keep their handles together in the task note rather than counting every row as a separate assignment. If the broker snapshot cannot be read, status reports an error; that is an unknown work state, not evidence that the queue is empty.
A morning triage example
The following is an illustrative worksheet, not captured Scout output or a live team result. Project, human owner, artifact, and last-checked time are fields the coordinator adds from the actual task and repository evidence.
| Task | Evidence available | Next actor | Useful next action |
|---|---|---|---|
| Investigate a flaky test | The existing flight is recorded as running; no result has returned | Assigned investigator | Follow that reference; wait for evidence before starting another investigation |
| Clarify retry behavior | An open question asks whether a timeout permits a second write | Human owner of the requirement | Answer the existing question in its conversation |
| Review a proposed fix | A result and diff are available; human acceptance is pending | Assigned reviewer | Check the revision, test evidence and open findings |
The first row calls for observation, the second for a decision, and the third for review. Completed execution is useful evidence, but the team still needs to establish whether its artifact meets the requested outcome.
For each task, record the project, responsible person, broker/work reference, observed state, evidence timestamp, next actor, next action and artifact. Use the morning-triage worksheet↗ alongside the work. This worksheet is maintained by the team; it is not an automatically synchronized Scout view.
Find questions that already have an owner
operator filters for the broker's human operator identity. self resolves the current Scout sender identity. Neither option discovers your company's org chart or assigns a task to a colleague. Inspect the complete blocked list as well, because records with unknown next actors will not match either filter.
Native harness permissions appear here only when the host captures them in records Scout can inspect. If the destination is waiting on an uncaptured permission prompt, use that harness's supported interface. See operator attention and current coverage.
Follow a result without starting the task again
A timeout ends this wait. It does not prove that execution failed or authorize a duplicate run. Inspect the same reference and any recorded blocker before deciding how to continue. When the result arrives, open its artifact and use the review evidence checklist↗.
For future work, --notify lets an ask return after its broker receipt. This example starts a real review using the selected harness and its provider account; replace the path and scope with work you intend to delegate:
Save the receipt's reference. Recording the request and delivering its eventual notification are separate events; notification delivery is best-effort. The reference remains your route back to status and the result.
Use activity streams for more context
Replace PROJECT_NAME with the project to inspect. watch streams broker messages; tail reads observed harness activity. Activity can explain what a worker is doing, while the work record explains the recorded lifecycle. An observed transcript does not become a Scout conversation merely because it is visible in the feed.
Check your pilot
Try this on a small set of actual tasks. Record time to identify the next actor, waiting tasks without an owner, and duplicate starts. Keep unknown states and missing evidence visible. These are measurements to collect, not claimed OpenScout results.
The workflow is useful when another authorized person can identify the next valid action from the task note and evidence without asking the original requester to reconstruct the session.