Repository navigation
RFC(assistant): tool boundaries, delegation ownership and heartbeat cost of the discovery session #6247
Description
Summary
This RFC tracks product decisions for the personal assistant's proactive discovery. The ownership and capability bugs are split out as #6249 and #6250. Probe results from those bugs and the review on this thread have changed several positions below. Items marked revised differ from the previous version.
Verified so far (origin/main@59f61cf7d)
| Area | Status |
|---|---|
| Discovery-created Matters invisible to the conversation | Reproduced (#6249) |
| Completion and clarification from those Matters | Reproduced: they go to the discovery Session, not the Bot inbox (#6249) |
| Discovery Session can mutate conversation memory indexes and adopt unassigned Matters | Reproduced (#6250) |
| Discovery Session rejected for Bot-only, conversation-scoped and own-activation tools | Reproduced (#6250) |
| Heartbeat gate, topic disposition, spending policy | Design questions; no code changes proposed here |
Decisions
- Discovery direction. Keep open-ended exploration, or drive it toward the user's stated goals? This determines the discovery prompt and whether a change-driven path is useful.
- Discovery capability boundary. Revised. Do not derive it from
BOT_TOOLS. Define a discovery-specific allowlist: read tools,DiscoveryReport,DiscoveryContext. Open questions:MemorySourceQuery(external reads) andMemoryExtract(LLM call and cost). Delegation from discovery is rejected; discovery reports the need to the Bot. - Change-driven gate. Revised. "No observed change means no model call" applies only to event-triggered paths. Scheduled open-ended exploration should keep its open-ended character. Question: do we want a change-driven path at all, and what should it look like?
- Cost visibility before limits. Revised. Hard Matter round or time limits stay removed, because earlier limits left useful work unfinished. First add observability: daily model calls; input, cache and output tokens; duration; activations per Matter; whether each run reported anything. User-configured budgets are a separate policy discussion.
- Topic disposition. Revised. The README sentence "no pending/processed state or InboxUpdate" describes Bot inbox batch delivery. It does not rule out remembering that a user handled, rejected or no longer wants a topic. Keep three states separate: investigated, withheld, told the user. A material change may make a previously discussed topic relevant again.
- Failure mode: loss of initiative. New. A reviewer observed in recent local runs that a persistent discovery Session concentrates on familiar topics and their changes, then goes quiet, despite a prompt that permits broader exploration. Evaluation must cover missed useful discoveries as well as repeated notifications, latency and cost.
Sequencing
Per review: fix ownership and capability bugs first, with targeted regression tests (#6249, #6250). Heartbeat gating, topic disposition and spending policy are separate product decisions.
Changes from the previous version
- "Heartbeat has no change gate" is scoped to change-driven paths (decision 3).
- "Matters have no round or spend limit" is reframed as cost observability (decision 4). It is no longer a request for limits.
- "Wakes lack state context" is withdrawn as a defect. Discovery retrieves context on demand by design. A useful addition would be a query for changes since the previous check: a feature request, not a bug.
- Decision 5 previously said the README rules out a processed state. That misread the Inbox paragraph.
- Decision 2 previously proposed the same ceiling as the Bot. Withdrawn; see decision 2.
Related
- bug(assistant): MatterDelegate from the discovery session creates a Matter the conversation cannot see #6249, bug(assistant): discovery session can mutate conversation memory indexes and adopt unassigned Matters #6250
- tracking(runtime-host): condition-driven Session waits and wake-ups #5926 condition-driven waits and wake-ups
- Refactor WorkHub around a simpler coordination and configuration model #5745, tracking(desktop): evolve WorkHub into a per-Runtime-Host conversational coordinator #3492 WorkHub direction
中文版（点击展开）
标题： RFC(assistant)：探索会话的工具边界、委派归属与心跳成本
概要
本 RFC 跟踪个人助手主动探索的产品决策。归属与能力问题已拆分为 #6249 和 #6250。这两个 bug 的探针结果以及本帖的评审意见，改变了下面几项的立场。标注为 已修订 的条目与之前的版本不同。
目前已验证的内容（origin/main@59f61cf）
| 范围 | 状态 |
|---|---|
| 探索会话创建的事项，对话看不到 | 已复现（#6249） |
| 这些事项的完成通知与澄清请求 | 已复现：送到探索会话，而不是 Bot 收件箱（#6249） |
| 探索会话可以修改对话的记忆索引，并接管未分配的事项 | 已复现（#6250） |
| 探索会话调用 Bot 专用、对话作用域和需要自身激活的工具时被拒绝 | 已复现（#6250） |
| 心跳门控、话题处置、成本策略 | 设计问题；本文不提出代码改动 |
决策
- 探索的方向。 保持开放式探索，还是围绕用户明确的目标推进？这决定探索的提示词，也决定变化驱动路径是否有意义。
- 探索的能力边界。 已修订。 不再以
BOT_TOOLS为基准，改为探索专用白名单：读取类工具、DiscoveryReport、DiscoveryContext。待定：MemorySourceQuery（外部读取）和MemoryExtract（会发起 LLM 调用，有成本）。探索会话的委派被拒绝；需要委派时，由探索会话告知 Bot。 - 变化驱动的门控。 已修订。 "无变化就不调用模型"只适用于事件触发的路径。定时的开放式探索应保持其开放性。问题：是否需要变化驱动路径，它应该是什么样子？
- 先做成本可观测，再谈上限。 已修订。 Matter 的硬性轮次或时间上限保持取消，因为之前的上限让有用的工作没有做完。先增加可观测性：每日模型调用次数；输入、缓存和输出 token；耗时；每件事项的激活次数；每轮是否有上报。用户可配置的预算是另一项策略讨论。
- 话题处置。 已修订。 README 中 "no pending/processed state or InboxUpdate" 这句话描述的是 Bot 收件箱的批量投递，并不排除记住用户已处理、已拒绝或不再关心某个话题。应把三种状态分开：已调查、已压制、已告知用户。重大变化可能让之前讨论过的话题重新变得相关。
- 失败模式：主动性丧失。 新增。 评审者在近期的本地运行中观察到：持续运行的探索会话会逐渐集中到熟悉的话题及其变化上，然后沉默，即使提示词允许更广泛的探索。评估需要同时覆盖漏掉的有用发现，以及重复通知、延迟和成本。
推进顺序
按评审意见：先用有针对性的回归测试修复归属与能力问题（#6249、#6250）。心跳门控、话题处置和成本策略作为单独的产品决策讨论。
相对于之前版本的变化
- "心跳没有变化门控" 收窄为只适用于变化驱动路径（决策 3）。
- "持续事项没有轮次或花费上限" 改为成本可观测性（决策 4），不再是加上限的请求。
- "唤醒缺少状态上下文" 不再视为缺陷。探索按设计按需检索上下文。有用的补充是一个"自上次检查以来的变化"查询入口，这是功能需求，不是 bug。
- 决策 5 之前说 README 排除了 processed 状态，这是对 Inbox 段落的误读。
- 决策 2 之前提议与 Bot 相同的天花板，现已撤回，见决策 2。
相关
- bug(assistant): MatterDelegate from the discovery session creates a Matter the conversation cannot see #6249、bug(assistant): discovery session can mutate conversation memory indexes and adopt unassigned Matters #6250
- tracking(runtime-host): condition-driven Session waits and wake-ups #5926 条件式等待与唤醒
- Refactor WorkHub around a simpler coordination and configuration model #5745、tracking(desktop): evolve WorkHub into a per-Runtime-Host conversational coordinator #3492 WorkHub 方向
Activity
[-]RFC(assistant): 探索会话的工具边界、委派归属与心跳成本——对照 main 的核对结果与待决策项[/-][+]RFC(assistant): tool boundaries, delegation ownership and heartbeat cost of the discovery session[/+]liugddx commentedon Oct 23, 2026
N1 and N2 are now split into separate bug reports so they can be tracked and fixed independently:
MatterDelegatefrom the discovery session creates a Matter the conversation cannot see (reproduced at59f61cf7d).BOT_TOOLS).Points still open in this RFC (decisions 1, 3, 4, 5 above) are unchanged. Decision 2 (discovery tool boundary) is now the scope of #6250.
中文版（点击展开）
N1 和 N2 已拆分为独立的 bug report，便于分别跟踪和修复：
MatterDelegate创建的事项，对话看不到（在59f61cf7d上复现）。BOT_TOOLS中）。本 RFC 中尚未决定的事项（上文的决策 1、3、4、5）不变。决策 2（探索的工具边界）现在属于 #6250 的范围。
xxhZs commentedon Oct 23, 2026
Thanks for splitting out #6249 and #6250. I support fixing the ownership and capability-boundary bugs first, while keeping the broader product decisions separate. These comments follow a review of
main@59f61cf7dand recent local discovery runs; I have not independently rerun the reproduction probes in those issues.Ownership and discovery capabilities. For the current design, rejecting delegation from discovery is consistent with its documented role: report the need to the Bot for coordination instead of creating a Matter invisible to the conversation. Please also test the completion/clarification return path; creation and visibility were reproduced, but completion delivery remains a code-based conclusion in bug(assistant): MatterDelegate from the discovery session creates a Matter the conversation cannot see #6249. For bug(assistant): discovery session can mutate conversation memory indexes and adopt unassigned Matters #6250, define a discovery-specific capability boundary rather than copying
BOT_TOOLS: the Bot is a coordinator, and tools outside its list include legitimate discovery capabilities such asDiscoveryReport,DiscoveryContextand source queries. Catalog exposure and successful unauthorized execution should be distinguished; existing-target writes and native shell/edit behavior still need verification.Change-driven attention and open-ended exploration can coexist. A frequent check can start from changes and retrieve related history, while less frequent exploration can find value in existing information and external sources. “No observed changes = zero model calls” should not be a universal invariant for scheduled discovery. For an event-triggered path, no event can mean no run without restricting the Agent's ability to investigate historical context once awake.
On-demand context is intentional. Not injecting a summary into every wake is not itself a defect. The Agent should retrieve context through tools. An efficient query entry point for changes since the previous check would help, while retaining access to the notebook, indexes and original history. We do not need to put large incremental payloads into the wake prompt.
Cost visibility before hard limits. Daily model calls, input/cache/output usage, duration, per-Matter activations and per-run reporting outcomes would help evaluate value. Please preserve the deliberate removal of hard Matter round/time limits: these previously left useful work unfinished. User-configured budget policies can be discussed separately rather than entering incidentally with the bug fixes.
Inbox delivery state is not topic disposition. The absence of
pending/processedorInboxUpdateconcerns batch delivery to the Bot. It does not rule out remembering that a user handled, rejected or no longer wants a topic. Respecting that feedback does not require restoring complex Inbox maintenance. “Previously investigated,” “previously withheld,” and “actually told the user” are also different; material changes can make a previously discussed topic relevant again.Test loss of initiative as well as repetition. Recent local runs also show the opposite failure: a persistent discovery session increasingly concentrates on familiar topics and their changes, then goes quiet, even with a prompt explicitly permitting exploration beyond incremental information. This does not establish session-history growth as the sole cause, but stronger suppression alone will not address both failure modes. Evaluation should cover missed useful discoveries, repeated notifications, latency and cost.
My preference is targeted ownership/capability fixes first, with heartbeat gating, topic-disposition behavior and spending policies discussed separately. I have also sent these points to the linked mailing-list discussion.
liugddx commentedon Oct 23, 2026
Thanks for the review. I have revised the RFC body. Decisions 2–5 and the related items now follow it: the discovery boundary is a discovery-specific allowlist rather than
BOT_TOOLS, the change gate applies only to change-driven paths, cost work starts with observability, and topic disposition is separated from Inbox state. #6250 is narrowed to the execution results from the probes. #6249 now includes the completion and clarification results.中文版（点击展开）
感谢评审。我已修订 RFC 正文：决策 2–5 及相关条目已按评审意见调整。探索的边界改为探索专用白名单而非
BOT_TOOLS；门控只适用于变化驱动路径；成本工作先做可观测性；话题处置与 Inbox 状态分开。#6250 已收窄为探针中已执行的工具。#6249 补充了完成通知与澄清请求的结果。liugddx commentedon Oct 23, 2026
PR #6256 implements the ownership and capability items this review agreed to fix first (#6249, #6250), with regression tests. Decisions 1, 3, 4 and 5 (discovery direction, change-driven gate, cost observability, topic disposition) are unchanged and still open.
中文版（点击展开）
PR #6256 实现了评审中同意优先修复的归属与能力问题（#6249、#6250），并附回归测试。决策 1、3、4、5（探索方向、变化驱动门控、成本可观测性、话题处置）保持不变，仍待讨论。