## 6\. Observe jobs and read results ### Keep three identities separate | Identity | What it names | Where to discover it | | --- | --- | --- | | **Tan agent ID** | The conversation\/agent registration\, generated as `Tan-…` | Runtime Hub roster or agent\-facing Hub list | | **Background job ID** | The initial managed run\, commonly generated as `bg_…` | Dispatch acknowledgment\, `/jobs`\, Hub job inspection | | **Supervised process name** | A server\, watcher\, debugger\, or other broker\-managed process | Hub process listing and description | A display label such as `tan`\, a shortened task preview\, or “the second row” is not an identity\. The internal background\-job record has an `agentId` association\. The persisted tan dispatch record also contains the job ID\, full work text\, and a transcript filename based on the Tan ID\. **Not every rendered or tool\-facing job snapshot exposes that association\.** Do not claim to have mapped the two IDs merely because a list contains one plausible label\. ### Copyable discovery request to Main **Plain\-language message — Main only\:** ~~~text Main, inspect the current live and parked agent roster and your background jobs. Find the tan assigned to the Lantern Library label audit. Report: - its exact Tan agent ID; - any backing background job ID, distinguishing running from merely retained; - its owner or parent; - its agent lifecycle state and job state separately; - the evidence connecting the task, Tan ID, and job ID. Use current roster, dispatch, and authorized transcript information. Do not infer the mapping from a shared "tan" label, a truncated preview, row order, or a remembered job number. Do not send, revive, or cancel anything. If the mapping is unavailable or ambiguous, say so. ~~~ This is a discovery request\, not a special OMP command\. Main must use the inspection surfaces actually available to it\. ### Status without messaging **OMP slash command — Main only\:** ~~~text /jobs ~~~ This shows Main’s owner\-scoped running jobs and a small recent\-job list\. It is a status snapshot\; it does not itself retrieve and consume settled job\-result bodies\. For a currently parked tan\, messaging is not passive observation\: sending can revive it and start a turn\. Read its transcript instead when you only want to inspect prior work\. ### Hub tool arguments are not terminal commands The following are **argument objects for the agent’s `hub` tool**\. They are not shell commands\, slash commands\, or HTTP requests\. Main normally supplies them through its available tool interface\. **Discover live peers\:** ~~~json {"op":"list"} ~~~ **Discover parked peers in the current session root\:** ~~~json {"op":"list","status":"parked","limit":100} ~~~ **Inspect owner\-scoped jobs and additional running\-agent activity\:** ~~~json {"op":"jobs"} ~~~ The default peer list includes running and idle peers\, excludes the caller and advisor transcripts\, and does not list aborted agents\. Parked peers require the parked filter\. Lists default to 32 rows and allow at most 100\. Inspect `shown` and `truncated` counts\. Increasing the limit is not a guarantee of an exhaustive roster\, and no pagination parameter is supplied here\. The runtime UI Hub can also show parked\, killed\, and advisor transcript rows\. These surfaces intentionally have different visibility rules\. ### Checking status can consume delivery A completed tan normally delivers its final text to the **owning session**\, ordinarily Main\. Owner\-routed delivery can enter an active run at a boundary or wake an idle owner\. However\, if the agent’s Hub **`jobs` or `wait`** operation observes a settled result first\, that snapshot becomes the recovered delivery and suppresses a duplicate automatic `async-result`\. Later snapshots may say\: ~~~text Delivery: already delivered or recovered. ~~~ …and omit the body\. That does not mean the tan produced no output\. Look in the earlier delivery or Hub result\, then follow any actual artifact link\. This is why repeated status polling is not a reliable way to repeatedly fetch the same full report\. ### Waiting is not “wait until all work succeeds” After discovering an actual job ID\, Main can narrow a wait\. **Hub tool arguments — replace the placeholder only with a discovered current job ID\:** ~~~json {"op":"wait","ids":[""],"timeoutMs":30000} ~~~ The unified wait can return on the first relevant message\, watched job settlement\, timeout\, or interruption\. It is not an all\-jobs\-complete barrier\. A timeout\: - Does not cancel the job\. - Does not prove the tan is stuck\. - Does not prove that a message was not delivered\. Default job waits can use an adaptive window\. An explicit `timeoutMs` is in **milliseconds**\; do not confuse it with process\-operation timeout fields measured in seconds\. ### Messaging from Main is a different input path **Plain\-language message — Main only\:** ~~~text Main, rediscover the exact Tan ID for the Lantern Library label audit. If there is one unambiguous match, send it this correction: report only green-shelf mismatches, keep the input files read-only, and leave Main's work alone. Report the exact recipient and delivery receipt. Do not describe the receipt as proof that the correction has already been followed. ~~~ For illustration\, the corresponding tool arguments have this shape\: ~~~json {"op":"send","to":"","message":"Report only green-shelf mismatches. Keep the input files read-only and leave Main's work alone."} ~~~ The source messaging path delivers a peer message to a busy agent or wakes\/revives an idle\/parked one\. This is **not the same queue\-control gesture as focused Enter**\, and it is not the same as Ctrl\+Q follow\-up ordering\. If an answer is essential\, `send` supports `await:true`\. That waits for a reply\; it is not a guarantee of task completion\. If the send succeeded but the reply wait timed out or was interrupted\, check the inbox or wait again rather than blindly resending\. ### Read the transcript\, not an invented result path `history://` is an **OMP internal resource scheme**\, read through OMP’s read tooling\. - `history://` provides an index\. - `history://` reads that agent’s transcript\. For live agents\, the handler reads live session messages\. For parked or unregistered agents\, it can use retained JSONL files found through its discovery paths\. It does not need to revive the agent just to read history\. The representation is concise Markdown\, not a promise that every large tool payload is reproduced verbatim\. **Plain\-language message — Main only\:** ~~~text Main, discover the exact Tan ID for the Lantern Library label audit and read its history:// transcript without reviving it. Summarize the audit, the later correction, and any queued follow-up that actually ran. Distinguish completed evidence from proposed or skipped work. Follow only artifact links that were actually returned. ~~~ Ordinary task result URLs such as `agent://` resolve a corresponding `.md` output artifact\. **The initial `/tan` controller does not automatically write that ordinary task result artifact\.** Do not assume an `agent://` route for a Tan ID will work merely because its transcript exists\. ### Full text versus previews A Hub preview or compact dispatch line is not the whole result\. Owner delivery keeps text inline up to the current 12\,000\-character threshold\. Larger text is normally represented by a 4\,000\-character preview plus an `artifact://` link **if artifact persistence succeeds**\. If persistence fails\, only the preview may be available through that delivery\. Read the returned full\-output artifact when present\. If it is missing\, report the gap\; do not silently treat the preview as a complete report\. ### Job IDs are short\-lived handles Background\-job rows are process\-local and normally retained for roughly five minutes after settlement\. They can be removed earlier by lifecycle operations\. Generated job IDs can be reused after eviction\. Therefore\: - Rediscover before cancelling\. - Do not use a job number from an old screenshot or a previous OMP process\. - A missing job row does not mean its Tan transcript disappeared\. - A revived tan can be working without a new job row for its prompt\. Hub job snapshots include additional running\-agent activity not represented by the caller’s running jobs\. That can include a revived agent or work owned by another agent\. It is not blanket authority for Main to cancel that work\. ---