Long-Term Memory: Preferences the Agent Keeps Between Sessions

"Remember that our logo goes in the bottom right" and "remember that I never want captions on my videos" sound like the same kind of instruction — both are things you're saying once and expecting to stick. They're not the same kind of instruction, and Versely's agent actually keeps them in two different places for a reason: one is a fact about how you like things done, and the other is a physical asset that has to be fetched and applied to a render. Put a logo file's description into the preferences store or a tone-of-voice rule into the brand kit, and it technically gets saved somewhere — just not the place that actually uses it the way you need it used.

Two stores, two different jobs

remember is for durable preferences and lasting facts — the kind of statement that shapes how future conversations should go, not what gets pasted into a specific render. "Always make my videos 9:16." "My audience is Gen-Z gamers, keep the tone playful." "Keep captions minimal on my content." Each of those is a standing instruction about how to work with you, and the tool's own description is explicit about its boundary: it's for durable preferences and lasting facts about the user or business, and it's not for one-off instructions scoped to a single request. Ask for something once, mean it once, and it doesn't belong here — that's what makes a normal request a request instead of a memory.

set_brand_kit is the other store, and it's scoped to something narrower and more concrete: colors, fonts, logo, product shots, voice and tone, a tagline, a default caption style, a default aspect ratio. These aren't preferences in the abstract sense — they're assets and specifications that get pulled into an actual generation, the way a hex code gets applied to a graphic or a logo file gets composited onto a frame. The tool's own guidance draws this line directly: brand assets like colors, fonts, logo, and tone explicitly do not belong in remember — they belong here instead.

Why the split exists instead of one big memory bucket

It would be simpler, on paper, to have one memory store that took everything. The reason it doesn't is that the two kinds of information get used differently downstream. A preference like "keep captions minimal" is a instruction that gets read and interpreted — it shapes a decision the agent makes about how to build something. A brand color is not interpreted at all; it's a literal value that gets applied — #FF5733 doesn't need judgment, it needs to be pulled and used exactly as saved, every time, without drift. Folding a hex code into a pile of freeform preference text would make it something the agent has to re-parse and re-interpret on every use instead of a fixed value it can just apply, and that's a worse system for the one category of information that most needs to stay exact.

The brand kit is also built to be updated in place without disturbing everything else already saved: sharing a new accent color doesn't wipe the logo or the tone-of-voice notes, because colors and fonts merge by key rather than replacing the whole object, and only the specific fields you mention actually change. That partial-update behavior is a brand kit thing specifically — it's what makes it safe to add one detail at a time over several conversations instead of having to restate the whole kit every time something new comes up.

The mistake people actually make

The common error isn't putting a brand fact in memory outright — most people who've used the tool a few times get that far. It's a subtler version: mentioning a brand detail conversationally, expecting it saved, and having it land as a general memory instead of a brand-kit field, because the request didn't sound like "set my brand kit," it sounded like an aside. "Oh, and our tone is playful but confident" said in passing during an unrelated request is exactly the kind of line that should trigger a brand-kit update, not a generic remembered fact — the tool's own guidance calls this out directly, saying to proactively offer a brand-kit save whenever someone describes brand details in conversation, specifically because those details tend to arrive as asides rather than deliberate setup requests.

The reverse mistake is rarer but just as costly: trying to force a standing behavioral preference — "always keep my videos under 15 seconds," "never use stock voiceover, always clone mine" — into the brand kit's fixed fields, where there's no natural slot for it and it either gets dropped or bent into a field it doesn't really fit. That kind of instruction is exactly what remember exists for. It doesn't need a value to be applied literally — it needs to be interpreted every time a relevant decision comes up, which is what a memory entry is for and a brand-kit field isn't.

Both are visible, and that's not incidental

Neither store is a black box. Everything saved through remember is user-viewable and user-editable in the app's Saved Context settings, and the brand kit can be read back in full at any point rather than trusted blindly to be correct. That visibility matters more than it might seem, because both stores are working silently in the background from the moment something is saved — a preference or a brand detail set three weeks ago is still shaping today's output whether or not anyone's actively thinking about it. Being able to open the settings and see exactly what's been remembered, and edit or remove anything that's gone stale, is what keeps "the agent remembers things" from turning into "the agent is doing something and nobody's sure why."

Versely walkthrough: saying both kinds of thing in one conversation

A realistic exchange touches both stores without the user having to think about which is which — that's the agent's job, not yours — but it's worth seeing the split in practice:

1. "Our brand color is #2B6CB0, our tone is confident but not corporate, and here's our logo." This is a brand-kit update: concrete assets and specifications that will get applied literally to future generations, saved as a partial update that layers onto anything already there.
2. "Also, remember that I always want a 9:16 aspect ratio unless I say otherwise, and keep captions minimal — my audience skims." This is a lasting preference: a standing instruction about how to make decisions, not a value to paste into a render.
3. Both land correctly without you naming which store each belongs to — the split shown above is what the agent is checking against when it decides where a given statement actually goes.
4. Weeks later, either can be checked or corrected directly: ask what's currently saved in the brand kit, or review everything under Saved Context, and edit anything that's drifted from what's actually true now.

For the fuller picture of what a brand kit is meant to hold and why it binds harder in some places than others, that's worth a separate look — the short version for this post is just knowing which of the two stores a given piece of information actually belongs in.

Takeaway

The line between the two stores isn't complicated once it's named: if it's a value that gets applied literally to a render — a color, a font, a logo, a tagline — it belongs in the brand kit. If it's a standing instruction that shapes how a decision gets made — an aspect ratio default, a tone rule, a fact about your audience — it belongs in memory. Getting this right isn't about memorizing the distinction yourself; it's about recognizing that both exist, both are visible and editable, and saying the thing once, in either direction, is genuinely enough.