Goal runners

What goal runs do

1. Accepts a high-level objective from the UI or tool layer.
2. Uses the built-in daemon agent to generate a structured plan.
3. Converts executable steps into child tasks on the daemon queue.
4. Monitors retries, failures, approvals, and completion.
5. Reflects on the final trajectory.
6. May write durable memory and generate a reusable skill.

Run lifecycle

Step-level status is tracked separately with pending, in_progress, completed, failed, and skipped.

Launch surfaces

Goal runs are launched from daemon clients, and richer Mission Control-style preflight is still evolving. What is already shipped is the durable goal object itself plus client surfaces that can expose the requested outcome, provider/model choices, role roster, and inherited defaults before or after launch.

• Goal prompt: what the run is trying to accomplish.
• Primary agent: the main provider/model/reasoning choice.
• Role assignments: which runtime roster will be used for planning and execution.
• Preset source: whether the roster came from prior snapshot state or current main-agent inheritance.

Visibility today

During a run, Goals stays the orchestration surface and Threads stays the conversational surface. In the TUI this already includes a real goal workspace with goal, files, progress, active-agent, threads, and needs-attention modes; richer desktop goal shells continue to mature around the same daemon state.

Queue integration

Each executable plan step becomes a child task. Those tasks inherit the normal daemon machinery:

• lane scheduling
• session affinity
• retry policy
• approval waiting state
• managed terminal execution
• queue visibility and control

This design keeps goal runners consistent with the rest of tamux instead of inventing a separate execution runtime.

Approvals and replanning

When a child task hits an approval gate, the task enters awaiting_approval and the goal run surfaces the same blocked state. Once the operator resolves the approval request, work resumes.

When a child task fails, the goal runner records the failure and decides whether to replan. If replanning budget remains, the daemon asks for revised remaining steps. If not, the run becomes failed.

Durable outputs

On successful completion, goal runners can produce two especially important durable outputs:

• Memory update: appended only when a stable fact, operator preference, or durable strategy hint is identified.
• Generated skill: a procedural artifact derived from a successful trajectory.

The structured run history itself stays persisted in SQLite while the editable memory and skill artifacts remain on disk.

When to use goals

• The task will take multiple steps.
• You want approvals and child-task visibility.
• You want work to survive closing a client UI.
• You want reflection, reusable skills, or durable memory from the result.

Use a normal chat turn when the task is short, disposable, or only needs reasoning rather than durable orchestration.

First goal ideas