A response is not a task state
A chat interface optimizes for the next answer. That is appropriate for questions with short lives. The answer can be read, revised, or discarded without affecting anything else.
Long work behaves differently. Its goal, constraints, earlier decisions, failed attempts, source material, and unresolved questions all remain relevant. If those facts live only in a transcript, the task becomes dependent on the model or the person remembering which parts still matter.
The unit of work must survive the session
LibreTask treats a task as a durable thread. The thread has a contract, an execution history, checkpoints, and a final delivery. Closing the application does not erase its state. Returning later does not require reconstructing the work from the last few messages.
This changes the kind of work that can be delegated. A task can wait for a person, switch to another approved capability after a failure, or resume after a restart while preserving the same accepted outcome.
Human judgment belongs inside the work
Long tasks contain moments where more computation is not the right answer. A source direction may need confirmation. A budget may need adjustment. A high-impact external action may need authority.
A durable task makes those moments explicit. It pauses with the relevant context, records the resulting decision, and continues from that point. The human is not outside the workflow giving occasional instructions; the human is part of the system’s control layer.
The end is acceptance, not completion
A final message can claim that work is complete. It cannot show that the acceptance criteria were met, which sources supported the conclusion, what failed, or what remains uncertain.
LibreTask therefore treats the delivery package as part of the work. The result, checks, evidence, execution history, and open questions arrive together. The task becomes complete only when a person can review that package and accept it.