Deliverables

Deliverables, in the sidebar, is the list of everything the agents delivered across your organisation’s workspaces. Each row answers three questions: what it is, where it lives, and what it did. Nothing on the list is a separate record. Each row is put together, every time you open the page, from the same records the Inbox, the receipt and the re-reads use, so the three can never disagree about one piece of work.

What is on the list

A piece of work is listed once something was actually delivered:

It went somewhere. A pull request opened, a draft was created in your editor, or a field was written. If the latest attempt failed after an earlier one worked, it is not listed until a later attempt works.
It is ready for you to put live. New wording for a page, or a post for a network we never post to: written, and waiting for you to paste or post it, or already marked live by you.
It is a listing to file. A directory listing the directory would not take from us, prefilled for you to submit, or already filed by you.
It is a picture. An image a chat or automation drew.
Its pull request was closed without merging. It was delivered and turned down in your own repository, so it stays listed as closed.

A proposal you declined in the Inbox was never delivered, and is not listed.

Types

Type	What it is
Article	A new piece the agent wrote
Page change	A change to a live page: new wording for you to paste, or a field written in Webflow, WordPress or Notion
Fix	A change to a file in your repository, delivered as a pull request
Post	A post for a social network, which you post from your own account
Listing	A directory listing, filed or prefilled
Product copy	A product or collection description or SEO text in Shopify
Image	A picture a session drew

Reading the table

The columns are Type, Deliverable, Where it lives and What it did. With more than one workspace, a Workspace column names the workspace each row belongs to, until you filter to one.

Filter by type with the chips above the table. Each chip carries its count; a type with nothing in it is not offered.
Filter by workspace with the selector beside them, when the organisation has more than one.
The filters live in the page’s address, as ?project=<workspace id>&type=<type>, so a filtered list is a link you can send.
Rows are newest first, by when they last changed. Load more fetches the next page.

Where it lives

The place, such as Pull request #12 on GitHub, Draft in Webflow, Synced to Shopify (draft), Lands in Lovable after merge, Ready for you to post on LinkedIn or Directory listing for you to submit. Under it, the delivery status, as a sentence:

Status	What the row says	What it means
`waiting_on_you`	Waiting on you to put it live, or Prefilled and waiting on you to file it at the directory	Done on our side, and yours to put live: paste it, post it, or file it. These rows are muted and never shown as live
`draft`	Saved as a draft; publish it there to put it live, or Ready to download and use on an image	Saved unpublished in your editor, such as a new article in Webflow or Notion
`synced_draft`	Synced to Shopify as a draft; publish it there to put it live	A new article saved unpublished in your Shopify blog
`open`	Pull request #12 is open for review, or Being published	A pull request waiting for review, or a change that is not live yet
`merged`	Merged pull request #12	The pull request merged
`live`	Live	An approved change one of our integrations put live itself
`shipped`	You marked it live, or You filed it at the directory	You put it live yourself
`closed`	Pull request #12 closed without merging	The pull request was closed without merging

Live is the strongest claim on the list, and it has a rule: only an approved change that one of our integrations actually put live carries it. A draft, a pull request that has not merged, or anything waiting on you is never called live, whatever a vendor’s own status says.

What it did

Only something that shipped (merged, live, or marked live by you) can have moved anything. Until then, the column says what it is waiting for: Measured once you put it live, or Measured once it is live. A pull request closed without merging reads Not shipped, so nothing to measure. After that, it reports the re-reads:

What you see	What it means
Waiting for the +7 re-read	Shipped, and the first re-read has not run yet
Up on 3 of 4 readings at the +14 re-read	Named more often, past the significance test, on that many of the prompt and engine readings
Down on 1 of 4 readings at the +7 re-read	Named less often, past the same test
Up on 2 and down on 1 of 4 readings…	Both directions are real, so no single arrow is shown
No change at the +30 re-read	No difference past the test
Nothing we can prove yet	A difference inside the noise. This is a verdict of its own, never counted as up or as flat
Not measured: no tracked prompt was named for it	Nothing will be measured: the work named no tracked prompt
Not live yet at the +7 re-read; reading again at +14	The re-read did not find the change on the live page, so it measured nothing and waits for the next one
Not live when we re-read it at +30, so nothing was measured	No re-read found the change on the live page, and none is left
Its re-reads were cancelled	The re-reads stopped before any reached a verdict, for example because every prompt they would read was deleted

The latest re-read with a verdict is the one shown. If a later re-read found the change gone from the page, that is added to the line. An image is not measured on its own; the page it goes on is.

Opening a deliverable

Click a row to open it beside the list. The panel shows its Status, What it did, and Approved by: the person who said yes, or your standing permission when the workspace’s approval mode let it go ahead on its own. Then a preview of the thing itself:

Type	Preview
Article	The article, rendered. While it still waits for your yes, this is its current text, including any edit made in Studio; after that, it is exactly what was delivered
Page change, Product copy	The field before and after
Fix	The pull request, read live from GitHub, as in the Inbox panel. If GitHub cannot be reached, or the repository is no longer connected, the change as we filed it is shown instead, with a line saying why
Image	The picture
Post	The post’s text
Listing	The listing’s fields, one per row

Ready for review and Merge stay in the Inbox. The preview here only shows the pull request.

Actions

Each one appears only when it has somewhere to go:

Open where it lives: the pull request, the draft, the post or the page.
Download: an article as Markdown or HTML, a picture as itself, anything else with text as Markdown. A fix has no download: the pull request is where it lives. A download comes from your signed-in session, never from a public link, and the HTML version is rendered without any raw HTML the text contains.
Watch the run: opens the chat or automation run that made it, at the step that made it. Work recorded before we kept that link has no button.

From your assistant

The MCP server has a read-only list_deliverables tool over the same list, for one workspace at a time, and the REST API serves it as GET /v1/deliverables. Neither spends credits, and both work on a spent balance.

Argument	What it does
`type`	One of `article`, `page`, `fix`, `social_post`, `listing_fix`, `product_copy`, `image`
`work_area_id`	Only what one project’s runs made. Project ids come from `list_projects`
`status`	One or more delivery statuses, comma-separated: `waiting_on_you`, `draft`, `open`, `merged`, `synced_draft`, `live`, `shipped`, `closed`
`cursor`	The `next_cursor` of the previous page

It answers {deliverables, next_cursor}, newest first, twenty to a page; next_cursor is null on the last page. Each deliverable carries:

Field	Notes
`id`, `type`, `title`
`work_area_id`	The project whose run made it. `null` for work no project’s run produced
`location`	`{provider, label, url}`. `provider` is the kind of place: `pull_request`, `cms`, `notion`, `copy`, `listing`, `integration`, `session` (an image, in the chat that drew it) or `none`. `label` is the same sentence the table shows, and `url` the link, `null` when there is none
`status`, `status_label`	One of the statuses above, and its sentence
`result`	`null` when there is nothing to measure. Otherwise `{state, label, verdict}`, with `state` `pending` or `measured` and `verdict` one of `up`, `down`, `flat`, `noise`, or `null` until a re-read reaches one
`approved_by`	`{type, name, at}`, or `null`. `type` is `customer` for a person and `system` for your standing permission
`run_id`, `run_url`	The session that made it, which `get_session` reads, and its replay at the step that made it. `null` for work recorded before we kept that link
`dashboard_url`	This page, filtered to the deliverable’s workspace and type
`created_at`, `shipped_at`	`shipped_at` is `null` until it merged, went live or was marked live

An unknown type or status is refused with the valid values in the message, so an assistant can correct itself in one step.

Get started

What you track

Reading the numbers

Pages and AI traffic

The agent

MCP

REST API

Agencies and client reporting

Account

Reference

What is on the list

Types

Reading the table

Where it lives

What it did

Opening a deliverable

Actions

From your assistant

​What is on the list

​Types

​Reading the table

​Where it lives

​What it did

​Opening a deliverable

​Actions

​From your assistant

What is on the list

Types

Reading the table

Where it lives

What it did

Opening a deliverable

Actions

From your assistant