Resolve existing peer Agent delivery routes before substituting host sub-agents

[huangruiteng]

Problem and observed behavior

A user requested review by an existing LoopX peer. The coordinator initially substituted a temporary host sub-agent, then inspected a later historical session binding rather than resolving the intended peer. That host task was unavailable. The user had to supply the existing task link explicitly.

Readback established that identity had not been lost: resolve-agent-thread --thread-link ... returned status=bound, the expected Goal/Agent and authority=locator_only; reading the user-selected host task succeeded. The first failure was coordinator behavior: it did not consult existing identity evidence before choosing a different execution mechanism. Do not relabel this as a broken thread-to-Agent resolver.

There is also a discoverability gap worth closing: agent-directory projects registered identity, current work and observation/delivery references, but not a verified route for addressing the peer. One Agent may retain multiple historical thread bindings. Array order, recency or a missing task on one host does not establish which binding should receive new work.

Roadmap / existing owners

Refs #4574, overall roadmap S3/S9 and R2/R3, especially “Peer help and independent review”: requests must reach an existing peer, preserve its commitments, and return accepted results. R6 owns cross-host authorization; this issue must not import or rebind sessions across host/profile boundaries.

Reuse loopx/control_plane/agents/directory.py, the existing Agent registry / host-session locator, local-delegation and collaboration request/return owners. No second Agent registry, scheduler or synthetic “side-agent” hierarchy is needed.

Proposed complete slice

• Make peer selection distinguish a durable LoopX Agent from a temporary host sub-agent. An explicit peer/task selection wins; never silently replace it because another tool is convenient.
• Offer a bounded reverse lookup / route preview using the existing binding owner. Preserve multiple candidates and report typed resolved, ambiguous, unavailable or not_authorized outcomes with evidence provenance. Do not pick the last registry row.
• Verify the selected route through the owning host, preserving host/profile/session boundaries. A route is a locator, not a claim/lease transfer, capability grant or proof of availability.
• Reuse durable delegation/request identity to hand off the exact review artifact/head and acceptance/return obligation. Separate delivery, receiver adoption, review completion and result return. On unavailable/ambiguous routing, expose the specific gap and retain the user's intended peer.
• Repair the host-facing guidance so a peer name first triggers registry/directory resolution; when the user supplies a task link, use the existing exact-link resolver before guessing titles or scanning historical bindings.

Decisive acceptance

Use synthetic identities and real host adapters where supported:

1. Multiple historical bindings with the intended task still readable: explicit selection routes to that task, with zero replacement workers created.
2. One unreachable historical task plus another authorized candidate: report bounded evidence; do not conclude the Agent is missing or automatically resume another session.
3. Ambiguous, revoked, archived and cross-profile candidates fail with distinct actionable outcomes and no session copying/rebinding.
4. A real existing peer receives an exact-head review request, adopts it, returns its verdict/artifact to the requester, and retries after restart do not duplicate the request.
5. Ordinary directory reads remain read-only and public-safe; no private task links, local paths or raw conversations appear in public projection/fixtures.

The reported incident's operational workaround is explicit identity resolution followed by the user's selected task. This issue concerns making that path discoverable and reliable without requiring the user to correct the coordinator each time.

Confirmed follow-up: the display projection is lossy

Both project and global exact-link resolution returned bound. The peer then traced its contrary conclusion to the global status display's single session_binding and corrected the inference; no binding or lease repair was needed.

loopx/control_plane/agents/management_projection.py builds session_bindings as a dictionary keyed by Agent and assigns session_bindings[agent_id] while walking all thread_agent_bindings (lines 587–604 at baseline 37bbaec79). A later binding replaces an earlier one; the Agent row exposes the surviving value at lines 669–670. This is a display projection, not proof that the omitted exact binding is invalid. The coordinator also tried choosing a newer historical binding, so the ambiguity affected both sides of the handoff.

The fix should preserve a bounded, explicitly described binding/candidate summary or route-resolution reference instead of encouraging consumers to infer unique execution ownership from this one field. Existing exact-link resolution must stay authoritative for the relation it actually checks; it still grants no lease, write or cross-profile resume authority. Cover the same multiple-binding counterexample through status, directory, exact lookup and actual request adoption.