Proposal: WorkHub as a unified conversational entry point for all work

[ARE404]

Problem

Maka currently organizes work through Projects and Sessions. This gives each task a clear context, permission boundary, execution history, and recovery path, but it also requires users to manage routing themselves.

When working on several things, users must repeatedly remember:

• which Project contains the work;
• which Session should receive the next message;
• where the previous conversation stopped;
• whether a new Session should be created;
• which Sessions need to be checked for progress.

This is navigation and context-management work rather than the user's actual work.

The cost is particularly visible for non-technical users and on mobile devices, where navigating a hierarchy of Projects and Sessions is more expensive.

Desired outcome

Maka should provide one permanent conversational entry point where users can understand and advance all their work without manually selecting a Session first.

The proposed user-facing name is WorkHub. "Unified Session" refers to the current experiment, while "Work Orchestrator" describes the internal coordination role.

From WorkHub, a user should be able to:

• ask what work is currently active;
• ask for the progress of a particular Work;
• continue an existing Work using natural references such as "continue the login issue";
• start a new Work without manually creating a Session;
• coordinate multiple Works and their dependencies;
• answer permission requests and clarification questions in place;
• enter the underlying Session whenever detailed control is needed.

The user should manage goals and priorities. Maka should manage routing.

Proposed user experience

WorkHub should behave like an ordinary Maka conversation rather than a separate administrative dashboard.

A user message can produce one of four outcomes:

1. Discussion

   Exploratory or ambiguous conversation remains in WorkHub. Maka does not create a Work merely because a topic was mentioned.

2. Resume an existing Work

   When the intended Work can be identified with sufficient confidence, Maka binds the message to the Session that owns that Work.

3. Create a new Work

   When the user expresses a clear execution goal and no suitable Work exists, Maka creates a normal Session and presents it as a new Work.

4. Clarify

   When multiple targets are plausible, especially before file changes or external side effects, Maka asks the user to select the intended Work instead of silently guessing.

Each Work is displayed as an independent message block. Project and Work information should remain visible but visually secondary. WorkHub should otherwise reuse the normal Session layout, message components, composer, permissions, and interaction cards.

Product and architecture principles

Sessions remain authoritative

This proposal does not replace or merge ordinary Sessions.

Each Session continues to own its:

• conversation and execution history;
• model and permission mode;
• Project and filesystem scope;
• tool calls and artifacts;
• interruption and recovery state;
• archive and deletion semantics.

WorkHub is an orchestration and projection layer over those Sessions.

Routing is bounded

A model must not invent Session identities or freely choose arbitrary execution targets.

Existing deterministic filtering should produce a bounded set of Work candidates. Semantic intent recognition may select from those candidates, request clarification, create a new Work, keep the message as Discussion, or coordinate several explicit Works.

When the cost of a wrong binding is asymmetric, Maka should prefer one clarification question over confident misrouting.

One executable turn has one Work authority

A message that changes files or produces external effects must be bound to one Work before execution.

Requests involving several Works should be decomposed into explicit Work turns and coordinated through the existing Graph dependency model.

The feature must remain reversible

Users can always open an ordinary Session and continue working there.

Disabling WorkHub restores the ordinary navigation behavior without deleting the Works, Sessions, or history created through it.

Alternatives or workarounds

Improve Session search and navigation

Better search and faster switching reduce the number of clicks, but users still need to understand the Session structure and decide where every message belongs. This reduces switching cost without removing routing as a user responsibility.

Merge all Sessions into one context

A single transcript would appear seamless, but it would mix unrelated context, permissions, recovery state, and deletion semantics. It would also create an indefinitely growing model context.

Add a work-status dashboard

A dashboard helps users inspect progress, but users must still leave it and find the appropriate Session before they can continue working. It solves visibility without providing one place to advance the work.

Why WorkHub

WorkHub combines global work visibility with a conversational control surface while preserving independent Session authorities.

Users can understand, continue, create, and coordinate all their work in one place without managing the underlying Session routing.

Experimental implementation

A working experiment currently demonstrates:

• a permanent unified entry;
• Discussion without eager Session creation;
• creating and resuming Work;
• bounded target recognition;
• clarification and retargeting;
• Project / Work attribution;
• independent permission handling;
• low-noise lifecycle projection;
• Graph-based coordination across Works.

The experiment is evidence of feasibility, not a predetermined final implementation.

Illustrated overview:

https://github.com/ARE404/maka-agent/blob/codex/unified-session-experiment/UNIFIED_SESSION_EXPERIMENT.zh-CN.md

Experimental branch:

https://github.com/ARE404/maka-agent/tree/codex/unified-session-experiment

Scope

The intended product contract covers all Maka Workspaces registered in the application.

The first production implementation may be delivered in smaller slices, but it should not establish a model that makes cross-Workspace work impossible later.

Non-goals

• Removing ordinary Sessions.
• Combining every Session transcript into one model context.
• Sharing permissions implicitly across Works.
• Allowing an LLM to invent execution targets.
• Hiding irreversible effects after a Work is redirected.
• Solving cloud or cross-device synchronization in the first milestone.

Open questions

1. When WorkHub is enabled, should it become Maka's default application entry point?
2. What evidence and confidence should be required before automatically binding to an existing Work?
3. Which operations should always require explicit target confirmation because they may modify files or produce external side effects?
4. What is the smallest production milestone that preserves the intended cross-Workspace model?
5. Which product metrics can demonstrate that WorkHub actually reduces navigation, Session management, and context-switching burden?

Feedback on the user model, terminology, safety boundaries, and rollout scope is welcome.

[likun666661]

I think there may be a deeper simplification behind WorkHub.

If we start from the agent loop, a Session is primarily a container for an ordered set of messages plus an execution boundary. Once Work becomes the durable user-facing concept, it is worth asking whether Session still needs to be a primary domain entity at all.

A possible alternative model is:

• Event: an immutable fact appended to the log
• Work: a durable projection of events around a user goal
• Run / Attempt: one concrete agent-loop execution
• Context Snapshot: the exact events selected for a Run
• Authority Snapshot: the filesystem, permission, model, and tool scope for that Run

In this model, Session can remain as a compatibility or UI projection, but it no longer has to be the storage or authority primitive.

The underlying structure would not really be a single transcript. Physically, it can be an append-only sequence, but logically it is a temporal causal graph. Events need typed relationships such as:

• reply_to
• caused_by
• retrieved_from
• derived_from
• supersedes
• depends_on
• belongs_to

For example, if message C was generated because message B was retrieved into the previous context, that should be represented through a persisted Context Snapshot rather than inferred later from transcript proximity. This would make agent behavior auditable and replayable.

From this perspective, WorkHub routing becomes a large-scale Event Log search problem, but I think it should be split into two distinct retrieval stages:

1. Global Work/reference resolution

   Search a bounded, privacy-filtered routing index using BM25, semantic retrieval, entity matching, graph proximity, Work Focus, and temporal signals. Produce a lightweight intent projection such as: “I think you mean Work X, with this goal and scope.”

2. Scoped execution-context retrieval

   Only after the Work is selected or confirmed, search the detailed events inside that authority scope, expand causal neighbors, reduce superseded state, and produce the immutable Context Snapshot used by the next agent Run.

This separation matters because global target identification and execution-context construction have different safety requirements. A global message search should not automatically become execution authority or inject unrelated raw history into the agent context.

User confirmation can then be risk-based:

• low-risk, high-confidence references may bind automatically while showing the selected Work;
• ambiguous or high-side-effect actions should first return the candidate projection for confirmation;
• the confirmed binding itself should be appended as an event.

Time also needs richer treatment than a general recency score. Recent conversational messages may decay quickly, while decisions, unresolved permissions, and architectural constraints remain important. The system should distinguish event time from ingest time and understand supersedes relationships so that historical evidence is searchable without being mistaken for current truth.

So the deeper question may be:

Could Work be a projection over an append-only temporal causal graph, with Session reduced to a derived view, rather than Work being a wrapper around Session?

Even if Session is removed as a concept, its operational responsibilities do not disappear. Execution isolation, permissions, cancellation, recovery, and concurrency would move explicitly into Run, Authority Snapshot, and causal-branch primitives.

For an MVP, the existing one-Work/one-Session implementation may still be the practical path. However, keeping workId independent from sessionId, and defining Event, Run, Context Snapshot, and typed causal relationships early, would avoid making the eventual architecture depend on Session as the permanent information boundary.

[Astro-Han]

Thanks, this pushed me to go read the actual source code.

The read side of your framing already runs inside Maka. The execution domain is an append-only per-run ledger with a monotonic sequence, plus a projection cache keyed by session and event type. The same events/projections pair shows up again for task runs and workflow plans. Canonical terminal turn status is computed from the immutable runtime event ledger, not read from a stored snapshot. For a completed run, the canonical read model itself declares source: 'runtime_events'; the stored session_messages table works as an in-flight and compatibility fallback.

What does not exist is the recall layer. No full-text, BM25, or semantic index anywhere in the tree. Search today is a bounded substring scan. That gap is roughly WorkHub sized: a read model that can answer where things stand without opening every session.

The write side is where Session stops being a cache and becomes the authority. Sessions own the model, connection, backend, archive state, the permission boundary, and the working-directory binding. Those are not projections. File contents, external system state, and manual edits live outside the event ledger, and no replay rebuilds them.

One detail in the code makes this concrete: root turn admissions per session must form a single linear chain, and branching is a hard error. A recall layer can rank events, but it cannot decide who appends the next root turn. That arbitration is the real thing a Session-less design has to re-home, not the display layer.

So on the read side, Session as navigation should fold into a projected WorkHub over the event feed. On the write side, the question is not whether Session disappears, but which authority takes over lifecycle, boundary evolution, recovery identity, and turn-append arbitration. For an MVP, WorkHub as a projection over Sessions is the smallest viable step, and keeping workId separate from sessionId leaves the deeper model open.

---

中文版：

顺着你这个角度去看代码，读侧的部分其实 Maka 已经在做了。执行域就是按 run 追加的不可变事件表，配一张按 session 和事件类型缓存最新值的投影表，task run 和 workflow plan 也走同一套 events/projections 结构。turn 的终态（完成/失败/中断）是从不可变运行时事件里现算出来的，不读现成快照；已完成 run 的权威读模型自己也声明 source: 'runtime_events'，session_messages 只是保底/兼容的投影缓存。

真正缺的是召回层。整个仓库没有全文索引、没有 BM25、没有向量索引，现在的搜索就是个限范围的子串扫描。这个洞正好是 WorkHub 该填的：不用打开每个 session 就能回答"现在到哪了"的读模型。

写侧才是 Session 从缓存变成权威的地方。模型、连接、backend、归档状态、权限边界、工作目录绑定都挂在 Session 上；这些不是投影。文件内容、外部系统状态、用户手动改的东西都不在事件账本里，重放重建不出来。

代码里有个更直接的证据：每个 session 的 root turn 受理必须构成唯一一条线性链，分叉直接报错。召回能排候选，但仲裁不了"下一条 root turn 谁写"。这才是去 Session 之后真正要迁移的东西，不是展示层。

所以读侧，Session 作为导航应当融进事件流上的 WorkHub 投影；写侧，问题不是 Session 要不要消失，而是生命周期、边界演进、恢复身份、turn 追加仲裁这些职责交给谁。MVP 里 WorkHub 作为 Session 之上的投影是最小可行的口径，workId 与 sessionId 解耦，后面那条更难的路才走得通。

---

Note: this reply was drafted with AI assistance, reviewed by the author against the source, and edited by hand before posting.

[Astro-Han]

Reading this together with the proposal and Li's event-log framing, here is our take and where it agrees or splits with the other two.

Our proposal: a Hub main agent, not a new Work entity.

We want to keep the existing Session/Project model untouched and add one permanent conversational entry: a single global main agent living in a persistent Hub session. The user talks only to this agent. Work is not a new domain abstraction; it is whatever the main agent decides to orchestrate. Each work is executed by subagents (existing Sessions are simply treated as agent units too), each gets a sandbox and an automatically scoped task, failures are handled by the main agent (retry, reroute, degrade) instead of being pushed to the user, and the user sees results only. The UI is a conversation stream, mobile-first, with work details hidden until asked.

Where we agree with the WorkHub proposal:

• Sessions stay authoritative. Existing Sessions and Projects are untouched; the Hub is an alternative view on top of them, so both data models stay interoperable.
• One entry point, and the system owns routing.
• Confirmation is risk-based: automatic when low-risk, explicit when ambiguous or high-side-effect.

Where we differ from the proposal:

• Work is not an entity with its own id, lifecycle, and dependency graph. That abstraction layer is not needed if the main agent orchestrates everything.
• The work boundary is defined by the subagent sandbox scope, not by a Work object.
• Mobile-first: the Hub is an IM-style surface; drilling into the underlying Session is not a primary interaction.

Where we agree with Li's event-log view:

• Session is not the center of the user's world. The main agent (and the event stream under the Hub) is.
• The underlying storage is an event log, and the Hub conversation itself is one.
• Confirmation is risk-tiered.

Where we split with Li:

• Li puts large-scale retrieval at the center: one big event log, organized by semantic/keyword search, Context Snapshots, Authority Snapshots, and typed causal relationships.
• We put orchestration at the center. Retrieval is supporting machinery (locating a task like "continue that login issue", rebuilding context), not the organizing principle. Authority is not decomposed into explicit snapshots; it stays in the Runtime's permission and confirmation mechanism and in the main agent's orchestration.
• Li treats the Session as removable in principle; we keep it (untouched, as a view) because removing it would break the existing data model.

What all three share: users should not manually manage Session routing; the bottom layer is an event stream; confirmation should be risk-based and reversible.

Open questions for the discussion: is Work worth keeping as its own entity, or is a main agent's orchestration view enough? And is large-scale retrieval the core mechanism, or is orchestration?

---

中文版：

结合李坤那条事件流的视角，我把我们的方案跟两边摆在一起，说说异同。

我们的主张：一个 Hub 主 Agent，不造 Work 实体。

现有 Session/Project 完全不动，在上面加一个永久对话入口：全局唯一的主 Agent，住在常驻的 Hub 会话里，用户只跟它说话。Work 不是新的领域实体，只是主 Agent 眼里的一个编排容器。每件工作由子 Agent 干（历史 Session 也统一当作 Agent 单位），每个子 Agent 拿到沙箱、范围自动划定，出错由主 Agent 自己编排（重试、换路、降级），不推到用户面前，用户只看结果。界面就是对话流，移动优先，细节默认藏着。

和 WorkHub 提案一致的地方：

• Session 依然权威。现有 Session/Project 不动，Hub 是叠在上面的另一层视图，两套数据互通。
• 单一入口，路由归系统。
• 确认按风险分级：低风险自动，含糊才问。

和提案不一样的地方：

• Work 不做成有 id、生命周期、依赖图的实体，这层抽象没必要。
• 工作的边界由子 Agent 的沙盒范围定义，不是由 Work 对象定义。
• 移动优先：Hub 是 IM 形态，钻进底层 Session 不是主要交互。

和李坤一致的地方：

• Session 不是用户世界的中心，主 Agent（和它背后的事件流）才是。
• 底层是事件流，Hub 会话本身就是一条事件流。
• 确认按风险分级。

和李坤分岔的地方：

• 李坤把大规模检索当核心：一条大事件流，靠语义/关键词搜索、Context 快照、Authority 快照、类型化因果关系组织一切。
• 我们把编排当核心：检索只是支撑（定位、恢复上下文），不是组织原则；权限不拆成显式快照，留在 Runtime 的权限/确认机制和主 Agent 的编排里。
• 李坤原则上可以去掉 Session；我们保留它不动它，因为去掉会破坏现有数据模型。

三方共同点：用户不该手动管 Session 路由；底层都是事件流；确认要风险分级、可逆。

想请大家讨论：Work 值不值得做成独立实体，还是主 Agent 的编排视图就够？核心机制到底是检索还是编排？

---

Note: this reply was drafted with AI assistance, reviewed by the author, and edited by hand before posting.