> ## Documentation Index
> Fetch the complete documentation index at: https://docs.membrane.agency/llms.txt
> Use this file to discover all available pages before exploring further.

# Tasks

A task is one unit of work inside a [job](/docs/how-membrane-works/jobs) or routine: "prepare the June COGS report", "triage this return", or another concrete outcome that you can watch, steer, and review as a conversation. A job's operator is accountable for every task under it, and each launch opens the default Membrane agent. Routines create tasks on schedule or in response to events; you can also create one directly under a job or routine, or the agent can queue follow-up work as new tasks.

## Where tasks come from

* **Routines.** A job's schedules and triggers create tasks as their work items. An event-triggered task records which event fired it, so you can always trace a result back to its cause. Test events create tasks flagged as tests.
* **You.** Request work on the job when you want something done once. The request creates the task,
  starts it, and opens the task so you can follow it.
* **The agent.** Work often uncovers more work; the agent records it as new tasks instead of losing it.

Creating a task can either launch it immediately or park it in **To do** for deliberate queueing. A routine normally launches the task it creates, and requesting work from a job starts it immediately. Commands and internal workflows can still create a parked task deliberately; people can work, comment on, and move the status of that task themselves. Whenever a launch happens, Membrane opens the task's session with the default Membrane agent; there is no agent choice or separate assignment step.

## The statuses

```mermaid theme={null}
stateDiagram-v2
    direction LR
    [*] --> Proposed: proposed
    [*] --> ToDo: created
    Proposed --> ToDo: approved
    Proposed --> Declined: declined
    Proposed --> Expired: no answer by deadline
    Proposed --> Cancelled: withdrawn
    Declined --> ToDo: approved later
    Expired --> Proposed: reopened
    ToDo --> InProgress: start
    ToDo --> OnHold: waiting
    InProgress --> OnHold: waiting
    OnHold --> InProgress: time, prompt, or event
    OnHold --> Done: work completed
    OnHold --> Cancelled: stop requested
    InProgress --> Done: work completed
    InProgress --> Exception: exception marked
    InProgress --> Cancelled: stop requested
    Done --> InProgress: new prompt
    Exception --> InProgress: work resumed
    Cancelled --> InProgress: run again

    ToDo: To do
    InProgress: In progress
    OnHold: On hold
```

* **Proposed** — work awaiting a decision. Approval moves it into the work queue, a no marks it
  Declined, and no answer before its deadline marks it Expired. The job's operator can also withdraw
  it, which marks it Cancelled without a decision.
* **Declined** — the proposed work was turned down. A later approval can still move it into the
  queue.
* **Expired** — the proposal reached its deadline without an answer. It can be reopened with a new
  deadline.
* **To do** — recorded, not yet in motion. A deliberately parked task waits for a launch; a routine-created task and a request made through the job composer both start immediately.
* **In progress** — the work is happening. Status describes the state of the work, whoever does it: a person can move a task here and work it by hand. Launching opens the default Membrane agent in the task's session, and changing the status label alone does not launch work.
* **On hold** — the work is deliberately waiting. A hold records why it is waiting and, when it is
  scheduled, the time it will resume. Without a resume time, the hold is indefinite. A prompt or an
  event wakes the task early.
* **Done** — the work finished and its results are recorded.
* **Exception** — the task was explicitly marked as needing exception handling. A failed built-in agent run does not move the task here.
* **Cancelled** — you asked it to stop, or the operator withdrew a proposal before anyone decided. Membrane commits this state immediately, then asks the executor to wind down.

An agent run only launches when its job can run: the job has an operator and isn't paused.

At the end of a run, the agent has three exits: finish the task, put it On hold until a time, or
raise it to the operator and leave it open. Nothing closes a task automatically. If a run ends
without an outcome, the task stays In progress and the operator receives an inbox item that links
to its session.

## The task and its session

A task reads like an issue: the full outcome at the top, comments below. **Comments** are notes from people — or from the agent working the task, when it has something worth recording for the team. A comment never launches anything and never changes status.

The task's **session**, in the side panel, is where you start the Membrane agent, watch the full working transcript — messages, tool use, results — and talk to it. Anything you type in the session is a **prompt**: clarify the outcome, redirect it, ask for a status. Prompts sent while the agent is working are queued and handled in order. **Stop** closes the task as Cancelled immediately and then asks the agent to wind down.

If a run fails or is stopped for spending, the inbox item explains the cause. From there, the operator can prompt the failed session to continue. A task-spend ceiling offers `continue-task-run`; a session-spend ceiling requires `run-task`, which starts a fresh session with a fresh session budget.

Comments belong to the task; prompts belong to the session. While a session is live, new comments are passed to the agent as context — not as instructions. Together with status changes, run events, and receipts, they become TaskActivities: the durable task timeline that remains intact across runs.

A finished task isn't sealed: prompting its session re-opens the work with the full history intact. That's also how results come back for another pass — see below.

## Tasks and receipts

Results a task produces are recorded as receipts against the job's [deliverables](/docs/how-membrane-works/deliverables). Each receipt links to the task whose run produced it, and the operator's review decision flows back into that task as a prompt:

* **Issue** — the work stands and becomes visible to the client.
* **Send back** — the task resumes with the reason, revises the work, and submits the receipt again.

So a task with reviewed output typically runs in two acts: produce and submit, then issue or revise. The full status model is in [Receipt Lifecycle](/docs/how-membrane-works/deliverables/lifecycle).