feat(agents): support bounded consultations while peers are busy without forging decisions #1702

Before submitting

• I searched open and closed issues and did not find a request for this feature.
• I reviewed this request and removed credentials, tokens, private paths, hostnames, and other sensitive data.

Problem or opportunity

A question sent to a busy orchestrator or subagent can wait until its answer is no longer useful. Queries include both information requests and decisions. Transport acceptance or a helper's answer must not be confused with a response or approval from the responsible agent.

Improved discovery removes routine coordination questions, but information requiring reasoning and owner-only decisions still need an explicit timely response path.

Proposed outcome

• Answer requests for recorded status/scope directly from bounded existing metadata without invoking an additional model, waking the recipient or waiting for its main lane. Include source/freshness and say when the answer is unknown.
• For information that requires reasoning, provide an explicitly requested, consent- and cost-bounded read-only consultation lane while the recipient continues working. Use only authorized bounded context; identify the answer as a helper's snapshot-based response, not the responsible agent's decision.
• Support consultation of orchestrators and owned subagents while preserving ownership and cross-session safety boundaries. Reuse existing runtime, task and messaging seams; do not add an independent daemon or duplicate authority store.
• Carry whether the request is blocking, its urgency and expiry. Expired requests do not cause late work or late decisions to appear current; cancellation, failure and unavailable context produce explicit outcomes.
• Decision requests remain owned by the responsible agent and use the existing safe delivery lifecycle. Surface pending/expired decisions and prioritize actionable requests at a safe point without killing active tools or silently granting authority.
• Do not implement automatic delegated approvals in this initial feature. A helper may prepare advice, but cannot consent, authorize edits/delivery or approve on behalf of the recipient or user.
• Bound concurrent consultation work and context/model usage, and reuse unchanged metadata rather than launching a full worker for every status question.
• Test busy-main and long-tool scenarios, zero extra model calls for metadata requests, bounded reasoning calls, stale snapshots, cancellation/expiry, ambiguous recipients, consent rejection and the absence of decision/approval forgery. Include isolated runtime verification.

Alternatives considered

Wait in the ordinary recipient queue; may answer too late. Interrupt every question; harms throughput and still cannot guarantee immediate owner decisions. Spawn a full agent per message; wastes resources. Let helpers decide for owners; creates unauthorized authority.

Additional context

Distinct from ordinary messaging (#674), managed parent-input round trips (#1229), proactive progress (#1323), runtime adapters (#444), and delivery defects (#1517, #1092, #1638). Respect receiver provenance/consent boundaries tracked by #1518; do not duplicate the prompt-lifecycle fixes in PRs #1639/#1640.

Deliver metadata-first, then bounded reasoning consultations and owner-decision handling as focused stacked PRs. Partial slices use Refs; only the completing slice uses Closes. This is not a guarantee of an immediate decision from a busy owner.