Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
 [flagged] Show HN: UltraContext – A simple context API for AI agents with auto-versioning (ultracontext.ai)
21 points by ofabioroma 14 days ago | hide | past | favorite | 21 comments
Hey HN! I'm Fabio and I built UltraContext, a simple context API for AI agents with automatic versioning.

After two years building AI agents in production, I experienced firsthand how frustrating it is to manage context at scale. Storing messages, iterating system prompts, debugging behavior and multi-agent patterns—all while keeping track of everything without breaking anything. It was driving me insane.

So I built UltraContext. The mental model is git for context:

- Updates and deletes automatically create versions (history is never lost)

- Replay state at any point

The API is 5 methods:

  uc.create()   // new context (can fork from existing)
  uc.append()   // add message
  uc.get()      // retrieve by version, timestamp, or index
  uc.update()   // edit message → creates version
  uc.delete()   // remove message → creates version
Messages are schema-free. Store conversation history, tool calls, system prompts—whatever shape you need. Pass it straight to your LLM using any framework you'd like.

What it's for:

- Persisting conversation state across sessions

- Debugging agent behavior (rewind to decision point)

- Forking contexts to test different flows

- Audit trails without building audit infrastructure

- Multi-agent and sub-agent patterns

What it's NOT:

- Not a memory/RAG system (no semantic search)

- Not a vector database

- Not an Orchestration/LLM framework

UltraContext handles versioning, branching, history. You get time-travel with one line.

Docs: https://ultracontext.ai/docs

Early access: https://ultracontext.ai

Would love feedback! Especially from anyone who's rolled their own context engineering and can tell me what I'm missing.



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 compression and long-running agents, may I suggest https://memtree.dev. We offer a simple API that compresses messages asynchronously for instant responses and small context leading to much higher quality generations. We're about to release a dashboard that will show you what each compressed request looked like, the token distribution between system, memory, and tool messages, along with memory retrievals, etc... Is this the type of thing that you're looking for?


Something like this needs to be open-sourced. You're going to have a hell of a time trying to get enough trust from people to run all of their prompts through your servers.

reply


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?


What about context loaded in from tool calls?


You can load context from wherever you want (including inside other contexts and/or external tools), just uc.get() your way into the context. You can use metadata to filter your tool calls. You pick whatever structure works best for you. UltraContext is just the building blocks for your app! What are you building?


[under-the-rug stub]

[see https://news.ycombinator.com/item?id=45988611 for explanation]


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!


Great 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.


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.


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.


i've always wondered (for this, portkey, etc) - why not have a parallel option that fires an extra request instead of mitm the llm call?


You can fire them in parallel for simple cases. The issue is when you have multi-agent setups. If context isn't persisted before a sub-agent reads it, you get stale state. Single source of truth matters when agents are reading and writing to the same context.

For single-agent flows, parallel works fine.


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.


Lots of comments here from new accounts.


What about privacy does this imply storing messages in your layer?


Yes, messages are stored on our infrastructure

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: