This is an example of an agent you can build with Sylvie: tell it what changed and who needs to know, and it writes the full in-product message set (banner, tooltip, modal, empty state, toast) at the right length for each surface, each one carrying a single clear action. It runs on your brand brain, so the wording matches your current feature names, your UX writing rules and the launch email going out beside it. Sylvie does not ship it pre-built; your team assembles it on the brain that holds how this product talks to its users.
Sylvie does not ship this agent pre-built. It is an example of an agent your team can build with Sylvie, powered by your brand brain, so it runs your workflow the way you actually run it.
The In App Notification agent is an example of what a marketing or lifecycle team can build on Sylvie: a writer for the messages that appear inside the product itself, covering feature announcements, onboarding nudges, trial and plan prompts, deprecation warnings and maintenance notices. Each one is written to the constraints of the surface it will live on, not pasted into a component that then has to be redesigned around the copy.
In-product copy is usually written last, in a ticket, by whoever is free that afternoon. That is why the banner says one thing, the launch email says another, and the tooltip still uses a name the product retired two releases ago. An agent built on your brand brain writes the whole set from the same facts and the same voice, so what a user sees in the product agrees with what lands in their inbox.
Before it writes a word, the agent reads the brand brain: the product facts and the feature names as they stand today, the tone of voice and the UX writing rules your team has agreed on (sentence case, verb-first actions, no exclamation points), the segments and lifecycle stages you message, the campaign or email already approved for this launch, and the notifications you have run before. The brain is permission-aware, so the copy is grounded in what this product is cleared to claim.
Then it produces the set end to end inside Sylvie: one message per surface with character counts respected, a primary and secondary action on each, variants by segment (trial against paid, admin against member), and a version per locale if you run multiple markets. It hands the finished set to wherever your team works, so product and marketing review the same copy in one place before anything reaches a user, and every approved set stays in the brain as the reference for the next one.
A tooltip, a banner, a modal and an empty state need different copy, not the same sentence resized. Each message is written to fit where it appears, so nothing is truncated and nothing swamps the interface.
The in-app set is generated from the same facts as the launch email and the release note, so a user is never told two different versions of the same change in two different places.
Names and behavior come straight from your brand brain, so a notification never announces something using a label the product stopped using two releases ago.
Variants for trial, paid, admin or brand-new accounts come out of the same run, so each person reads a message that fits their situation instead of a notice addressed to everyone.
Every message carries one job and one clear action with a reason to take it now, so the notification produces an activation rather than another thing to close.
If you run several markets, the set comes back per locale in the same voice, so the rollout is simultaneous instead of waiting a week for translations to catch up.
A few of the moments a team builds this agent for, every message written from the same brand brain that produced the campaign around it. The outcome is in-product copy that ships on the same day as the feature and says the same thing as the email.
Engineering ships on Thursday and marketing has a day to announce it. The agent writes the banner, the tooltip walkthrough and the updated empty state alongside the launch email, so the feature gets found inside the product instead of quietly living in the changelog.
Users on day twelve of a fourteen day trial need a nudge that is honest rather than desperate. The agent writes the prompts by day and by usage level, so people who reached real value get a specific reason to convert and the rest get a reason to keep going.
New accounts consistently stall at the same screen and never reach the moment the product clicks. The agent rewrites that empty state and its nudge in your voice, pointing at the next action rather than describing the page, so more accounts get past the step that was costing you activation.
An old feature is being switched off and the message has to be clear without triggering churn. The agent writes the warning, the in-product countdown and the migration prompt from approved wording, so support fields fewer angry tickets and more users finish the move.
New packaging affects each segment differently and a single generic notice would be wrong for most of them. The agent writes a variant per segment against approved messaging and the facts of what actually changes for whom, so every user reads something accurate to their plan.
A release has to appear in four languages at once and translations normally arrive a week late. The agent produces every locale in one pass in the same tone, so the announcement goes live everywhere on launch day rather than in a staggered trickle.
It is not a delivery tool and it does not replace the one you have. This agent does the thinking and the writing (which message, on which surface, for which segment, in what words), then hands the finished set to your team to ship through whatever you already use to trigger in-app messages.
You build it. Sylvie does not ship a finished In App Notification agent; this page is an example of what a team assembles on the platform. Sylvie helps you wire it to your brand brain, your UX writing rules and your review process, so it produces copy your product team will actually approve.
It reads your current product facts and feature names, your tone of voice and UX writing rules, your segments and lifecycle stages, and the campaign already approved for the launch, then writes every surface against that same source. Nothing is invented, because the claims come from the brain rather than from a model's guess about your product.
Both, and that is a build-time decision rather than a fixed answer. You define what the agent takes in (a release note, a campaign brief, a segment definition) and who signs off, so the same brain can power a launch-focused version and a lifecycle-focused version with different inputs.
You set the rules and the agent writes to them: one job per message, a cap on what a segment sees in a week, a hierarchy for what deserves a modal against a quiet banner. Those rules live in the brain, so every new set is written against the same discipline instead of each launch fighting for attention.
No. It works from your brand knowledge and the segment definitions you hand it, not from raw user records, unless you deliberately connect a source. Every brand brain is isolated and permission-aware, so what one team or client puts in never surfaces anywhere else.
Book a demo and we will map the workflows worth turning into agents, and show how each one runs on your brand brain.
Request a demo