roadmap(product): evolve Maka into a durable Agent workspace #2469

Problem

Maka already has a substantial Agent Runtime: local-first state, Runtime and Task event ledgers, permissions, Artifacts, Memory, Automations, Plan/Agent collaboration, Graph/subagent orchestration, Headless execution, and recovery semantics shared across Desktop, CLI, TUI, and Headless.

The product experience does not yet express those capabilities as one understandable work system. Users still have to infer important state from conversations, tool cards, settings, and implementation concepts:

• whether Maka is actually ready to accept a task;
• what the current task is doing and how far it has progressed;
• whether an Agent is running, waiting, blocked, or recoverable;
• which delegated worker owns which part of the work;
• whether completion is supported by execution evidence;
• what is safe to resume after an interruption.

This creates a gap between Maka's backend strengths and its user-facing value. The next product pass should not add more top-level Agent modes or tools. It should turn the existing Runtime into a clear, controllable, evidence-backed task experience.

Product direction

Position Maka as:

A local-first, recoverable, and auditable Agent workspace for work that must finish.

The product model should move from:

conversation -> messages -> tool logs -> final assistant message

toward:

project -> task -> state -> execution -> evidence -> deliverables -> resume or follow-up

Conversation remains an important interaction surface, but it should not be the only representation of work.

Product principles

Conversation is an interface, not the work object

A task needs an explicit goal, state, execution progress, permissions, delegated work, deliverables, evidence, and recovery status. Chat is how the user collaborates with that task.

Every task has an observable state

Users should not need to read raw tool output to distinguish discussion, planning, running, waiting for the user, waiting for an external condition, blocked, recoverable, failed, and completed work.

Every completion has evidence

An Agent's claim that work is complete is not sufficient authority. Completion should reference existing execution facts such as changed files, commands, test results, Artifacts, unresolved items, and known risks.

Every interruption has an honest recovery decision

Maka should distinguish safe retry, safe continuation, required revalidation, unknown external side effects, and cases that require an explicit user decision.

Scope

This roadmap is primarily a product-experience and projection effort. It should reuse current Runtime authorities rather than inventing another task/event store.

Phase 0: reconcile product truth

• Audit open product issues against the current implementation.
• Close issues whose intended behavior has shipped.
• Rewrite partially completed issues around their actual remaining scope.
• Mark proposals superseded by newer Runtime or product architecture.
• Publish a current capability matrix for Desktop, CLI/TUI, Headless, Plan, Graph/subagents, Resume, Memory, Automation, Artifacts, and Evidence.

Phase 1: make first success reliable

• Define one shared readiness snapshot for Runtime Host, model target, workspace, tools, Git, and permissions.
• Surface readiness failures before task submission with a cause and a direct repair action.
• Prevent configuration drift, such as an unavailable default model, from appearing as a late unrelated feature error.
• Establish one real first-success journey: configure a model, open a project, complete a small change, inspect the diff, run validation, and review the result.
• Measure time to first verified result on Desktop and cover an equivalent CLI smoke path.

Phase 2: make task state legible

• Project task status from existing Session, AgentRun, TaskRun, plan, permission, and recovery facts.
• Add a compact task status header showing phase, progress, active delegated work, waiting conditions, intervention needs, elapsed time, and risk.
• Present user-facing autonomy levels such as discuss, plan first, execute, and continue until done.
• Keep Plan, Agent, Graph, Swarm, and Headless as Runtime mechanisms or advanced controls instead of requiring every user to understand them as peer product modes.

Phase 3: make completion reviewable

• Define an evidence-backed Completion Packet projection.
• Include completed objective, changed files, validation results, produced Artifacts, unresolved work, known risks, and suggested next steps.
• Render the same semantics appropriately in Desktop and CLI.
• Support a portable Markdown export without creating a second source of truth.

Phase 4: make delegation understandable

• Continue feat(desktop): surface linked child sessions in the session workbar #1457 and move linked child work into the session workbar.
• Show what each child owns, why it was created, and whether it is running, waiting, failed, or complete.
• Allow users to inspect, interrupt, supplement, or take over delegated work.
• Fold Graph into the same delegated-work surface instead of maintaining competing orchestration views.
• Keep the parent Agent responsible for final synthesis.

Phase 5: productize evidence and recovery

• Build the pure RuntimeEvent trace projection proposed by [RFC] Session Inspector: a per-session runtime event trace, replay, and cost-attribution surface #1625.
• Use trace facts first in Completion Packets and failure explanations.
• Add a Recovery Card that explains confirmed progress, unknown side effects, revalidation requirements, and safe next actions.
• Add deeper trace search and replay only after the primary completion and recovery journeys are useful.

Phase 6: unify long-running work

• Make Automations create ordinary observable Tasks rather than a separate result model.
• Treat Daily Review as a task template.
• Surface Headless TaskRuns in Desktop with the same state, evidence, pause, and recovery semantics.
• Give Memory entries explicit source, scope, freshness, and context-injection semantics.
• Add background execution, budgets, and notifications only through the shared task model.

Non-goals

This roadmap does not propose:

• rewriting the Runtime;
• adding another event or task authority;
• a big-bang Desktop redesign;
• additional top-level Agent modes;
• more tools or providers as part of this work;
• a decorative Graph visualization before delegated-work status is understandable;
• using visual polish as a substitute for information architecture;
• expanding unattended autonomy before completion and recovery are trustworthy.

Delivery constraints

• Each child issue and PR must be independently reviewable and reversible.
• Prefer pure projections over existing authoritative facts.
• Desktop, CLI, and TUI may use different layouts but must share state semantics.
• Every task-facing surface must account for loading, empty, running, waiting, failed, recoverable, and completed states where applicable.
• High-risk flows need behavior or real-journey tests, not only source-text contracts.
• Do not expose a new top-level module when an existing task or workbar surface can own the experience.

Success criteria

Activation

• A new user can reach a first verified result within 10 minutes.
• Invalid model or environment configuration is actionable before task submission.

Comprehension

• A user can identify whether work is running, waiting, blocked, recoverable, or complete within a few seconds.
• Primary progress does not require reading raw tool logs.

Trust

• Completed work includes validation evidence by default.
• Unknown tool side effects are never presented as safe failure or success.
• Model self-report does not replace Runtime facts.

Continuity

• After restart, Maka can explain where work stopped and which continuation choices are safe.
• Interactive, automated, delegated, and Headless work share task-state and result semantics.

Initial issue split

1. Audit current product issues and capability status.
2. Define a shared Maka readiness snapshot.
3. Surface actionable startup/task-submission readiness in Desktop.
4. Cover the first successful task journey in Desktop and CLI.
5. Define a task-status projection over existing execution facts.
6. Add the task status header.
7. Define the Completion Packet projection.
8. Present evidence-backed completion in Desktop and CLI.

The first implementation milestone should stop after readiness and first-success evidence are working. Task status and Completion Packet follow on that stable foundation.

Related

• roadmap: durable agent platform #544 — durable Agent platform roadmap
• feat(desktop): surface linked child sessions in the session workbar #1457 — linked child sessions in the session workbar
• [RFC] Session Inspector: a per-session runtime event trace, replay, and cost-attribution surface #1625 — Session Inspector and RuntimeEvent trace
• feat(ui): discuss priority-based conversation ordering and activity filtering #1737 — conversation activity ordering and filtering
• polish(desktop): track high-impact native-experience improvements #2084 — high-impact Desktop experience improvements
• roadmap(windows): make Windows a supported platform #2142 — Windows support roadmap
• RFC: Radically slim the Session Task Ledger #2290 — Task Ledger simplification