Task Manager

A chat window only works while you are sitting in front of it. You type, it answers, you type again. Walk away and the work stops.

That is a real ceiling on what an AI tool can do for you, and it has nothing to do with how good the model is. The Task Manager is how Semantix removes it: work you describe once, that runs on a schedule, and is finished when you look.

Opening it#

The Task Manager button in the menu bar — the lightning bolt, second of the three workspace icons — opens it as a tab. Down the left, a rail: New task, then All runs under Overview, then your Tasks, each wearing its kind's glyph and a dot in the colour of its last run's outcome. The rail's foot reads tasksd v0.1.0 · 3 tasks while the daemon answers.

What it needs from you first#

An account. Tasks and their run history live on the Semantix server, against your account, so they follow you between machines and so a run's story has a durable home before the run exists. Signed out, the form refuses with Sign in to Semantix — task documents live on the server, and the history reads Run history unavailable — Signed out — run history lives in your account.

A connection. A task fires only while the server can be reached. Offline, nothing fires and the miss is recorded — see Running while Semantix is closed.

For an agent task, one of your API-key models. The daemon runs the agent through the server while you're away, so it needs a model Semantix can call itself — a connected provider's, or a custom endpoint. Claude Code and the other installed coding agents are for conversations, not for tasks.

What a task is#

A task is three answers, and the new-task form asks them in that order.

When it fires. A schedule — every hour, every weekday at 6am, the first of the month — or something that happens in the editor: a file saved, a reindex finished, an agent run ending.

What it runs. A shell command, an agent with a prompt, or a saved agentic flow.

Where it belongs. One of your projects, or nothing at all — a global task that belongs to no project and works in its own directory.

That is the whole model. Everything else on these pages is detail underneath those three.

A worked example#

You want your test suite run every morning before you start, and you want to know what broke without opening anything.

You create a task scoped to the project, set the schedule to weekdays at 07:00, choose Shell command, and give it npm test. That is the whole setup.

At 07:00 it runs. The tail of what the command printed, the exit code, how long it took — all kept in that task's history. When you open the Task Manager you read what happened instead of running it yourself and waiting.

Swap the shell command for an Agent and the same slot holds a prompt instead: "read last night's failures and tell me which ones are the same bug." Same trigger, same history, different runner.

What happens after it runs#

Every run is recorded — outcome, timing, why it fired, and the tail of what it printed. For agent and flow tasks there is the full transcript too: which tools it called and what it did with them.

Work that happens while you are away is exactly the work you have the least reason to trust, so it is the work that has to be the most legible. See Run history.

Running while Semantix is closed#

Today: not yet. The daemons that keep the schedules and fire the tasks are started by the Studio and stop when you close its window, so a task set for 4am runs at 4am only if the Studio is open at 4am. Running them as a service of their own — so the work goes on after you close the window and after you log out — is on the way; the daemons already adopt such a service if one is running, so the day it ships nothing about your tasks changes.

→ Running while Semantix is closed has the whole picture, and the three things that stop a task from firing.

The rest of this section#

• Triggers — when a task fires: on a schedule, on an editor event, or by hand.
• What it runs — shell commands, agents and saved flows, and what an unattended agent is allowed to do.
• Run history — outcomes, causes and transcripts.
• Running while Semantix is closed — the daemons, and the three things that stop a task firing.

Where it is now#