Vector DBs are great for retrieval: "find relevant chunks to add to the prompt." But they're not designed for state management. When you update a message, there's no version history. When something breaks, you can't rewind to see exactly what the agent saw.

UltraContext manages the structured context (conversation history, tool calls, system prompts) with git semantics. Fork, rewind, merge. You can't git revert a vector embedding.

They're complementary. You'd use a vector DB to decide what goes in the context, and UltraContext to manage what's already there.

On UltraContext, you'll do it like this:

// Shared context all agents read/write to

await uc.append(sharedCtx, { agent: 'planner', content: '...' })

await uc.append(sharedCtx, { agent: 'researcher', content: '...' })

// Or fork into separate branches per agent

const branch = await uc.create({ from: sharedCtx, at: 5 })

Schema-free, so you can tag messages by agent, track provenance in metadata, and branch/merge however you want. Full history on everything.

The goal is to focus on the core building blocks that enable more sophisticated use cases. Compression, compaction, and offloading strategies should be straightforward to build on top of UC rather than baked in at the core layer.

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.

For sensitive use cases, I'm exploring a few options: client-side encryption, data anonymization, or a local-first deployment where context never leaves your infra. Not there yet, but it's on the roadmap.

What's your use case? Happy to chat about what privacy guarantees you'd need.