Carrying a Persona Forward: Fixing a Bot Onboarding Migration That Could Overwrite It
What Is dm_persona?
Every HelaSyn bot has a dm_persona: the personality and voice an owner has configured for their bot in direct messages -- distinct from the bot's public-facing identity. Owners can write a persona from scratch, and once set, it is meant to persist indefinitely, independent of any later platform changes.
HelaSyn recently introduced a v2 conversational onboarding flow -- a guided, chat-based setup that captures an owner's preferences (name, tone) and builds a persona from a template plus those captured slots. Bots onboarded under the old model already had a persona of their own, built a different way, with no v2-specific bookkeeping attached to it.
What Happened
A stray [GUARDIAN:] tag -- an internal directive tag the bot's own output can emit -- reached an old-model bot that had never been through v2 onboarding. The onboarding code checked whether the bot's setup was "complete," saw that it was (the bot already had a persona), but did not distinguish how that persona had been built. It proceeded to rebuild dm_persona from the v2 template and freshly-captured slots, discarding the owner's original persona -- in this case, a distinctive, fully custom one the owner had written by hand.
The migration was lossy in a specific way: it replaced the old state instead of carrying it forward, on the assumption that any bot reaching that code path needed a fresh v2 build.
The Fix
The fix (persona.py, tag_processor.py) adds a carry-forward guard at both places a rebuild could be triggered: build_guardian_persona and the [GUARDIAN:] tag handler itself.
The guard's signal is the absence of a specific marker (_guardian_persona_sig) that is written only when a persona is genuinely built by the v2 flow. If a bot has a dm_persona but no such marker, that persona was owner-authored or built under the old model -- and the fix treats it as something to preserve, not rebuild:
- The existing persona is left untouched, verbatim.
- The bot's "onboarded" flags are latched for both the old and new model, so the code path that caused the rebuild cannot fire again for that bot.
- No
_guardian_persona_sigis written on a carried-forward persona, on purpose -- its continued absence is what keeps the guard authoritative on every future call, even after the bot is marked v2-complete.
The result is idempotent: running the carry-forward logic again on an already-migrated bot is a no-op, and a genuinely new bot going through v2 onboarding for the first time is unaffected.
Verification
Six new regression tests were added covering both the persona-builder and the tag-handler code paths (four cases for the builder, two for the tag handler); the full onboarding test suite -- 46 tests in total -- came back clean. The fix went through HeLa's standard security and quality gates before merging, and the affected bot's persona was restored from a backup and independently verified intact after the fix and a fleet-wide restart of 62 bots, with no other bot affected.
Why This Matters
The bug is a common shape for any migration that has to handle two generations of the same kind of state: a check for "is setup complete" is not the same question as "was this built by the new code," and conflating the two can make a migration destructive for exactly the users it should least affect -- the ones who set things up carefully before the migration existed. The fix generalizes past this one bug: any future change to onboarding has the same carry-forward guard available to build on, rather than needing to invent this check again.
Q&A
What is dm_persona?
The personality and voice configuration a HelaSyn bot owner sets for how their bot behaves in direct messages.
What caused the bug? A migration path treated "has a persona already" as equivalent to "was onboarded under the new flow," when the two are different questions. Bots onboarded under an older model had a persona but no new-flow marker, and a stray internal tag triggered a rebuild that discarded it.
Was any user's data permanently lost? No. The one affected bot's persona was restored from a backup, and the fix independently verified as correct before the fleet-wide restart -- the restored persona was confirmed intact afterward.
How was the fix verified? Six new regression tests plus the full 46-test onboarding suite, both coming back clean, in addition to HeLa's standard security and quality review gates.
Does this affect new bots going through onboarding today? No. The guard only preserves personas that already existed before the v2 flow touched them; a new bot onboarding for the first time builds its persona normally.
What's Next
The fix has merged and is live across the fleet. The broader lesson -- distinguish "already set up" from "set up by the current code" whenever a migration spans two generations of the same state -- is now documented alongside the onboarding design for future changes to build on.