landing_page — Landing Page Copy

Field	Value
Type key	`landing_page`
Label	Landing Page Copy
Agent queue	`agent__landing-page-writer`
Plan tier	Pro only (professional plan)
Credits/unit	3
Monthly range	0–2

What it produces

Full conversion-focused landing page copy rendered as a self-contained HTML file. Output stored in a LandingPage DB record with seven parsed sections (hero, problem, solution, features, socialProof, faq, cta) plus metaTitle and metaDescription.

Typical structure:

Hero section: H1 headline + subheadline + CTA button
Problem section: Pain points as cards
Solution section: How the product solves it
Features/Benefits: 3–6 benefit-led cards
Social proof: Testimonial placeholders + trust signals
FAQ: 3–5 objection-busting questions with answers
CTA section: Final conversion push

HTML is rendered on demand by renderLandingPageHtml() in packages/common/src/landing-page-html.ts — inline CSS, no CDN, no JS.

Pipeline sequence


Activity queued
      │
landing-page-writer worker
      │
LandingPage created (status: dm_review)
Activity.status = awaiting_approval
      │
DM reviewer approves in DM portal
LandingPage.status = client_review
      │
Client approves in Dashboard
LandingPage.status = client_approved
Deliverable.status = approved

Rejection at either gate re-enqueues the worker with wakeReason: "rejection" and increments LandingPage.version.

Status machine

Activity status

Status	Meaning
`pending`	Scheduled, waiting
`queued`	Submitted to BullMQ
`in_progress`	Worker running
`awaiting_approval`	Copy written; waiting for DM review
`failed`	Worker error

LandingPage status

Status	Meaning
`dm_review`	Awaiting DM reviewer approval
`client_review`	DM approved; awaiting client approval
`client_approved`	Fully approved; Deliverable set to `approved`
`dm_rejected`	DM rejected; worker re-enqueued
`client_rejected`	Client rejected; worker re-enqueued

HITL gates

Gate	Reviewer	Portal	Action on approve	Action on reject
DM review	DM reviewer	`/landing-pages/[id]`	`status → client_review`	Re-enqueues worker with feedback; `version++`
Client approval	Client	Dashboard `/landing-pages/[id]`	`status → client_approved`; Deliverable approved	Re-enqueues worker with feedback; `version++`

Dependencies

None. The landing page writer reads tenant context from ClientContext and the AgentConfig system prompt. No upstream activity dependencies.

DB records created

Record	Created by	Notes
`Activity`	activity-planner	One per landing page; `deliverableType = "landing_page"`
`LandingPage`	landing-page-writer worker	Holds `content` (raw markdown), `sections` (JSON), `slug`, `metaTitle`, `metaDescription`, `version`, `status`
`Deliverable`	landing-page-writer worker	Linked to `LandingPage` via `landingPageId`; moves `generating → in_review → approved`

Plan restriction

Landing pages are available on the Professional plan only. The deliverable planner checks PLAN_TIER before including this type:

DB plan name	Tier	Landing pages?
`starter`	0 (free)	No
`growth`	0 (free)	No
`professional`	1 (pro)	Yes

Key rules

3 credits per landing page is the highest per-unit cost of any activity type, reflecting the depth of copy produced.
No publishing integration — the HTML file is downloaded by the agency/client and deployed to their CMS or website builder.
Monthly volume (0–2) is determined by the deliverable planner based on campaign goals and the tenant’s subscription tier.
The HTML renderer normalises legacy agent output — pages generated before the April 2026 prompt fix (which emitted H1: / Subheadline: labels as text) are backfilled via normalizeLabels() in landing-page-html.ts and render correctly without regeneration.