I built an agent that turns a shipped release into a launch email
· #building #automation
Every launch email used to take me about 1 to 2 hours. Write the email, make the artwork in Figma, then get it out to users. Now an agent does the whole thing on its own, right through to sending it.
Launch emails are one of those jobs everyone agrees matter and nobody wants to do. The feature ships, and someone has to work out what actually changed, write the copy, get artwork made, build the email and send it to the right people. By the time that happens the release is a week old and the email goes out late or not at all.
For a fintech I work with, I turned that whole process into an agent skill in Codex. A person flags a release, and a little later the launch email is out. Here's how it works and what I learned building it.
The trigger is a human
The run starts when someone flags a release in Linear. That's it.
I first tried having the agent monitor for new releases every 5 minutes. It worked, but it caused more noise than value. Releases get marked ready at odd times, things get rolled back, and a draft for every flicker of status isn't what anyone wants. I paused the monitoring and switched to a human-triggered run.
That turned out to be the right call. The person who flags it already knows it's worth announcing. The agent's job is everything after that.
Step 1: build a brief it can trust
The agent reads the flagged issue, its parent, any child issues, the comments and the linked docs. From that it writes a short brief: what changed, who it's for, what it does, and what the limits are.
The important rule here: "ready to announce" is an editorial signal, not proof the thing is live. The agent has to check rollout and availability before it says anything about them. It never claims a feature is live, free or available to everyone unless there's evidence for it.
That rule is boring but it matters most. An email that announces something customers can't use yet does more damage than no email at all.
Step 2: write the copy
For tone and structure, the agent looks at the previous launch email. For facts, it uses the current docs and the brief. Keeping those two apart matters. Old emails are good for voice and terrible for facts.
Every email follows the same shape:
- One subject line, led by the benefit
- A preview line
- A few real use cases
- Any limits, stated plainly
- One call to action
It's also told not to pad small updates. A minor improvement gets a short email. Stretching a small release to look like a big one is how people learn to ignore your emails.
Step 3: make the artwork in Figma
This was the part I expected to be hardest, and it ended up being one of the most useful.
The agent clones the frame from the last release's artwork and adapts it to the new feature. Same brand, same layout, new content. Then it checks the result is still readable at 600px, which is roughly how wide it'll be in an inbox. Text that looks fine on a big canvas is often unreadable in an email.
It exports a 1200px PNG so it stays sharp on retina screens, and hosts the image properly. Not an editor link. A Figma link in an email is a broken image waiting to happen.
Step 4: build the email in HubSpot and send it
The agent clones the previous launch email in HubSpot. That keeps the template, footer and sender exactly as they were, so nobody has to recheck the boring stuff. It drops in the new copy and artwork, sets the two audience segments, and sends it to the right users.
The guardrails
Most of the work in agent automations goes into the guardrails, not the happy path. These are the ones that mattered:
Check the facts before anything goes out. Every claim in the email has to trace back to the brief and the current docs. The agent never says a feature is live, free or available to everyone without evidence. Once it sends itself, this is the guardrail doing the most work.
No duplicate emails. Each release gets a stable key, and the agent keeps a small local record of what it has already created. If the run happens twice, it finds the email it already made instead of creating a second one. Nobody gets the same launch email twice.
One release, one email. No bundling, no splitting. That keeps everything traceable from the issue to the email.
The gotcha
The HubSpot template is a coded one. When the agent pulled the email through the API, the layout came back with empty sections, even though the email renders perfectly in HubSpot.
If the agent had trusted that and sent the layout back, it would have overwritten the real email with a blank one. So the skill now tells it to make those changes through the editor rather than pushing an empty layout through the API.
That's the sort of thing you only find by running it for real. APIs don't always show you what's actually there.
What I'd tell anyone building something similar
Start with a human trigger. Monitoring sounds clever but a person flagging the work is usually the better signal.
Separate where tone comes from and where facts come from. Past work for voice, current docs for truth.
Make it safe to rerun and make it check its facts before you let it send.
If you're a small team shipping often and your launch emails keep slipping, this is a very buildable workflow. Happy to compare notes if you're trying something like it.