Task Manager
Work that runs on a schedule instead of in a chat window — what a task is, and what fires it.
A chat window only works while you are sitting in front of it. You type, it answers, you type again. Close the laptop 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 get back.
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 runs. 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.
Note
The two kinds of trigger do not have the same reach, and the difference is worth knowing before you pick one. A schedule is kept by the background daemon, so it fires whether or not Semantix is open. An editor event only exists while the editor is running — so event-triggered tasks fire when the app is up, and not otherwise.
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 output — everything the command printed, the exit code, how long it took — is kept in that task's history. When you open Semantix 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 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#
Yes — but it depends on one thing, and it is worth knowing before you rely on it.
Tasks are fired by a small background daemon, not by the app window. If that daemon is installed as a service on your machine it keeps running after you quit and after you log out, and your 4am task fires at 4am. If it is not, the app runs the daemon itself and stops it when you quit, so tasks fire only while Semantix is open.
Important
Installing the daemon as a service is a manual step today, and it is what separates "runs while I sleep" from "runs while the app is open". If unattended work is why you are here, do that step — Running while Semantix is closed is the whole answer.
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 daemon, and the three things that stop a task firing.
Where it is now#
Note
The Task Manager is early, like the rest of Semantix Studio, and is built and tested on Linux. Schedules, editor events, shell tasks, agent tasks and agentic flows all work today. An event-triggered task runs as you configured it — it does not yet receive details of the event that fired it. Where something on these pages is marked coming, it means exactly that.