[RFC] Cross-session conversation references and retrieval

Summary and status

I'd like feedback on a small way to reuse context from a previous DeerFlow conversation, and on which follow-up would be useful after that.

Implementation for review: #5399. It provides an opt-in, API-only conversation reader. The possible follow-ups below are discussion points and do not expand that PR's scope.

Problem / motivation

A user starts conversation B and wants to use requirements agreed in conversation A. Manually copying the material takes effort, while carrying the entire conversation may add irrelevant context.

DeerFlow already exposes owned transcripts through HTTP APIs and has history tools for the current task. This proposal adds a model-facing way to consult a specifically referenced previous conversation while continuing the current task.

Current proposal

An operator enables read_conversation. The API caller explicitly submits up to three thread IDs or same-origin chat URLs through conversation_references; the lead agent can then call:

read_conversation(thread_id, cursor?, limit?)

• The server binds references to the current run and authenticated user. Admission requires runs:read; each read checks the allowed sources and current ownership.
• IDs in ordinary messages, quoted material or older history grant no access. A new run, including resume or replay, must submit references again.
• Reads reuse existing transcript storage and visibility rules. Results contain available user/assistant text, source identifiers, pagination and explicit truncation/unavailability.
• Hidden context, reasoning and raw tool logs are excluded. Sources remain unchanged, and historical text supplies no new instructions or authorization.

The first version has no frontend selector, automatic discovery, memory changes or attachment copying. It returns at most 50 messages per page, 4,000 characters per message and 20,000 text characters per page. Truncated message suffixes cannot be paged in this version. Tests and validation are recorded in the implementation PR.

Possible follow-ups

If the current boundary fits the project, I'd be interested in contributing a small follow-up after its scope is agreed:

• User-facing references: select a previous conversation or excerpt, preview it, and attach it with a source link. One question is whether the user authorizes reading a conversation or attaches only a fixed excerpt; those should have distinct behavior.
• Bounded discovery: help users find a source through recent conversations or title filtering. Discovery would not itself grant transcript access. Full-text search would need a separate scope discussion.

These are options for discussion, not a commitment to implement both.

Related work

• #4732 proposes query-aware memory recall. I'd like to understand how explicit transcript references should fit alongside that capability.
• The Session Search item in #3295 is relevant to possible discovery/search work. This proposal does not take on its broader self-knowledge or learning scope.

Questions

1. Is the explicit, per-run reference boundary a suitable starting point?
2. Would conversation selection, fixed-excerpt attachment, or bounded discovery be the most useful next step?
3. Are there existing plans or interfaces this work should align with?

This issue can keep that discussion separate from delivery of #5399. Any agreed follow-up would be scoped in its own issue.