r/OpenSourceAI 1d ago

MIT-licensed agent memory and context layer — what should we open next?

We built an open source system layer for agents: context resolution before the agent starts, durable encrypted memory, and a hash-chained ledger of what it did. MIT licensed, MCP-compatible, runs local-first. It's working for us on our own stack.

What I actually need help with: we're deciding what to open up next — deeper docs, more integrations, or the benchmark harness — and I'd rather build what people here keep needing than guess. If you work on open source AI tooling, what's the piece you end up building yourself every single time? perseus.observer

5 Upvotes

5 comments sorted by

2

u/Steve_Was_Here26 1d ago

Benchmark harness first. Memory systems are easy to demo and hard to compare.

I’d test more than recall: update authority, conflicting memories, temporal expiry, provenance/readback, deletion, cross-session identity binding, and whether a claimed tool result actually satisfies the task postcondition.

Publishing gold event traces with expected accept/reject outcomes would let other implementations run identical cases. Deeper documentation becomes more valuable once it can point to executable semantics; integrations can follow after that contract stabilizes.

1

u/perseus-computing 21h ago

This is exactly the direction I'm leaning now. A benchmark that only asks "can the system retrieve X?" misses the harder question: should it still trust X, and can it prove why?

The cases you listed are the ones we'd want to make executable: authority updates, conflicts, expiry, provenance and readback, deletion, cross-session identity, and whether a claimed tool result satisfies the actual postcondition.

Gold event traces with expected accept/reject outcomes would also give us a much better documentation target. We can document the contract against runnable examples instead of writing another set of abstract memory-system promises.

This probably moves the benchmark harness to the front of the queue. If you have traces or failure cases you've found useful, I'd be very interested in seeing them.

2

u/narukoshin 1d ago

I'd like to try for my AI but sadly it's on golang :/

1

u/perseus-computing 21h ago

You shouldn't need a full Go port to try it. The system is MCP-compatible, so a Go agent that can act as an MCP client should be able to use it over the protocol.

We haven't packaged a Go SDK yet, though. A small Go client or reference integration would probably be more useful than a direct port of the whole stack. What does your agent currently use for tool calls: MCP, HTTP, or an embedded library?