Repository navigation
roadmap: durable agent platform #544
Description
Context
Maka is moving beyond a single-turn chat/runtime product. The next major product and architecture work should be planned around a durable, recoverable, observable, and orchestratable agent platform.
This issue is the roadmap/RFC anchor for that work. The goal is to split the roadmap into tracks that can be prioritized, validated, and implemented as smaller issues and PRs.
Roadmap Tracks
1. Durable Execution Foundation
- Memory: long-lived user, project, and task memory, not just context summarization. Memory needs source attribution, freshness, confidence, scope, and expiry semantics.
- Resume: agent/session/task/run recovery from interruption. Resume must know which state is trusted, which tool results or files need revalidation, and where execution can safely continue.
- Agent filesystem: explicit persistent workspace semantics for drafts, artifacts, caches, checkouts, long-term notes, and disposable temporary files.
- Observability: runtime behavior must be explainable through live event traces, LLM/tool/cost/compaction/retry/task state, failure attribution, replay, and searchable inspection views.
2. Task And Orchestration Layer
- Task: agent work should converge around explicit units that can be declared, claimed, progressed, reviewed, and closed.
- Dynamic workflow: long-running work needs dynamic graph expansion, dependency management, retry, pruning, parallelization, and review gates, not only static DAG execution.
- Cronjob / scheduled agent work: time-triggered and recurring work should support periodic checks, reminders, delayed follow-ups, status inspection, and automatic next steps.
- Multi-agent collaboration: support collaboration across agents and machines, including role assignment, handoff, conflict control, result aggregation, and review ownership.
3. Benchmark-Driven Self-Iteration
- Terminal-Bench loop: run Terminal-Bench as a recurring leaderboard and evolution loop, measuring capability, cost, runtime, and reliability, then feeding failures back into targeted Maka improvements.
- AHE evidence bridge: export task-run traces, official verifier/scorer results, failure digests, target snapshots, and change manifests through the AHE protocol so an outer evolution loop can propose bounded, evidence-backed patches.
- Leaderboard promotion gates: compare baseline and candidate runs through official cells such as
fail_to_pass,pass_to_fail, infra/excluded buckets, token/cost/runtime deltas, and rollback criteria before promoting a change. - Self-evolution backlog: cluster Terminal-Bench failures into root causes, map them to editable components such as prompt, heavy-task policy, tool contracts, context management, permission policy, and headless evaluation, then generate focused follow-up issues/PRs.
Suggested Priority
- Observability + Resume: first make it clear what happened, whether the run is recoverable, and where execution should resume. Without this, higher-level workflow becomes opaque and fragile.
- Agent filesystem + Memory: unify long-lived state and persistent file assets. Define which data enters model context and which remains a retrievable/recoverable asset.
- Task model hardening: tighten task status, claim/review/done flow, artifact linkage, failure reason, owner, and assignee semantics.
- Dynamic workflow: build dynamic decomposition, dependencies, parallel work, retries, and human review gates on top of observable/recoverable execution.
- Terminal-Bench + AHE self-iteration: once official traces/results are reliable, make Terminal-Bench a recurring loop that feeds AHE evidence export, candidate patches, regression checks, and leaderboard promotion.
- Cronjob: fold scheduled work into the same task/run/trace/memory model instead of creating an unobservable timer subsystem.
- Multi-agent collaboration: extend task/workflow into a multi-agent execution network, prioritizing handoff, permissions, context minimization, and result adjudication.
Design Constraints
- This roadmap should not become a big-bang rewrite. Each track should be split into independently mergeable issues/PRs.
- Every track needs observable events and resume semantics; UI-only or happy-path-only implementations are not enough.
- Memory, filesystem, resume, and task should not invent separate state models. They should share clear boundaries around run/session/task/artifact/fact.
- Dynamic workflow and multi-agent collaboration must start from failure, cancellation, timeout, and partial-completion semantics.
- Cronjob should produce logs, tasks, results, failure attribution, and next-schedule state, not just a local timer.
- Benchmark-driven self-iteration must use official benchmark authority for pass/fail claims, keep self-check and infra buckets separate, and preserve rollback criteria so leaderboard optimization does not become benchmark overfitting.
- AHE should propose staged, source-backed changes only against declared editable components; Maka remains the source of truth for runtime events, tool execution, permissions, artifacts, and official evaluation feedback.
Initial Issue Split
- Define durable run/session/task trace model for roadmap features.
- Add resume contract for interrupted agent sessions/runs.
- Define agent filesystem layout and lifecycle policy.
- Define memory scopes and write/read/update policy.
- Harden task lifecycle and review semantics.
- Add dynamic workflow RFC with dependency/retry/review primitives.
- Add Terminal-Bench + AHE self-iteration RFC covering evidence export, failure clustering, candidate patch manifests, baseline/candidate comparison, and leaderboard promotion gates.
- Add cronjob/scheduled-run RFC built on task/run trace.
- Add multi-agent collaboration RFC built on task/workflow handoff.
Related
- feat(runtime): RFC - observable long-running shell commands #486: observable long-running shell commands
- feat(runtime): add Codex-style permission profiles and sandbox enforcement #509: bash sandbox and safe write-back flow
- feat: selective config import/export (backup bundle) — RFC on credential handling #449: selective config import/export and credential handling
- feat(skills): Improve maka skill management architecture #424: skill management architecture
- feat(harness): add Maka-native AHE-style self-iteration loop #345: Maka-native self-iteration loop
- Add active-loop full compaction for long benchmark runs #327: active-loop full compaction for long benchmark runs
- roadmap: productize Deep Research workflow #566: productize Deep Research workflow
docs/ahe-target-protocol.md: AHE target protocol and candidate iteration contractdocs/ahe-evidence-export.md: AHE evidence export for Maka task-run traces and official results
中文版本
背景
Maka 现在已经不是单轮 chat/runtime 的问题了，后续关键方向应该围绕“长期可恢复、可观察、可编排的 agent 系统”来规划。这个 issue 先作为 roadmap / RFC 入口，用来把后续功能拆成可排序、可验证、可并行推进的主线。
Roadmap 主线
1. 可持续执行底座
- Memory：长期用户/项目/任务记忆，不只是上下文摘要；需要有来源、更新时间、置信度、作用域和失效策略。
- Resume：agent/session/task/run 能从中断点恢复；恢复时要知道哪些状态可信、哪些工具结果/文件/计划需要重新验证。
- Agent filesystem：给 agent 一个明确的持久工作区语义，包括草稿、产物、缓存、外部检出、长期笔记、可清理临时文件。
- Observability：运行态必须可解释，包括 live event trace、LLM/tool/cost/compaction/retry/task 状态、失败归因、可回放/可检索视图。
2. 任务与编排层
- Task：把 agent 工作收敛到可声明、可领取、可推进、可审查、可关闭的最小交付单元。
- Dynamic workflow：任务运行中可以动态拆图、补图、重试、裁剪、并行化，而不是只支持静态 DAG。
- Cronjob / scheduled agent work：支持时间触发、周期巡检、延期提醒、状态检查和自动 follow-up。
- Multi-agent collaboration：支持跨 agent / 跨机器协作，包括角色分工、上下文交接、冲突控制、结果汇总和审查门禁。
3. Benchmark 驱动的自迭代
- Terminal-Bench loop：把 Terminal-Bench 作为周期性打榜和进化 loop，同时观察能力、成本、耗时和可靠性，并把失败反馈成 Maka 的定向改进。
- AHE evidence bridge：通过 AHE 协议导出 task-run trace、official verifier/scorer 结果、失败摘要、target snapshot 和 change manifest，让外层进化循环能基于证据提出有边界的 patch。
- 打榜晋级门禁：candidate 变更需要和 baseline 做 official cell 对比，包括
fail_to_pass、pass_to_fail、infra/excluded bucket、token/cost/runtime delta 和 rollback criteria，再决定是否晋级。 - 自进化 backlog：把 Terminal-Bench 失败聚类成 root cause，映射到 prompt、heavy-task policy、tool contract、context management、permission policy、headless evaluation 等可编辑组件，再拆成聚焦的 issue/PR。
建议优先级
- Observability + Resume：先把“发生了什么、现在能不能恢复、恢复后从哪里继续”打牢。否则上层 workflow 会变成不可解释的黑盒。
- Agent filesystem + Memory：把长期状态和长期文件资产统一建模，明确哪些内容进入模型上下文、哪些只作为可检索/可恢复资产。
- Task model hardening：把任务状态、claim/review/done、artifact/linkage、失败原因、owner/assignee 语义收紧。
- Dynamic workflow：在可观察/可恢复的基础上支持动态拆解、依赖、并行、重试和人类 review gates。
- Terminal-Bench + AHE 自迭代：当 official trace/result 足够可靠后，把 Terminal-Bench 变成周期性 loop，接到 AHE evidence export、candidate patch、回归检查和打榜晋级流程。
- Cronjob：把 scheduled work 纳入同一套 task/run/trace/memory 语义，而不是另起一套不可观察的定时系统。
- Multi-agent collaboration：最后把 task/workflow 扩展为多 agent 网络，优先解决交接、权限、上下文最小化和结果裁决。
关键设计约束
- Roadmap 不是“大而全重写”，应该拆成一组可以独立合并的小 PR / 子 issue。
- 每条主线都必须有可观测事件和恢复语义，不能只做 UI 或只做 happy-path API。
- Memory、filesystem、resume、task 不能各自发明状态模型；需要共享 run/session/task/artifact/fact 的边界。
- Dynamic workflow 和 multi-agent 协作必须从失败/取消/超时/部分完成开始设计，否则真实长期任务会不可维护。
- Cronjob 不应该只是本地定时器；它应该产生日志、任务、结果、失败归因和下一次调度状态。
- Benchmark 驱动的自迭代必须用 official benchmark authority 来声明 pass/fail，把 self-check 和 infra bucket 分开，并保留 rollback criteria，避免打榜优化变成 benchmark overfitting。
- AHE 只能对声明过的 source-backed editable component 提出 staged change；Maka 继续作为 runtime event、tool execution、permission、artifact 和 official evaluation feedback 的事实来源。
初始拆分建议
- Define durable run/session/task trace model for roadmap features.
- Add resume contract for interrupted agent sessions/runs.
- Define agent filesystem layout and lifecycle policy.
- Define memory scopes and write/read/update policy.
- Harden task lifecycle and review semantics.
- Add dynamic workflow RFC with dependency/retry/review primitives.
- Add Terminal-Bench + AHE self-iteration RFC covering evidence export, failure clustering, candidate patch manifests, baseline/candidate comparison, and leaderboard promotion gates.
- Add cronjob/scheduled-run RFC built on task/run trace.
- Add multi-agent collaboration RFC built on task/workflow handoff.
Related
- feat(runtime): RFC - observable long-running shell commands #486: observable long-running shell commands
- feat(runtime): add Codex-style permission profiles and sandbox enforcement #509: bash sandbox and safe write-back flow
- feat: selective config import/export (backup bundle) — RFC on credential handling #449: selective config import/export and credential handling
- feat(skills): Improve maka skill management architecture #424: skill management architecture
- feat(harness): add Maka-native AHE-style self-iteration loop #345: Maka-native self-iteration loop
- Add active-loop full compaction for long benchmark runs #327: active-loop full compaction for long benchmark runs
- roadmap: productize Deep Research workflow #566: productize Deep Research workflow
docs/ahe-target-protocol.md: AHE target protocol and candidate iteration contractdocs/ahe-evidence-export.md: AHE evidence export for Maka task-run traces and official results
Activity
hqhq1025 commentedon Jul 5, 2026
Track 2 — Cronjob / scheduled agent work: session-only 层已在 #545 实现。
覆盖范围：CronCreate/CronDelete/CronList 三个 tool、5-field cron 表达式、recurring + one-shot、jitter、idle-gate、auto-expire 7d、race condition 防护、28 个单测 + desktop/headless 端到端验证。
后续待做（对应 roadmap 里更深的要求）：
GabrielDrapor commentedon Jul 5, 2026
Thought of two things, but not sure whether we should include them. Just sharing for everyone to discuss:
* Privacy protection (currently intentional but incomplete)
Today's privacy mechanisms are real but fragmented: credential storage (some OAuth tokens go through Electron safeStorage encryption), two independent redaction layers (@maka/core / @maka/ui redactSecrets), an incognito-mode contract (incognito.ts), and one codified OAuth-email leak-safety guard (ChatModelChoice.connectionName in chat-model-helpers.ts). None of these are wrong, but they're scattered and inconsistently enforced.
* Computer use
Computer use would let Maka act on anything on the user's screen, not just web pages — native macOS apps, dialogs, file pickers, terminal windows, and any workflow that spans multiple applications. (there's already a locked threat-model contract for this in the repo (apps/desktop/tests/smoke.md Path 18, PR-UI-CU-0) — the security design is done, it's just waiting on an implementation PR (PR-UI-CU-1/PR-RUNTIME-CU) to satisfy the gates.)
M4n5ter commentedon Jul 5, 2026
Using cua-driver should cover most of the functionality.
somewan820 commentedon Jul 6, 2026
I opened a focused follow-up for the Task lifecycle hardening part of this roadmap:
#559
The scope is intentionally RFC/contract-first rather than a large implementation PR. It focuses on:
defining a minimal, durable Task record
specifying allowed status transitions
requiring evidence for blocked and completed states
linking tasks to session/run/tool/artifact references
defining runtime event projection into Task state
defining conservative resume behavior
It intentionally leaves workflow orchestration, cron scheduling, subagent dispatch, multi-agent execution, and UI-only checklists out of scope for this first slice.
bug-superman commentedon Jul 6, 2026
I’d like to pick up a small Memory subtask from this roadmap.
Proposed scope:
decayTtlMsin the local memory metadata, but expired memories do not seem to have a clear prompt-injection policy yet.I’m also going to study EverOS / other agent memory designs first and keep the first PR small.
Does this direction fit the roadmap?
Mingqwqqaq commentedon Jul 6, 2026
I’d like to claim issue #509 and work on the first PR.
My understanding is that the core problem is not to keep strengthening Bash regex classification, but to put Bash and file-tool side effects behind a replaceable workspace execution boundary first. That would create the foundation for the later desktop worktree sandbox and diff-based write-back flow.
For the first PR, I plan to focus on the runtime layer rather than implementing the full desktop UI flow:
WorkspaceExecutor/WorkspaceExecutorFactsabstraction inpackages/runtime.LocalWorkspaceExecutorcompatibility implementation so the current default behavior remains unchanged.buildBuiltinTools({ executor })accept an injected executor.Bash / Read / Write / Edit / Glob / Grepthrough the executor.This PR would not try to implement Docker/remote sandboxing, the desktop diff-review UI, or broad permission-policy changes yet. Those can build on top of this abstraction in follow-up PRs:
WorktreeSandboxExecutor, sandbox diff generation, apply/discard write-back, and sandbox-aware permission policy.If this scope sounds right, I’ll start with this first PR for #509.
feat(runtime): unified Automation tool — Codex-style heartbeat + cron…
Nyvo-io commentedon Jul 16, 2026
I would like to claim the first backend-only mesh-collaboration slice for expert teams.
I checked the current boundaries before proposing this: #971 already provides lead-to-worker dispatch, parallel fan-out, and bounded fan-in, while #956 provides
task_idbinding, child ownership/outcomes, and the parent completion review gate. I will not duplicate either PR.The proposed follow-up is the capability still called out as deferred in
docs/expert-team-runtime.md:The design borrows WorkBuddy's
SendMessage+ shared task-board semantics, Codex's isolation and human-review boundary, and Grok's auditable parallel-worker model, adapted to Maka's foreground child-run architecture and permission system.If this scope matches the intended roadmap, I would like to own it and send the implementation PR. Please let me know if there is an in-flight effort I missed or if you prefer this split into mailbox and self-claim PRs.
github-actions commentedon Sep 2, 2026
This issue has had no human activity for 30 days and has been marked stale. It will be closed in 30 days unless someone comments.
If the issue is still current, please confirm it against the latest
mainand add any information that would help move it forward. Assigned issues and issues labelledpinnedare exempt from this policy.