3 ms·
How we manage agentic memory is going to be key in scaling the future of agents. I'm curious how this scales with larger datasets? Like let's say an agent has t
by Findkar 9mo ago
How we manage agentic memory is going to be key in scaling the future of agents. I'm curious how this scales with larger datasets? Like let's say an agent has to keep 5 parallel conversations, across 5 different social media acccounts, and each of the conversations is 10000 messages long. How would it manage parsing through huge DBs like that? or is it more for like more recent context?
Also, let's say an agent runs like 1000s of times, would each of those times become a version history?
I'm particularly interested in how parsing through agent context would work!
- ofabioroma 9mo agoGreat questions. On scaling: appends don't create versions, only updates and deletes do. So for your 10k message conversations, uc.get() is O(n) reads. Standard database scaling. The versioning overhead only kicks in when you're actually mutating context, and even then we handle the optimization so you don't have to think about it. On version history: each agent run doesn't create a version. Versions are created when you update or delete a message. So if your agent appends 1000 messages across 1000 runs, that's just 1000 appends. No version explosion. Time travel (rewinding to a specific point) is also O(n). This was my personal main bottleneck when deploying B2C agents, so the API is heavily optimized for it. For your 5 accounts x 5 conversations setup: you'd have 25 separate contexts. Each scales independently. Parse through them however you want, filter by metadata, retrieve by timestamp or index.