Tasks and subthreads

Choose how a chat works, let it hand work to Specialists or to subthreads you can open, and run recipes and schedules from the CLI.

Guide · Desktop · Tools and integrations · Interaction contract

Every message runs under a mode (how the turn behaves) and a Focus (what kind of work to emphasize). The chat’s agent can load a Specialist’s method into the conversation, hand part of the work to a hidden Task, or start a visible subthread. Definitions is the authority for these terms.

Choose a mode and Focus

Open the mode pill under the composer; it reads, for example, Agent Auto. Choices apply to your next message.

Mode	Use it to
Agent	Work with tools and Specialists under your permissions
Ask	Read, explain and explore without changing the project
Plan	Make a reviewable plan before implementation; finish with Accept plan or Accept & Build. Plan can ask you questions before it drafts, and your answers are kept with the plan, so a restart resumes from them (/plan answer in the CLI)
Debug	Reproduce a failure and verify a fix in an isolated worktree; mark Reproduced, Fixed or Not fixed, then Apply verified patch
Goal	Keep working toward a stopping condition, with Pause, Resume and Edit objective
Decisions	Shown once a decision model is chosen — see Decision models

Focus — Auto, Code, Creative or Work — steers which expertise is chosen. Neither mode nor Focus grants tools or file access; permissions do.

Specialists and Tasks

Specialists are shared experts; 28 are bundled, including General. The agent loads a Specialist’s method into the current chat when it fits, and you can add one yourself from the composer’s + menu → Specialists.

For independent work whose result the chat needs, the agent starts a Task: a fresh subagent that runs as a Specialist (General when it names none) and returns its answer inside the chat’s turn. It runs on the chat’s model and options unless the agent names another Profile model and you approve it in the turn (see Which model does the work). That approval is a card in the turn: Keep using <model>, Use <connection · model> for this task or Other (any enabled Profile model). Typing an answer that starts with “always” is kept as a project memory preference, and only such a remembered preference can pick another model in a turn you did not start. Parallel Tasks that name the same model in one turn share one card. While Tasks run, the thread rail’s Specialists card shows running/total on its title line and, open, lists running Tasks before finished ones. A Task recalls its parent chat’s working memory, inherits its workspace and permission ceiling (a read-only chat cannot gain writes by delegating), and its approval requests appear in the parent chat. The parent can wait on a Task it needs or end its turn and hear from it later.

Configure delegation in Settings → General → Focus & delegation; it applies to every workspace, project and chat. Choose Save & Apply.

Control	Meaning
Default Focus	Focus for new chats
Worker delegation	Automatic (default), Ask first or Off
Read-only workers	Concurrent read-only Tasks (default 32)
Isolated writers	Concurrent writing Tasks in their own worktrees (default 8)
Running threads	Conversations and threads that can run at once (default 8)

Each connection’s own request limit still applies, so Tasks sharing one local model take turns. If a Task fails before its first model response, check the connection; it may need a fresh sign-in.

Subthreads

A subthread is an ordinary chat nested under the one that started it, for a separate piece of work you want to open, steer and review yourself. Ask for one in your own words (“do the docs in a separate thread”), or let the agent suggest one. Before it starts, a box in the turn asks New thread or Do it here, then which model it runs on. Only a turn you started can start one; turns started by another thread or an automation may only propose one. Agora and Lysis chats start no subthreads; Lysis may still delegate Tasks, and its Tasks default to Reverse Engineer.

Under the hood the agent calls ThreadStart with a brief, an optional name (used as the title), context (fresh or fork), writes, an initiation (user_asked starts now, offer asks New thread or Do it here, own_initiative shows a proposal card) and optionally model. A subthread on another model always starts fresh with only its brief. A writing subthread works in its own Git worktree and branch; merging is always your click. When it finishes, the parent gets one short notice and can read the full answer on demand; the subthread answers in plain words, not in the chat’s Persona. Rows, roll-up lines, worktrees and notices are described in Desktop → Subthreads.

Recipes and schedules

Recipes are reusable, durable task graphs that persist dependencies, signals, timers and pause state, so a restart resumes rather than repeats. Twenty-five ship with Synoec, covering implementation, diagnosis, review, release readiness, incidents, migrations, performance, accessibility, security, data analysis, design, writing and planning; synoec recipe list shows them with any you add. A recipe you define in a project or your own configuration shadows a bundled one of the same name. The desktop has no Workflows or Automations page, and the agent can no longer improvise a workflow. When a recipe is registered, the agent may start it with RunWorkflow; otherwise use parallel Tasks or the CLI.

synoec recipe list
synoec recipe dry-run <recipe>
synoec recipe run <recipe> --input '{"request":"Review the open diff"}'
synoec recipe status <workflow-id>
synoec inspect tasks

Schedules are created and managed only from the CLI. They run once, at an interval or on selected weekdays, and synoec automation service runs them while no app is open.

synoec automation definitions
synoec automation create --definition <id> --session <id> --branch <id> \
  --time-zone Europe/London --local-time 09:00 --weekdays 1,2,3,4,5
synoec automation list
synoec automation pause <id> --revision <n>
synoec automation service status

When a Task cannot finish, it reports the reason with any partial result and the turn ends there, without another attempt. An image request counts as finished only with a successful image result, and while a turn is generating or editing an image, shell, browser, web and Computer tools ask for every call, at every sandbox level.

Completion evidence

The agent decides when its work is done. The engine records a receipt for every tool effect and holds a turn open only for what it owns: a Task the turn waits on, a required protocol step such as Plan Review, or a committed task contract. It also records whether a test or check passed after the latest edit; a readback, a static check, a started background task or a check piped into another command does not count. A reply that used no tool is recorded as answered_unchecked; nothing holds the turn open for it and no surface shows it yet. The agent is told that facts about this machine, its files and processes are checkable, and to say so when it did not check. A Task that started is not a Task that finished: the agent integrates each result and reports blocks or partial results honestly. Receipts prove what happened, not that every answer is correct.

Limits

• Delegation settings are global, not per workspace.
• A durable task refuses to resume on an engine whose Profile, connection or model no longer matches the one it started with; the current default is never substituted. A task waiting to run is claimed only by the engine of the workspace it belongs to.
• A saved plan is the authority for Plan mode; a chat summary does not replace it.
• Schedules run on this computer only; there is no hosted scheduler and no desktop page for them.
• A model choice never grants a Task or subthread extra tools or authority.
• The children one chat runs at once is the sum of its connections’ request limits, from 1 to 32, and three until a limit is known.
• A run with no way to show an approval, such as synoec --print, delegates as Automatic even when delegation is set to Ask first; Off stays off.

Related

• Providers and models · Desktop · CLI
• Capability library — Skills, Specialists, commands and recipes
• Orchestration contract
• Storage and execution foundation

Decisions behind this page: 0191, 0225, 0226, 0227, 0228, 0230, 0258, 0263 — see the decisions index.