This is really well thought out. The git-like versioning approach for memory artifacts is something I’ve been advocating for after spending way too much time debugging agent state issues.
I’ve been working on AI memory backends and context management myself and the core insight here — that context needs to be versionable and inspectable, not just a growing blob — is spot on.
Tried UltraContext in my project TruthKeeper and it clicked immediately. Being able to trace back why an agent “remembered” something wrong is a game changer for production debugging.
One thing I’d love to see: any thoughts on compression strategies for long-running agents? I’ve been experimenting with semantic compression to keep context windows manageable without losing critical information.
Great work, will be following this closely.
For now, I’m intentionally keeping UltraContext as unopinionated as possible, since every application has different constraints and failure modes.
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.
Quick backstory: every agent project I worked on, I spent more time on context infrastructure than the actual product. Same pattern—duct-tape a store, lose history, debug blind when things broke.
The "aha" was needing git semantics for a project where users wanted to edit messages while still being able to travel back. So that's what I built: immutable history, branch on change, rewind to any commit. But I didn't want to expose that complexity. So the API is just contexts and messages. Versioning happens automatically.
Still early. What context engineering problems are you hitting with your agents?
I don't get it. Why wouldn't I just use a Vector DB (Pinecone/Weaviate) for this? Just retrieve relevant chunks and stick them in the prompt. Feels like you're reinventing the wheel here.
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.
Yes. That's a core use case. You can either use a separate tree or even nest contexts. It's very powerful for sub-agents like the one Claude Code has built in with the Explore and Task subagents
~20ms overhead. Built on Cloudflare's edge, so it's fast globally. The value isn't speed—it's that you stop rebuilding context infrastructure and get versioning/debugging for free.
This is really well thought out. The git-like versioning approach for memory artifacts is something I’ve been advocating for after spending way too much time debugging agent state issues.
I’ve been working on AI memory backends and context management myself and the core insight here — that context needs to be versionable and inspectable, not just a growing blob — is spot on.
Tried UltraContext in my project TruthKeeper and it clicked immediately. Being able to trace back why an agent “remembered” something wrong is a game changer for production debugging.
One thing I’d love to see: any thoughts on compression strategies for long-running agents? I’ve been experimenting with semantic compression to keep context windows manageable without losing critical information. Great work, will be following this closely.
For now, I’m intentionally keeping UltraContext as unopinionated as possible, since every application has different constraints and failure modes.
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.
Founder here. Happy to answer questions.
Quick backstory: every agent project I worked on, I spent more time on context infrastructure than the actual product. Same pattern—duct-tape a store, lose history, debug blind when things broke.
The "aha" was needing git semantics for a project where users wanted to edit messages while still being able to travel back. So that's what I built: immutable history, branch on change, rewind to any commit. But I didn't want to expose that complexity. So the API is just contexts and messages. Versioning happens automatically.
Still early. What context engineering problems are you hitting with your agents?
I don't get it. Why wouldn't I just use a Vector DB (Pinecone/Weaviate) for this? Just retrieve relevant chunks and stick them in the prompt. Feels like you're reinventing the wheel here.
Great question. They solve different problems.
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.
This may interesting for agent orchestration. Can I use it to make multiple agents interact and save this context as a separate tree?
Yes. That's a core use case. You can either use a separate tree or even nest contexts. It's very powerful for sub-agents like the one Claude Code has built in with the Explore and Task subagents
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.
Adding an API call between my Agent and the LLM seems like it would kill latency. How much overhead does this add vs just managing the list locally?
~20ms overhead. Built on Cloudflare's edge, so it's fast globally. The value isn't speed—it's that you stop rebuilding context infrastructure and get versioning/debugging for free.