Turn shipped changes into launch content

The Marketing Agent can turn what your team shipped (merged pull requests, changelog entries, release tags, and closed tickets) into a launch post, a LinkedIn post, or a newsletter draft.

Nothing starts on its own when you merge or release: you start the session. For the whole job, with docs and release notes from the Docs Agent, follow the recipe Turn a release into docs, release notes and a launch post.

Before you begin

Any member of your organization can start a Marketing Agent session.
The repositories that hold your code and changelog are connected through GitHub or GitLab.
To include closed tickets, Jira or Linear is connected. See Integrations.
Your Company Profile has Tone and Voice filled in, under Settings > Organization > Company Profile.

Steps

Click New session, select Marketing Agent, and select a format: Blog post for a launch post, LinkedIn post, or Newsletter.
Say what shipped. Either give a time window, or name the changes:
- A window: write it in Topic, or in Period for a newsletter, for example “releases since 1 September”. Without one, the agent looks back 14 days. The longest window is 90 days.
- Specific changes: paste pull request numbers, a release tag, or a changelog file path under Sources and files.
To get more than one format from the same changes, select them under Also make, from the same brief.
Click Create draft, then answer the agent’s questions. For a launch post, it asks when no source says who can use the feature today (plan, version, region, or beta), or where the call to action should point.
Read the agent’s sizing for a launch post. It recommends one of: a changelog line and no post, a product update post (600 to 1,000 words), a launch article (1,200 to 2,000 words), or a company launch that also needs a launch plan. When it recommends a changelog line, it gives you the line in the chat and still writes the post you asked for.
Review the draft in the editor, then click Copy or Download and publish it yourself.

What the agent includes and leaves out

A launch post says exactly who can use the feature today, by plan, version or release, region, or beta. A feature behind a flag, in beta, or on the roadmap is never described as available. The post also covers what changes for the reader (a before and after), objections taken only from your sources such as support threads, sales notes, or documented limits, and one call to action whose link the agent opens to check it works.

A release roundup leaves out any change that was:

reverted in the window
a security or vulnerability fix
behind a feature flag, with no sign it is fully rolled out
internal only: refactors, infrastructure, build tooling, tests, or dependency updates with no visible effect for users
a documentation-only change

It also drops a change when no source explains why it matters to users. A newsletter gets one section per remaining change, ordered by what matters most to its audience. If every change is excluded, that is a quiet window, not an error.

Release notes and changelog pages are Docs Agent work, not Marketing Agent formats. See Generate release notes.

Check it worked

The draft is open in the editor.
The chat summary lists the pull requests, tickets, or changelog entries the draft rests on, with links.
A launch post includes a line that says who can use the feature today.

Troubleshooting

What you see	What to do
The agent says it cannot reach any source	Connect the repository through GitHub or GitLab, or paste the pull requests or changelog under Sources and files.
The agent asks for a shorter window	It works on at most 90 days at a time. Split the period into smaller windows.
A change you expected is missing	It matched one of the exclusions above. If it was behind a flag and is now fully rolled out, point the agent to the release note, pull request, or ticket comment that says so.

Built on Potluck Docs, our open source template.