How nala works

nala's core design decision is that the work does not live in a window. Everything that matters (terminals, tasks, agents, messages, approvals, artifacts) lives in a detached daemon process. The desktop app, the nala TUI, and the CLI are just clients of that daemon. This one decision explains most of what nala can do that a terminal tab cannot.

The daemon

The daemon is a background process that owns every PTY (terminal session) and every piece of orchestration state. Because it outlives any window:

• Closing the app does not kill your terminals. Rebooting does not either.
• Multiple clients can attach to the same session at once.
• Agents keep working while you are not looking at them.

Manage it directly when you need to:

nala daemon status
nala daemon logs
nala daemon restart
nala daemon stop      # refuses if work is active

The single durable writer

For orchestration state, the daemon is the sole writer. Tasks, agents, messages, approvals, and artifacts all flow through one store, which is what makes A2A messaging durable (messages survive restarts and land exactly once) and approvals meaningful (there is exactly one queue to approve from).

The entity model:

Workspace (1) ──< Task (N) ──< Agent (N)
                   │              │
                   │              ├──< Session (1)
                   │              │     queued → starting → running → waiting → stopped/failed
                   │              └──< Delegation (N)
                   │                    parent → child, depth-limited, cycle-detected
                   └──< Artifact (N)
                          │
                          └──< Artifact (N)   parent dependency, acyclic

Tasks come in four modes: Regular (standard tracked work), Plan (an idea captured without running shell commands), Epic (large multi-task work), and Review (code review with findings to resolve).

The orchestration services

Inside the daemon, each concern is a service: tasks, providers, messages, agents, artifacts, spawn proposals, approvals, idea capture, comments, claims, search, snapshots, journals, verification, scheduling, worktrees, reconciliation (detecting ambiguous writes after timeouts or crashes), and the skills manager. You will meet them through the UI and CLI rather than directly, but their names show up in traces and nala doctor output.

Why local-first matters here

Because the daemon is on your machine, everything described above works offline, with zero accounts, and with your code never leaving the machine unless you ask a remote model to see it. The optional NALA Managed services (cloud execution, managed inference) are additive credits-funded extras, framed as future services, never a requirement. The local product is the permanent foundation.

Where things live on disk

The internal data identity stays wmux (the upstream open-source project nala descends from) so data paths, pipes, and the single-instance lock remain compatible.

Next steps

• Durable sessions — what survival actually means.
• The nala agent — the resident agent and how routing works.
• A2A messaging — the protocol on top of the store.