Project Tasks Belong in APX, Not APC
A project task is operational state.
That is why it belongs in APX, not APC.
APC is the portable context layer. It keeps the repository contract in files like AGENTS.md and .apc/. APX is the daily-use runtime and tooling layer. It keeps the moving parts that should stay local: sessions, messages, conversations, caches, and, importantly, tasks.
That split matters because tasks feel deceptively simple. People often try to store everything in the same place: project rules, agent definitions, memory notes, TODOs, and runtime traces. The result is a blurred system where durable context and daily operations pollute each other.
APX draws a cleaner line.
In the implementation, project tasks live under:
~/.apx/projects/<project-id>/tasks/YYYY-MM.jsonl
That location says a lot.
The task log is per project, machine-local, append-only, and runtime-owned. APC does not need to version it inside the repository. The repository should define what the project is. APX should track what is happening around the project right now.
The current task store is also deliberately small. Each task is created as an event, then projected into current state. The lifecycle stays simple:
createupdatedonedropreopen
Open tasks can also carry a workflow status such as pending, running, in_review, or blocked.
That design is practical for agent work.
If you ask APX to capture a follow-up, the CLI can write it without inventing a bigger project-management system:
apx task add "Review auth edge case" --tag bug --agent reviewer --due 2026-07-15
apx task list --state open
apx task done t_ab12cd
Those commands are useful precisely because they stay local to APX runtime state. They do not rewrite your repository contract. They do not pretend a temporary follow-up note is the same kind of artifact as AGENTS.md, .apc/project.json, or .apc/mcps.json.
There is also a structural reason this belongs in APX.
Tasks are tied to runtime activity. APX exposes per-project task APIs, a global task view across registered projects, task summaries for status screens, and task-aware tools for the super-agent. That is operational plumbing, not portable specification. APC-compatible tools may understand agent definitions or project metadata, but they should not be forced to inherit one runtime's transient TODO stream.
This is the same boundary APC and APX keep elsewhere.
- APC stores durable, reviewable project intent.
- APX stores live execution state.
A task like "re-run migration after vendor update" is real work, but it is not project contract. It may matter only on one machine, for one agent, during one week. Storing it in APX keeps the repo clean while still making the work visible and queryable.
The alternative looks worse in both directions.
If tasks go into APC, the repository starts collecting operational noise that should not travel forever. If tasks stay only inside ad hoc chat threads, they become hidden, vendor-tied, and hard to inspect later.
APX avoids both problems by giving tasks a first-class local store.
That also makes the APC/APX relationship easier to explain:
APC tells a runtime what this project means.
APX tracks what this project is doing.
For daily agent work, that is the right split. Keep the shared contract in APC. Keep the changing task flow in APX.
Top comments (0)