Tasks and side tasks
An objective keeps the goal of a piece of AI work apart from the conversation doing it. Side tasks let debugging and research happen without burying it.
Long AI work loses its goal. An agent starts on an objective, meets an error, debugs it, researches an API, tries an alternative — and forty messages later nobody, the model included, can say what the work was for. Tasks keep the goal somewhere the conversation cannot bury it.
Objectives
An objective says what a piece of work is ultimately for: the outcome, not the first step. Usually the agent doing the work starts one through Deliverd's MCP server at the beginning of anything substantial. You can also start one from Tasks.
Each objective keeps a short task state: where the work stands, the next action, open questions, constraints and anything blocking it. It is short on purpose. It is what an agent reads when it resumes — after a restart, a new session, or a different model — instead of the whole history.
Side tasks
A side task is a problem branched out of the main task: an investigation, research, a debugging session, or a decision to explore. It has its own goal and status, and it starts with a snapshot of its parent — the objective, where things stand, the decisions already made and the constraints — rather than a copy of the conversation. You can see and edit that snapshot when you create one.
Agents are told to suggest moving work into a side task when troubleshooting has taken several turns or a separate problem has appeared, and to ask you first. Side tasks can nest, up to three levels below the objective.
| Status | Meaning |
|---|---|
| Open | Created, not started. |
| In progress | Being worked on. |
| Blocked | Something is in the way; the task state says what. |
| Awaiting approval | Waiting on a decision that was put to approval. |
| Complete | Finished with a result. A side task's result then waits for a choice. |
| Applied, Kept as reference or Discarded | What was done with a finished side task's result. |
| Cancelled | Called off rather than finished. |
Finishing a side task
A side task finishes with a result: a summary, findings with their evidence, decisions it proposes, recommendations, questions still open, the impact on the main task and a suggested next action. Then choose what happens to it:
- Apply to main task
- Its decisions are added to the main task, a summary is recorded, its open questions are added, the question it was opened to answer comes off the list, and its suggested next action becomes the main task's. You return to the main task with a line that restates the objective.
- Keep as reference
- The result stays on the side task; the main task's state is unchanged.
- Discard
- Recorded as not used.
Reopen a finished side task if there turns out to be more to do. What it found the first time is kept under Earlier rounds.
Findings and decisions
Work produces findings: hypotheses, tests and their outcome, evidence, conclusions, recommendations, risks and questions. They are written to be checked by a reader. They are never the model's private reasoning, which is not shown or stored.
A decision recorded by an agent is a suggestion. It becomes confirmed only when a person confirms it here — applying a side task's result confirms the decisions in it, in your name — or when it is put to an approval and approved. Rejected decisions stay on the record, marked rejected. If the objective belongs to a flow, the approval appears on that flow's timeline.
Who can see and change tasks
- Everyone in the organisation can read its tasks, unless an objective was started in a workspace: then only that workspace's members and the organisation's administrators can. A side task is always exactly as visible as its objective.
- Owners, administrators, workspace administrators and publishers can create and change tasks. Viewers read them.
- Only whoever started an objective, or an administrator, can delete it — and deleting removes everything under it. The audit trail keeps the record.