ofabioroma

5 ms·

31.
by ofabioroma 9mo ago
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 writ
32.
by ofabioroma 9mo ago
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 yo
33.
by ofabioroma 9mo ago
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. Co
34.
by ofabioroma 9mo ago
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
35.
by ofabioroma 9mo ago
~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.
36.
by ofabioroma 9mo ago
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
37.
by ofabioroma 9mo ago
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
38.
Show HN: UltraContext – A simple context API for AI agents with auto-versioning(ultracontext.ai)
21 points by ofabioroma 9mo ago|21 comments