Skip to main content
Every deliverable carries a status — Pending, Needs review, Approved, Shipped, or Voided — that tells you exactly where it is on its way to you. This page explains each status: what it means, how a deliverable gets there, and what can happen next.

How deliverables are created

Deliverables are created when tasks are executed:
  • Automatically, when a task starts. Deliverable types marked automatic for a task are created by Membrane the moment the task launches, in Pending — before any work happens, so the work can’t finish without its record. The deliverable’s id is passed into the task, and the agent updates that record rather than creating its own.
  • By the agent, as the work produces resultscreate-deliverable. The agent creates the deliverable directly in the status that fits: Pending if the work is still underway, Needs review if it’s ready for sign-off, or straight to Shipped for pre-approved work that’s already delivered.

Needs approval vs. pre-approved

Each deliverable type on the job has an autonomy setting, one of:
  • Needs approval — the operator signs off every deliverable of this type before it ships. For high-stakes output: a report going to the CFO, a closed month.
  • Pre-approved — agreed once, at job setup; deliverables ship as soon as the work is done. For routine, high-frequency output: customer requests, daily digests.
Pre-approved work can still be submitted for review when the agent wants a human check.

The statuses

Pending

The deliverable exists, but hasn’t been delivered or handed over for review. The agent updates its content and line items as the work progresses (update-deliverable). Gets here by: being auto-created at task launch, being created by the agent mid-work, or being rejected in review and returned for rework.
CommandWhoMoves toNotes
update-deliverableAgentEdit content and line items
submit-deliverable-for-reviewAgentNeeds reviewCreates a review item in the operator’s Inbox
mark-deliverable-shippedAgentShippedPre-approved types only
void-deliverableOperatorVoidedKill work that should never ship

Needs review

Waiting for the operator’s decision. Submitting created an item in the operator’s Inbox, and the Inbox is where the review happens: approve or reject on the spot, with the deliverable’s content, task, and price in front of you. The operator can correct the content directly, or ask the agent to revise it — both can edit here. Gets here by: the agent submitting it from Pending, or creating it ready for review in the first place.
CommandWhoMoves toNotes
update-deliverableOperator / AgentCorrect directly, or the agent revises on the operator’s instructions
approve-deliverableOperatorApprovedSign off — content freezes
reject-deliverableOperatorPendingSend back for rework; comments optional
void-deliverableOperatorVoided

Approved

The operator signed off. Content and line items are frozen — what was approved is exactly what ships — and the producing task is resumed with the approval so it can deliver the result. Gets here by: the operator approving it in review.
CommandWhoMoves toNotes
mark-deliverable-shippedAgentShippedThe agent delivers the result, then marks it shipped
void-deliverableOperatorVoidedApproval can still be withdrawn before delivery happens

Shipped

Delivered. Delivering is the agent’s work — only it knows the steps that put this deliverable where it goes (write the sheet, send the email, publish the connector) — and marking the deliverable shipped is its confirmation that those steps completed. From here the deliverable is final: the record of what went out, when, and at what price. Its price is added to the current monthly statement; when that statement is billed at the end of the month, the deliverable’s billedAt is stamped. Gets here by: the agent marking it shipped — from Approved, from Pending for pre-approved work, or at creation when pre-approved work is already delivered. No commands apply.

Voided

Will never ship — rejected for good, duplicate, or out of scope. Never billed. Gets here by: the operator voiding it from Pending, Needs review, or Approved, with a reason. No commands apply.

Nothing gets stuck

Every active status has one party responsible for moving it on — the agent in Pending and Approved, the operator in Needs review. When that party stalls (a task dies with a pending deliverable, an approval never ships), Membrane raises it in the operator’s Inbox.