[DISCUSS] From task execution to an Always-on Agent harness

[Astro-Han]

Grok Bot, Meta Muse, ChatGPT Dots and Today.ai point toward a direction I think matters for Maka: an Agent that keeps responsibility for work between conversations. Grok Bot's architecture walkthrough and Raft are the main references I'd like to use here.

Maka's current “Bot” connects messaging channels to existing conversations. An Always-on Bot is a different harness: it maintains a continuing conversation and work process, can wake without a new user request, and decides when to contact the user.

Boundary	Current task/channel experience	Always-on Bot
Conversation	Organized around individual tasks	One continuing conversation, without a new task for each request
Trigger	User input and existing task schedules	User input, scheduled wakes, and eventually external events
Output	Assistant output appears in the task conversation and is forwarded by the WorkHub channel bridge	Internal execution stays separate; only explicit send user reaches the Bot conversation

My preference is to evolve WorkHub into this Bot, reusing its Session and task-management capabilities. I'd like @ARE404, @xxhZs and @M4n5ter's views on whether this is the right foundation and what can be removed.

Use the same names in product copy and code: Bot means the Always-on Agent; Channels means messaging ingress and delivery; Remote connection means client access to a Runtime Host. Rename the current messaging “Bot” surface to Channels. Session remains the internal conversation and work-state container.

First phase

• One Bot, existing Host. Runtime Host retains execution, Session, queuing and recovery authority. Messages and scheduled wakes continue the same Session; a Turn or Run ending does not end the Bot's conversation. Multiple Agents remain possible later.
• User input and schedules. Reuse existing queuing and steering, and ScheduledTask for one-time and recurring schedules. Control work through conversation, including stopping current work and changing or cancelling schedules; do not add a stop button.
• Files and context. Reuse WorkHub's persistent workhub-coordination directory for MEMORY.md, drafts and artifacts. Project files stay in their original directories under existing permissions; changing projects does not require a new Bot Session. Between compactions, append to a stable model context rather than rebuilding history on each wake.

Tools and interaction

• Send results deliberately. One send user tool supports Markdown, inline images, playable audio/video, files and links, including mixed content.
• Ask without blocking unrelated work. Questions offer choices, free text or skipping. Confirmations and editable approval drafts show the concrete action, destination, content and attachments. Requests return immediately; only dependent work waits. Replies stay linked to the original request, and the Host enforces approval of the final version.
• Use cards where there is an action or changing state. Connection authorization, questions, confirmations and drafts update their original card. Clients render the cards; the Host owns interaction state.
• Reuse connections and browser tools. Show configured services' connection status and authorization action in cards, reuse existing authorization, and continue the original work after connection. Prefer OpenCLI MCP with the connected browser's login state; keep the embedded browser as an optional supplement. Human handoff uses a card to open the browser and continue afterward, while the Bot stops operating that interface.
• Reuse tool and skill discovery. Keep basic tools directly available; use existing tool_search, SkillSearch and Skill for the rest. Save a workflow as SKILL.md when the user asks. No automatic plugin installation, automatic skill extraction or new memory system.

Questions for discussion

1. WorkHub as the foundation: can it become the Bot directly, and which existing mechanisms should be removed?
2. Cache-aware compaction: with a known one-hour cache TTL, should the Bot compact once after 45–50 minutes idle, measured from the last cache-using request's start? New requests reset the deadline. The next wake resumes from the saved compacted context. TTL depends on the provider and configuration; compare total cost and information loss before adopting this policy.
3. Remote connection: I think this needs a redesign covering setup, authentication, transport, reconnection and UI, without assuming the existing stack must remain. How can connection be simple and recovery return to the same Host and Session?

Defer external event triggers such as Slack messages and GitHub notifications until there is a concrete need. A separate message box like Raft's inbox is more likely to matter for group channels; first-phase direct messages use existing queuing.

Host lifecycle is a separate topic, including Desktop exit and channel/MCP connection ownership. This phase does not change it or add process sleep, VM snapshots or cloud suspension. Rust/GPUI rewrites and performance belong in a separate Discussion, linked with this one.

---

中文版（点击展开）

Grok Bot、Meta Muse、ChatGPT Dots 和 Today.ai 指向一个我认为对 Maka 很重要的方向：Agent 在两次对话之间仍然承担工作。Grok Bot 的架构分享和 Raft 是这次讨论的主要参考。

Maka 当前的“Bot”是把消息渠道接到已有对话。Always-on Bot 则是另一种 harness：维持一段持续的对话和工作过程，不需要用户每次重新发起请求才能继续，也由模型决定什么时候联系用户。

边界	当前任务／渠道体验	Always-on Bot
对话	围绕各项任务组织	一段持续对话，不因每次请求新建任务
触发	用户输入和已有任务调度	用户输入、定时唤醒，后续加入外部事件
输出	assistant 输出显示在任务对话中，并由 WorkHub 渠道桥接转发	内部执行另存，只有显式 send user 才进入 Bot 对话

我倾向于直接把 WorkHub 演进成 Bot，复用 Session 和任务管理能力。想请 @ARE404、@xxhZs 和 @M4n5ter 一起讨论：这个基础是否合适，哪些东西可以删掉。

产品文案和代码统一命名：Bot 指 Always-on Agent；Channels（消息渠道） 指消息接入和投递；Remote connection 指客户端连接 Runtime Host。当前表示消息接入的“Bot”改称消息渠道。Session 保留为内部对话和工作状态承载。

第一阶段

• 一个 Bot，复用 Host。 执行、Session、排队和恢复仍由 Runtime Host 管理。消息和定时唤醒继续同一个 Session；Turn 或 Run 结束不结束 Bot 的对话。后续不排除 multiple agents。
• 用户输入和定时任务。 复用已有排队、插话和 ScheduledTask，支持一次性与周期安排。用户直接通过对话要求停止当前工作，或修改、取消定时安排，不新增停止按钮。
• 文件和上下文。 复用 WorkHub 的持久目录 workhub-coordination，保存 MEMORY.md、草稿和产物。项目文件留在原目录，沿用已有权限；换项目不因此新建 Bot Session。两次压缩之间维持稳定的模型上下文，只追加，不在每次唤醒时重组历史。

工具与交互

• 主动发送结果。 一个 send user 工具支持 Markdown、直接展示的图片、可播放的音视频、文件和链接，也支持混合内容。
• 非阻塞提问。 支持选项、自由输入或跳过。操作确认和可编辑审批草稿展示具体动作、发送位置、正文和附件。请求立即返回，只暂停依赖回答的工作。回复关联原请求，最终版本的审批由 Host 执行。
• 需要操作或状态变化时用卡片。 连接授权、提问、确认和草稿在原卡片上更新。客户端负责展示，Host 管理交互状态。
• 复用连接与浏览器工具。 卡片展示已配置服务的连接状态和授权操作，沿用现有授权流程，连接成功后继续原工作。浏览器优先使用 OpenCLI MCP，沿用所连接浏览器的登录状态；内嵌浏览器作为按需补充。需要用户接手时，卡片提供打开浏览器和完成后继续的操作，Bot 同时停止操作该界面。
• 复用工具和技能发现。 基础工具直接可用，其余通过已有 tool_search、SkillSearch 和 Skill 使用。用户要求保存流程时写成 SKILL.md。第一阶段不自动安装插件、不自动提炼技能、不另建记忆系统。

想讨论的问题

1. WorkHub 是否适合作为基础？ 能否直接演进成 Bot，哪些已有机制应该删除？
2. 缓存失效前压缩是否值得做？ 已知缓存 TTL 为一小时时，是否从最后一次使用缓存的请求开始计时，空闲 45–50 分钟后压缩一次？新请求重置计时，下次从保存的压缩上下文继续。TTL 取决于供应商和配置，采用前需要比较总成本和信息损失。
3. Remote connection 怎么重做？ 我认为应该覆盖首次接入、认证、传输、重连和 UI，不预设保留现有网络栈。怎样让连接简单，恢复后回到同一个 Host 和 Session？

Slack 消息、GitHub 通知等外部事件触发，有具体需求后再做。类似 Raft inbox 的独立 message box 更可能在群频道里需要；第一阶段的直接消息复用已有排队。

Host 生命周期单独讨论，包括退出 Desktop 后的行为，以及渠道／MCP 连接的归属。第一阶段不改生命周期，不做进程休眠、VM 快照或云资源挂起。Rust／GPUI 重写和性能另开 Discussion，与本篇相互链接。

[Astro-Han]

Related implementation: PR #6004 by @xxhZs.

It already implements proactive checks in a continuing Session and delegates work through Host-created background Sessions. I'd like to use it as a concrete implementation reference for this discussion.

Three points to compare:

1. Can the personal-assistant entry in feat(assistant): integrate native assistance, indexed memory, and durable tasks #6004 and WorkHub converge on one Bot entry and continuing Session?
2. feat(assistant): integrate native assistance, indexed memory, and durable tasks #6004 notifies through ordinary assistant replies; this proposal uses explicit send user. How should that communication boundary be unified?
3. How should Matter delegation and scheduling relate to existing WorkHub and ScheduledTask? What can be reused or removed?

One user-facing Bot can still use internal worker Sessions. I'd like to compare these boundaries before deciding which implementation to carry forward.

中文版（点击展开）

相关实现：@xxhZs 的 PR #6004。

它已在持续的 Session 中实现主动检查，并通过 Host 创建后台 Session 执行委派任务。我想把它作为本次讨论的具体实现参考，重点对比三处：

1. feat(assistant): integrate native assistance, indexed memory, and durable tasks #6004 的个人助手入口和 WorkHub 能否收敛成一个 Bot 入口和持续 Session？
2. feat(assistant): integrate native assistance, indexed memory, and durable tasks #6004 通过普通 assistant 回复通知用户，这里的提案使用显式 send user，这个通信边界怎样统一？
3. Matter 的委派和调度与已有 WorkHub、ScheduledTask 怎样衔接，哪些可以复用或删除？

一个面向用户的 Bot 仍可使用内部 worker Session。我想先把这些边界讨论清楚，再决定沿用哪些实现。

[Astro-Han]

Why

Maka already connects IM messages to WorkHub, runs work and sends text replies back. The existing bridge also saves pending inputs and delivery records. I’d keep that foundation.

The gaps show up when I try to use it for everyday work:

• Attachments do not reach the Agent properly. Incoming media without text currently gets an unsupported-message response, and the shared outgoing interface only accepts text. Sending a screenshot or receiving a file should be part of the normal conversation. Current message handling, sending interface.
• Decisions still pull me back to Desktop. Some questions work through letter-based text replies, but permission requests and unsupported forms fall back to Desktop. Common choices and approvals should be answerable from the IM. Current interaction handling.
• Visible messages are still derived from execution output. The bridge collects assistant text and forwards it after the Turn finishes. An Always-on Bot needs to decide when to contact me, including during ongoing work. Current forwarding.
• Some message semantics are incorrect. Slack currently uses the thread root as the source message ID, so different replies in one thread can be mistaken for duplicates. Current Slack mapping.

These gaps make the phone an incomplete entry point. I want to delegate work, answer questions and receive results there without repeatedly returning to Desktop.

What

For the first phase, I’d focus on private chats with the same persistent WorkHub Bot:

• Prefer QR login or existing platform authorization. Connection cards show the connected identity, reconnect automatically after temporary network failures, and offer re-login when needed.
• Send and receive text, images, audio, video and files, preserving captions.
• Use native buttons/cards for common choices and approvals, with text and free-text answers as fallbacks. Complex forms can retain their Desktop entry.
• Let send user control visible messages. Replies return to their source chat; schedules keep their creation-time destination; other proactive messages use one default IM destination. A user instruction can override it.
• Keep activity quiet: native typing indicators during direct requests, deliberate progress messages, and no automatic tool logs or token-by-token previews.

New requests and follow-ups go directly to WorkHub. The IM entry does not need new/reset/switch-Session commands.

How

Reuse the existing adapters, login flows, WorkHub bridge, attachment storage and Host interactions. Extend the current message interfaces for media and cards. Runtime Host retains execution and interaction authority.

Remove the separate task-mode path and automatic assistant-output forwarding. Separate message ID, thread ID and reply-to ID. Keep existing WorkHub recovery, preserve pending send user messages and receipts, retry definite delivery failures, and use platform send deduplication where available.

OpenClaw and Hermes are useful implementation references. Group chats, channel monitoring, MessageBox, external event triggers, voice transcription and video processing can wait. No new channel plugin framework, multi-platform failover or Host lifecycle changes in this phase.

@ARE404 @xxhZs @M4n5ter — which gaps can be closed by extending the existing adapters, and which parts genuinely need replacement?

---

中文版（点击展开）

Why：为什么做

Maka 已经能把 IM 消息交给 WorkHub，执行工作，再把文字结果发回来。现有桥接也已经保存待处理输入和投递记录。这些基础值得保留。

真正拿它处理日常工作时，还存在几个具体缺口：

• 附件没有完整进入 Agent。 目前收到没有文字的媒体消息，会回复暂不支持；统一发送接口也只接受文字。发一张截图让它分析、收到一个处理好的文件，都应该是正常对话的一部分。现有接收逻辑、发送接口。
• 需要作决定时，仍会被拉回 Desktop。 部分问题可以回复字母选项，但权限请求和不支持的表单仍要到 Desktop 处理。常见选择和审批应该能直接在 IM 里完成。现有交互处理。
• 用户消息仍从执行输出中转发。 当前桥接收集 assistant 文字，等 Turn 结束后发送。Always-on Bot 需要自己决定什么时候联系我，也包括工作还没结束的时候。现有转发逻辑。
• 部分消息语义有问题。 Slack 当前把线程根消息当成来源消息 ID，同一线程里的不同回复可能被误判为重复消息。现有 Slack 映射。

这些缺口让手机端还不能完整承担工作入口。我希望在那里交代事情、回答问题、接收结果，不用反复回到 Desktop。

What：第一阶段做什么

先做好我与同一个持久 WorkHub Bot 的私聊：

• 优先扫码或已有平台授权。连接卡片展示连接对象；临时断网自动重连，需要重新登录时提供入口。
• 收发文字、图片、音频、视频和文件，保留附带文字。
• 常见选项和审批使用原生按钮／卡片，文字回复和自由输入兜底。复杂表单可以保留 Desktop 入口。
• 由 send user 决定用户看到的消息。普通回复原路返回，定时任务保留创建时的投递位置，其他主动消息使用一个默认 IM 入口；用户可以直接指定其他位置。
• 保持安静：直接请求使用原生“正在输入”提示，进度说明按需发送，不自动转发工具日志，不增加逐字答案预览。

新事情和追问直接交给 WorkHub。IM 入口不需要新建、重置或切换 Session 的命令。

How：怎么做

复用现有适配器、登录流程、WorkHub 桥接、附件存储和 Host 交互，扩展当前消息接口，让媒体和卡片能完整收发。执行和交互状态继续由 Runtime Host 管理。

删除独立的 task 模式路径和 assistant 输出自动转发。消息 ID、线程 ID、被回复消息 ID 分开。保留已有 WorkHub 恢复能力，保存待发送的 send user 内容和回执，明确发送失败时重试，平台支持发送去重就直接使用。

实现参考 OpenClaw 和 Hermes。群聊、频道监听、MessageBox、外部事件触发、语音转写和视频处理后移。这一阶段不新增渠道插件框架、多平台故障切换，也不改 Host 生命周期。

@ARE404 @xxhZs @M4n5ter，想听听你们的判断：哪些缺口可以直接扩展现有适配器解决，哪些部分确实需要替换？

[xxhZs]

[Colafornia]

English

Building on the #6004 comparison and @xxhZs's diagram, I think three questions still need to be settled. Here is where I lean:

1. Who manages Bot state across Runs? I suggest keeping WorkHub as the first user entry, with the Host responsible for durable inputs, pending questions, outgoing messages and recovery. Today, pending interactions end with the Run they belong to, while pending IM inputs and delivery receipts are kept in the Desktop bridge. The Inbox in the diagram seems like a good direction to follow: user messages, linked answers, scheduled wakes and task progress all enter the same Bot Session. For the implementation, I'd lean toward extending the existing Host queues and recovery first, adding only the state they cannot express, while Channels and Desktop handle delivery and presentation. Does this split of responsibilities match the intent of the diagram?

2. When unattended, when must the Bot ask the user? Approval cards decide how to ask; the Bot also needs to know when it must ask. My suggestion: a scheduled wake may continue working within the authorization already recorded, but waking does not extend that authorization; actions outside that scope, or changes that invalidate an earlier approval, should go back to the user. WorkHub currently runs with bypass together with a narrow tool profile, so expanding the Bot's tools should come with a matching permission design. Could we use this to decide the first-phase tool set and default autonomy scope?

3. Should ongoing work reuse existing mechanisms, or add a new lifecycle? My starting point: Goal manages goal state, ScheduledTask manages timing, and WorkHub delegation manages the link to worker Sessions. I suggest comparing Matter with this combination item by item to find the semantics it adds, such as coordinating a waiting condition with timed re-checks, acknowledging processed events at settle, and explicit settle with model review, and then judging whether those semantics fit as extensions of existing mechanisms or justify keeping Matter. The key is that every state change has a clear owner, so completion, waking, pausing and cancellation stay consistent. Which essential Matter semantics do you think existing mechanisms do not yet provide?

中文

结合 #6004 的对比和 @xxhZs 的图，我认为还有三个问题需要先确认，我的倾向如下：

1. 跨 Run 的 Bot 状态由谁管理？ 我建议保留 WorkHub 作为第一个用户入口，由 Host 负责持久输入、待回答问题、待发送消息和恢复。目前，待处理交互会随所在 Run 结束，而 IM 的待处理输入和投递回执保存在 Desktop 桥接里。图里的 Inbox 是一个值得沿用的方向：用户消息、关联回答、定时唤醒和任务进展进入同一个 Bot Session。实现上，我倾向于先扩展现有的 Host 队列和恢复机制，只补充它们无法表达的状态；渠道和 Desktop 负责投递与展示。这个职责划分是否符合图里的意图？

2. 无人值守时，什么时候必须询问用户？ 审批卡片解决的是"怎样询问"，Bot 还需要明确"什么时候必须询问"。我的建议是：定时唤醒可以在已记录的授权范围内继续工作，但唤醒本身不扩大授权；超出范围的操作，或者让此前批准失效的变化，应重新交给用户决定。WorkHub 当前使用 bypass，配合较窄的工具 profile，所以扩展 Bot 的工具时需要同时设计权限。是否可以据此确定第一阶段的工具集和默认自主范围？

3. 持续工作是复用现有机制，还是增加一套新的生命周期？ 我的出发点是：Goal 管目标状态，ScheduledTask 管时间安排，WorkHub 委派管理与 worker Session 的关联。建议把 Matter 和这个组合逐项比较，找出它额外提供的语义，例如等待条件与定时复查的配合、settle（结算）时确认已处理的事件、显式 settle 和模型审核，再判断这些语义适合扩展现有机制，还是足以支持保留 Matter。关键是每个状态变化都有明确的管理方，让完成、唤醒、暂停和取消保持一致。你们认为 Matter 中有哪些必要语义是现有机制尚未提供的？