Two read paths, one item
The same items answer "what happened last" and "what is relevant", through two different reads.
Why
An assistant needs two different things from its history. It needs the last few messages, in order, every single turn. And occasionally it needs the one thing the user said three weeks ago that bears on what they just asked. Those are different questions, and they want different reads.
The first is a Query on the session partition, read backwards with a Limit. It is the cheapest read in the course: the key decides what to read, nothing is scanned and thrown away, and the order is exact.
The second is a vector search, and the decision that makes it work is what the index is partitioned by. The SearchSchema here declares userId as its HASH, not sessionId. Partition by session and relevance can only ever reach inside the conversation you are already in, which is the one place recency has already covered. Partition by user and it reaches across every conversation they have ever had. That is the entire reason for keeping this in DynamoDB beside the items rather than in a separate vector database.
There is no join and no synchronisation between the two. The index is maintained as part of the base write, so a message is searchable the moment it is written. Merging the two result sets is your application's job, and there is no ranking that combines a sort order with a similarity score for you. That is a judgement about your product, and DynamoDB is right not to guess at it.
A vector index is a second read path over the same items; partition it by the axis relevance needs to cross, which is usually not the one recency already covers.
Try it. Then change it.
Predict what each request will do. Run it, inspect the response, then change a value in the workbench and try again.
The recency window: one session's partition, read backwards, capped at six. Cheap, exactly ordered, and completely blind to anything said in an earlier session.
"How did we decide to do the kubernetes rollout", scoped to one user rather than one session. The answers come from a conversation nearly a month old, which the recency window above would never have reached.
Fetch one of those search hits straight from the table. Same keys, same text, plus the embedding the search results left out. The index is a second read path over your items, not a second copy of them.
Built on this
- Agent Memory Store - What should this agent remember?
The recency window: one session's partition, read backwards, capped at six. Cheap, exactly ordered, and completely blind to anything said in an earlier session.
Choose an access pattern above, or build your own request. See what comes back and what it costs.