Sharing long-term memory across two agents comes down to the actorId you write under

The failure mode is filing. A record extracted from a voice session is stored under that session's key, and a chat turn looks up a different key, so neither agent reads the other's records ^[2]. The post names the temptation plainly, letting each agent use its own runtime session as the identity, and introduces the choice as "the insight that makes or breaks the whole thing" ^[5].

So the key has to be the person, present in both entry points before the first turn ^[4]. The walkthrough has that to hand because the chat agent and the voice agent sit in one Amplify Gen 2 backend ^[14]. A voice channel that answers before the caller is identified does not. In my view you should refuse to write long-term records at all until an authenticated user id exists. A record written under a placeholder is worse than no record, because lookups will find it.

What gets stored is distilled knowledge ^[13]. You write raw events, AgentCore Memory runs extraction strategies in the background, and you pick which ones run ^[6]. The walkthrough enables two of the three strategies it names ^[1]. User Preference takes subjective likes and dislikes, such as "prefers ultralight gear" or "budget around 150 euros" ^[7]. Semantic takes objective facts, such as "bought a DayHike 25L Pack" or "camps in winter" ^[8]. Summarization is left off, on the grounds that for a shopping assistant the preferences and the facts are what matter ^[9].

Because extraction is background work, the event write and the usable long-term record are two moments rather than one ^[3]. The post does not say how long the gap runs ^[15]. A shopper who says a budget out loud and opens the chat immediately afterwards hits that gap.

The good engineering here is how much of the problem was already solved. On chat, the Amplify AI Kit persists the conversation to DynamoDB and replays it on every turn, so following "make it cheaper" needs no AgentCore events at all ^[10]. On voice, the BidiAgent keeps the live context inside the open bidirectional stream with Nova Sonic ^[11]. Both are handled, by different mechanisms with different lifetimes: the chat copy sits in a table, the voice copy exists only while the stream is open ^[5]. Neither one covers the long-term, cross-session, cross-channel layer ^[12].

That layer brings a new exposure with it. One actorId holds both what someone said they like and what they actually bought ^[4][7][8], so an identity mapping error does not merely weaken a recommendation, it merges two customers ^[6]. Records already written under a session key also stay filed under it, so a team that ships session keying and corrects it later cannot read its own history back through the new lookup ^[7].

For the number in this walkthrough to transfer to your build, two things have to be true: your voice entry point knows who the user is before it opens the stream, and both channels can agree on one identifier without a lookup that can fail. Both of those are auth questions.