Skip to content

Work with content assets

A content asset is one deliverable: a blog post, a social post, an email, a landing page, a case study. Assets are real records with a body you can read, not chat messages an agent wrote once.

OriginHow it gets here
generatedAn agent drafted it with the content tool, usually as a workflow step
importedYou made it yourself with + Add asset: composed in the app, pasted, or uploaded
referenceYou recorded something that already lives elsewhere, by its URL

+ Add asset offers four ways in. Compose is for writing a first draft directly in the app; Paste text, Link URL, and Upload file bring in something that already exists. Composed and pasted content both carry the imported origin, and that origin is why they always publish through human approval: the autonomy ladder only vouches for agent-generated content grounded in product truth.

Origin is not cosmetic. Content derived from an imported asset stays imported, so nothing can be laundered into the auto-publishable lane by passing it through a derivation.

Click any row in the assets view, or any row in a campaign’s asset table. The drawer shows:

  • the type, origin, channel, and campaign on one line,
  • the body, in full, or a Download link for an uploaded file (the link is short-lived, minted when you click),
  • metrics, once anything has been measured for it,
  • lineage, when the asset was derived from another or has derivatives of its own,
  • brand-safety lint results, after a publish attempt.

Edit in the drawer header opens the title, body, channel, and campaign for text assets. Uploaded files are not editable in place; upload a new version instead.

Status moves with two small actions:

  • a draft offers Mark approved, which records your editorial pass,
  • an approved asset offers Back to draft.

An asset in in_review offers neither. That status means a publish is already parked in the approvals queue, and the decision belongs there; the drawer links you to it.

Atomization derives one asset per target channel from a source asset, and records the link back to the source on each one.

It happens three ways:

  • Atomize in the drawer: add a row per target channel, pick each variant’s type, and create them all at once. The channel field suggests the campaign’s channels,
  • as the atomize step of the Launch Announcement or Content Atomization workflow,
  • by asking an agent that has the content tools to derive variants for named channels.

Each derived asset arrives as a draft, titled after its source with the channel in brackets, carrying a copy of the body to rewrite for that channel. From there it is an ordinary asset: rewrite it, give it a date, publish it.

The announcement post open in the drawer, with the social and newsletter variants derived from it listed under Lineage, both now scheduled.

Alpenglow’s two variants are past that first step: both have been placed on the calendar, one and four days after the post they came from.

Open the source asset and read the Lineage section: every asset derived from it, with its current status. Open a derived asset instead, and lineage points the other way, naming the asset it came from and how it was derived.

That is what makes a correction cheap. When the announcement turns out to overstate something, the family tree tells you exactly which posts repeat it.

Publish now in the drawer runs the full gate: brand-safety lint first, then the autonomy level for that channel’s action class. What comes back is one of three things:

  • blocked by lint. A banned phrase or a prohibited claim. Fix the content and retry. This stops a publish at every autonomy level.
  • queued for approval. The default. The request is now in your approvals queue carrying the exact payload that will be sent.
  • published. Only at a raised autonomy level, and only through an active binding.