What task are you trying to do?
Position Maka as the open-source CC (Claude Code) Workflow. To credibly claim that tag, Maka needs several foundational agent primitives that are currently incomplete or missing: deferred tool loading, subagent runtime, task tracking, loop/automation, and goal-based execution.
This issue tracks the gap analysis and build order for those primitives. They should be treated as related but mostly orthogonal control surfaces, not one dependency chain. In particular, task tracking is not subagent dispatch: tasks are the main agent's explicit control/state ledger, while subagents are execution capacity.
What do you do today?
Subagent: A first foreground child-run foundation now exists, but the broader subagent surface still needs clear profile, isolation, write-back, and inspection contracts. ExploreAgent (explore-agent-tool.ts) remains a deterministic read-only helper, not the LLM subagent primitive.
Tool loading: Large tool schemas should not all sit in the model context every turn. Deferred tool loading exists for some surfaces, but the rule should stay explicit: deferred loading is prompt/surface economy, not a permission boundary.
Task tracking: The model needs a structured way to create, update, list, and recover tasks during long work. This should be a typed, recoverable execution ledger for the main agent, not a UI-only checklist and not a queue of work assigned to subagents.
Loop/automation: Scheduled or recurring execution is still a separate control loop. It can consume task/goal state, but it should not assume subagents are the default execution mechanism.
Goal: Goal-based execution lets an agent work toward a durable objective across turns with verifiable stopping conditions. It may use a task ledger for progress and recovery, but it should not depend on subagents.
What would a good result look like?
A set of small, composable primitives with narrow contracts. Each primitive should stand on its own, and later workflow orchestration can compose them only where the composition is actually useful.
Primitive 1 — Deferred tool loading
Large-schema tools only load their full schema when the model asks for them. A lightweight catalog stays in the system prompt, and full schemas load on demand. This cuts per-turn token waste and makes it practical to keep adding tools without prompt bloat.
Primitive 2 — Subagent runtime
A parent session can spawn a child LLM run through the existing Runtime v2 pipeline. Child runs are real AgentRuns with their own RuntimeEvents, scoped tool/profile contracts, and inspectable output. Subagents are for delegation, isolation, parallel research, web research, implementation work, or future verifier/evaluator roles. They are not the foundation for task tracking.
Primitive 3 — Task tracking
The model can create, update, query, and recover tasks within a session. Tasks should survive recovery and carry enough evidence to be useful: current status, blocked reason, completion evidence, and links to relevant observations or artifacts.
Task tracking should be evaluated as a harness/control-state variable. The design question is whether a typed task ledger improves long coding/terminal task completion, recovery, and verification compared with no ledger or a free-text checklist. It should not be justified by "a subagent can be assigned to a task" as the primary use case.
Primitive 4 — Loop / automation
The system can schedule wakeups, recurring checks, or bounded retry loops. This depends on a clear execution contract, stop conditions, visibility, and audit trail. It may reference task or goal state, but it should not silently become a subagent scheduler.
Primitive 5 — Workflow orchestration
After the primitives above have narrow contracts, revisit the PR #1 workflow direction. A lightweight in-process workflow tool can compose agents, tasks, deferred tools, and verification loops for specific use cases. Rive remains the durable upgrade path for long-running distributed workflows, not the default for every local workflow.
Primitive 6 — Goal-based execution
An agent can accept a durable objective and work across turns without per-step user approval. A goal needs an objective, allowed scope, non-goals, verification, checkpoints, and stop conditions. It can use task tracking as progress state, but goal ownership should remain explicit.
What would count as done?
- Deferred tool loading: large-schema tools only load schema on demand. System prompt token count drops measurably when those tools are not used in a turn.
- Subagent: a parent session can spawn child LLM runs through Runtime v2, with profile/isolation/write-back contracts and inspectable RuntimeEvents.
- Task tracking: the model can create/update/query tasks; tasks survive session recovery; task status is evidence-bearing and does not override live filesystem/git/test truth.
- Loop: the system can schedule a wakeup or recurring execution with visible stop conditions and audit trail.
- Workflow: a lightweight in-process workflow tool exists with low parameter count for the common case; Rive integration is simplified with smart defaults for durable workflows.
- Goal: the model can accept an objective and work toward it across turns with checkpoints and verifiable stopping conditions.
What should stay out of scope?
- Rewriting Runtime v2 core. Build on the existing RuntimeEvent / AgentRun / RuntimeRunner architecture.
- Treating task tracking as subagent dispatch.
- Treating deferred tools, prompts, or task state as permission boundaries.
- Multi-machine distributed scheduling. That stays in Rive's domain.
- MCP server integration. Separate concern.
- Heavy project-management UI before the typed task ledger proves useful.
Current working direction
Subagent work has moved into focused follow-up issues such as #49 and #52. Keep #15 as the umbrella, but do not let the umbrella imply a false dependency chain.
The next task-tracking work should start from the question: does a typed task ledger improve long coding/terminal task completion, recovery, and verification for the main agent? If yes, implement the smallest ledger that can be A/B tested:
task_createtask_updatetask_list- optional
task_get
- statuses like
pending, in_progress, blocked, completed, cancelled
- evidence fields for completed/blocked states
- persistence through the runtime/session ledger
- compact UI for current task, remaining count, and blocked reason
- feature flag for benchmark comparison
Relevant context
What task are you trying to do?
Position Maka as the open-source CC (Claude Code) Workflow. To credibly claim that tag, Maka needs several foundational agent primitives that are currently incomplete or missing: deferred tool loading, subagent runtime, task tracking, loop/automation, and goal-based execution.
This issue tracks the gap analysis and build order for those primitives. They should be treated as related but mostly orthogonal control surfaces, not one dependency chain. In particular, task tracking is not subagent dispatch: tasks are the main agent's explicit control/state ledger, while subagents are execution capacity.
What do you do today?
Subagent: A first foreground child-run foundation now exists, but the broader subagent surface still needs clear profile, isolation, write-back, and inspection contracts. ExploreAgent (
explore-agent-tool.ts) remains a deterministic read-only helper, not the LLM subagent primitive.Tool loading: Large tool schemas should not all sit in the model context every turn. Deferred tool loading exists for some surfaces, but the rule should stay explicit: deferred loading is prompt/surface economy, not a permission boundary.
Task tracking: The model needs a structured way to create, update, list, and recover tasks during long work. This should be a typed, recoverable execution ledger for the main agent, not a UI-only checklist and not a queue of work assigned to subagents.
Loop/automation: Scheduled or recurring execution is still a separate control loop. It can consume task/goal state, but it should not assume subagents are the default execution mechanism.
Goal: Goal-based execution lets an agent work toward a durable objective across turns with verifiable stopping conditions. It may use a task ledger for progress and recovery, but it should not depend on subagents.
What would a good result look like?
A set of small, composable primitives with narrow contracts. Each primitive should stand on its own, and later workflow orchestration can compose them only where the composition is actually useful.
Primitive 1 — Deferred tool loading
Large-schema tools only load their full schema when the model asks for them. A lightweight catalog stays in the system prompt, and full schemas load on demand. This cuts per-turn token waste and makes it practical to keep adding tools without prompt bloat.
Primitive 2 — Subagent runtime
A parent session can spawn a child LLM run through the existing Runtime v2 pipeline. Child runs are real
AgentRuns with their own RuntimeEvents, scoped tool/profile contracts, and inspectable output. Subagents are for delegation, isolation, parallel research, web research, implementation work, or future verifier/evaluator roles. They are not the foundation for task tracking.Primitive 3 — Task tracking
The model can create, update, query, and recover tasks within a session. Tasks should survive recovery and carry enough evidence to be useful: current status, blocked reason, completion evidence, and links to relevant observations or artifacts.
Task tracking should be evaluated as a harness/control-state variable. The design question is whether a typed task ledger improves long coding/terminal task completion, recovery, and verification compared with no ledger or a free-text checklist. It should not be justified by "a subagent can be assigned to a task" as the primary use case.
Primitive 4 — Loop / automation
The system can schedule wakeups, recurring checks, or bounded retry loops. This depends on a clear execution contract, stop conditions, visibility, and audit trail. It may reference task or goal state, but it should not silently become a subagent scheduler.
Primitive 5 — Workflow orchestration
After the primitives above have narrow contracts, revisit the PR #1 workflow direction. A lightweight in-process workflow tool can compose agents, tasks, deferred tools, and verification loops for specific use cases. Rive remains the durable upgrade path for long-running distributed workflows, not the default for every local workflow.
Primitive 6 — Goal-based execution
An agent can accept a durable objective and work across turns without per-step user approval. A goal needs an objective, allowed scope, non-goals, verification, checkpoints, and stop conditions. It can use task tracking as progress state, but goal ownership should remain explicit.
What would count as done?
What should stay out of scope?
Current working direction
Subagent work has moved into focused follow-up issues such as #49 and #52. Keep #15 as the umbrella, but do not let the umbrella imply a false dependency chain.
The next task-tracking work should start from the question: does a typed task ledger improve long coding/terminal task completion, recovery, and verification for the main agent? If yes, implement the smallest ledger that can be A/B tested:
task_createtask_updatetask_listtask_getpending,in_progress,blocked,completed,cancelledRelevant context
apps/desktop/src/main/main.ts:531-551packages/core/src/permission.tsapps/desktop/src/main/explore-agent-tool.tsapps/desktop/src/main/rive-workflow-tool.ts