Tasks, plans, and runs
The durable work model: what a task is, what a plan revision is, and why state matters more than activity.
Tasks are the durable record of work. They outlive panes, windows, and reboots, because the daemon owns them rather than the UI.
The vocabulary
| Term | What it is |
|---|---|
| Task | A durable unit of work with an identity and a state |
| Plan | A proposed sequence of steps toward a goal |
| Plan revision | A numbered version of that plan; plans change, and the history is kept |
| Run | One execution attempt of a plan |
| Artifact | A durable Markdown output attached to the work |
| Delegation | An edge assigning a task to another agent |
A task is not a chat message and not a pane. You can close every window and the task remains.
Why state beats activity
IMPORTANT
A running process is not evidence of progress. An agent can hold a session open, print output, and advance nothing. The task state is the fact; the terminal is a view.
This is the single most useful habit when supervising agents: check the task, not the scrollback.
nala task list
Verification gates
Work can carry a verification requirement, so a task is not complete merely because an agent said so. Where a gate exists, the evidence has to exist too.
Treat agent-produced work the way you would treat a pull request from a very confident stranger: read the diff, run the tests, then decide.
Artifacts
Artifacts are Markdown documents attached to the work — a plan, a summary, a review, a decision record. They are durable, they are readable without the agent that produced them, and they survive the session.
Use them for anything you will want after the terminal is gone.
Plans change
A plan revision is numbered because plans are expected to change once contact with the repository happens. Keeping revisions means you can see what was proposed, what was approved, and what actually ran — which is the difference between an audit trail and a story.