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:
-
Discussion
Exploratory or ambiguous conversation remains in WorkHub. Maka does not create a Work merely because a topic was mentioned.
-
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.
-
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.
-
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
- When WorkHub is enabled, should it become Maka's default application entry point?
- What evidence and confidence should be required before automatically binding to an existing Work?
- Which operations should always require explicit target confirmation because they may modify files or produce external side effects?
- What is the smallest production milestone that preserves the intended cross-Workspace model?
- 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.
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:
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:
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:
Discussion
Exploratory or ambiguous conversation remains in WorkHub. Maka does not create a Work merely because a topic was mentioned.
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.
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.
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:
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:
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
Open questions
Feedback on the user model, terminology, safety boundaries, and rollout scope is welcome.