Tasks

A task is one unit of work inside a job 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

• 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. 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.