What a task runs · Semantix

A trigger decides when. This is the what.

The new-task form's What runs control offers three kinds, and they are genuinely different tools rather than three labels on the same thing. Pick by how much judgement the work needs.

Shell command#

The simplest, and often the right answer.

The command runs through sh -c, so pipes, redirects and $(…) all work exactly as they do in your terminal. npm test, a backup script, a curl to something that needs poking hourly.

No model is involved, nothing is sent anywhere, and it costs nothing but the time it runs. If the work has a deterministic answer, this is the kind to use — an agent asked to run your test suite is a slower, more expensive npm test.

Agent#

A prompt instead of a command: "read last night's failures and tell me which ones are the same bug."

Model is one of your API-key models — a connected provider's, or a custom endpoint — from the same picker the chat uses, narrowed to what the daemon can call through the server while you're away. The picker fills itself with the first model it offers, so a task always has one. Prompt is what the agent should do each run.

Memory#

An agent task starts blank every run unless you give it a memory. Memory has three answers:

None — the bare run. Nothing is remembered from one fire to the next.

New, with this task — a memory agent of its own, minted the moment you save, named after the task. Every run wears it: who the agent is and its standing orders go ahead of the prompt, whatever it already knows that bears on the prompt is handed to it, and when the run ends what it did is written down. The next fire knows what the last one found. It shows under Your Agents in its own Task agents group, and deleting the task offers to forget it.

An existing agent — one you already own, from any project: an agent you chat with, or one another task made. The task wears that memory and adds to it, so a chat agent can be briefed by what its task did overnight.

Note

A memory rides the server, so a task with one needs an API model — the Claude CLI never reaches the server and refuses to run such a task rather than run it blank. The memory is built on the task's own model: the run's transcript is distilled by the model that produced it.

The run's history shows what the memory came to — memory: nightly · 2 carved · 1 updated under the answer — or why the write failed. A failed write never fails the run.

What an unattended agent is allowed to do#

This is the part to read before you schedule one, because a task fires when you are not there and the permission gate has nobody to ask. So instead of a gate there is a ladder — Permissions, three rungs — and the rung decides which tools the agent is even given:

Safe — eyes only. The agent can read files, list folders, search the code and run your type-checker. Nothing that writes, nothing that runs. A task that needs to change something will fail honestly instead of hanging on an approval that is never coming.

Accept edits — the default. Eyes plus hands: it can also create and edit files, make folders, move and copy. Shell commands and deletes are still withheld.

Full autonomy — everything, including running commands and deleting.

Important

These rungs exist because an unattended run cannot ask you anything. The interactive permission gate is a real protection, and choosing Full autonomy for a scheduled task is choosing to switch it off while you are not watching. That is sometimes exactly right — a task in a scratch directory, or work you would rubber-stamp anyway. It should be a decision, not a default you clicked past.

Start a new agent task on Safe and fire it by hand. You will find out what it actually tries to do before you grant it anything.

Note

An agent task with no Working directory has no tools at all — the prompt is answered in one call, with nothing to read or write. The form pre-fills the open project's path the moment you pick Agent, so this only happens if you clear it.

Agentic Flow#

A saved flow — several agents wired together on a canvas — run end to end, in the daemon, on the task's schedule.

You pick the flow, and optionally supply Flow input: text handed to the flow's trigger on every run. Flows whose agents use tools show them in the picker — uses read_file, run_command — and for those the form also asks for a working directory and a permission rung, and refuses to save until the rung covers every tool the flow declares: run_command won't be allowed at this level — raise to "Full autonomy". A flow the store can't read is listed under Not listed: with the reason.

Note

A flow is referenced, not copied. The task stores which flow to run, so editing the flow changes what the next fire does. That is usually what you want — fix the flow once, every task using it improves — but it does mean a task's behaviour can change without the task being touched.

Settings every task shares#

Name — letters, digits, dots, dashes and underscores. It's the task's id, and it can't be changed after creation; to rename, delete and recreate.

Scope — one of your projects, or Global. A new task defaults to the project you have open. A global task belongs to no project and still runs in its own directory. A project task has one more choice: Only run while this project is open in the studio. Left unchecked — the default — the task fires whenever its trigger fires, even with another project open. Checked, the project must be open for it to run at all, and even Fire now refuses while it isn't.

Working directory — where the task runs. Pre-filled with the project's path for agent and flow tasks; a shell task can run anywhere.

Timeout (seconds) — how long before the run is cut off. 600 by default.

Data folder — where the task saves the files it produces. Each run gets its own subfolder; <task>/<run>/ is appended automatically. Left empty, it's a tasks/ folder beside the project's index.

If it's already running — what happens when a run is still going and the next one is due. Skip the new run (the default) lets the running one finish and passes on this fire. Run both starts the second anyway. Skip is the safer choice for anything that writes.

Environment variables — KEY=value, one per line, for that task's runs.

Note

Skip exists for a specific failure: a task that fires every minute and takes ninety seconds will otherwise pile runs on top of each other until something gives. It is also the blunt guard against a task that triggers itself — an agent that runs on file saved and then saves files.

A task's page#

Pick a task in the rail and its page shows the name, one line on what fires it — cron 0 7 * * 1-5, event file:save, or fire-by-hand only — and, on the left, the task itself: Edit, Delete (Its triggers stop firing immediately. Past runs stay in the history.) and Fire now; an Enabled switch (Off, nothing fires it — not its triggers, not Fire now. The document and its history stay.); its Kind and Scope; and the Definition as the daemon holds it. On the right, its runs, newest first.