Thanks, is the concern being non-starter on the trust side? the binary makes zero outbound calls. It talks to your bucket and nothing else, and that's verifiable with egress monitoring. I'm putting up a security page that spells it out.
Open-sourcing parts of it isn't off the table. I kept the core closed for now to understand the interest in it.
Harnesses are not a solved problem, yet. There are multiple kinds of memory that are user in them, conceptually. Working, Procedural, Semantic, etc. depending on harness design and architecture. Observe-modify is an integral part of harness development that continues to evolve and change, model to model.
Adoption of a system sans functional observability and mutation is of little utility. There's no reason to use a system that cannot be altered in design cycles (or larger model-release cycles), when memory systems aren't that complicated to begin with. RAG, Vector, simple KV, append-only buffers, are all in competition and used at different scales for good reasons.
The policy layer you’re describing lives in the harness, and yes, it changes over time. What I wanted to showcase is polign_db underneath with typed records, hybrid index, attached to your bucket. You can swap your memory design without migrating the storage or spawn nodes to access it quickly.
I see your point on observability. I haven’t baked it into polign yet, but I have been thinking about ‘how’ I would do it a very user friendly way. Glad to have a conversation about it.
So what's stopping me from using one of the million other versions of this that already exist? Or, even better, pointing Fable to your site and having it just develop its own version of this that I completely own?
I'm throwing in a bit of stank in those questions because I don't see anything here that's particularly unique, and keeping this closed and costly is just... absurd. I've vibe coded the same exact thing multiple times. It works, but it's only as useful as the philosophy of the person using it allows it to be.
So why would someone choose your solution? A vector database hosted in S3 is effectively trivial to set up at this point in time. What are you offering that I can't get from prompting a powerful enough model? If the answer to that question isn't the first thing people read when they open this post, then you can just consider all of this worthless and save yourself the hassle.
When I started, I was using what was available out in the world. The vector dbs I used and even the first version I built weren't really optimized to use RAM and resources conservatively. One of the aspects of Polign is it's optimized towards cold queries and only warms the cache when needed, all while keeping the recall accuracy in acceptable range. I accepted slower first-query latency on cold data as the tradeoff. For example, the demo serves 12.5 million passages from S3 with the server idling around 37 MiB RSS (I realized there is a 20 MB gcp sdk in there).
Hosted db have query costs that grow with the corpus, and self hosted have operational overheads. They do add up over time and I wanted cost flat, which took a while to get it right.
If a vibe-coded version covers your use case, you don't need this. I have added my own experience working and optimizing the storage into this, and Im certain it holds up well for a growing corpus and with simplicity to use it across multiple readers.
For a coding agent, just build an agent memory that is repo-aware and stores its files in respective repos. you can do this very quickly with any agent, just ask it to research memory systems like coala and propose an architecture
It's wordplay. I wanted it to be lightweight like pollen, but carrying all the information you need to build on top of it. The 'align' part nods to the core vector search aligning with your queries.
Thanks for taking a look. Yes, I kept it closed source for now. I'll mention that on the page.
Litestream with SQLite would solve some of these use cases, and backing up to S3 or GCS works well.
Here I was focused on more dynamic workloads. For example, larger indexes and corpus that can be accessed by multiple readers. I didn't want to invest in local storage, so the data is made to stay cold until it's actually accessed into warm cache.
Also, one node can serve all of that in one collection while serving typed agent memory in another.
Perhaps I missed something, but storage, memory, and operational overhead is something I wanted to worry less about.
There are countless agent memory stores today. Closed source is a non-starter.
Thanks, is the concern being non-starter on the trust side? the binary makes zero outbound calls. It talks to your bucket and nothing else, and that's verifiable with egress monitoring. I'm putting up a security page that spells it out.
Open-sourcing parts of it isn't off the table. I kept the core closed for now to understand the interest in it.
Harnesses are not a solved problem, yet. There are multiple kinds of memory that are user in them, conceptually. Working, Procedural, Semantic, etc. depending on harness design and architecture. Observe-modify is an integral part of harness development that continues to evolve and change, model to model.
Adoption of a system sans functional observability and mutation is of little utility. There's no reason to use a system that cannot be altered in design cycles (or larger model-release cycles), when memory systems aren't that complicated to begin with. RAG, Vector, simple KV, append-only buffers, are all in competition and used at different scales for good reasons.
The policy layer you’re describing lives in the harness, and yes, it changes over time. What I wanted to showcase is polign_db underneath with typed records, hybrid index, attached to your bucket. You can swap your memory design without migrating the storage or spawn nodes to access it quickly.
I see your point on observability. I haven’t baked it into polign yet, but I have been thinking about ‘how’ I would do it a very user friendly way. Glad to have a conversation about it.
So what's stopping me from using one of the million other versions of this that already exist? Or, even better, pointing Fable to your site and having it just develop its own version of this that I completely own?
I'm throwing in a bit of stank in those questions because I don't see anything here that's particularly unique, and keeping this closed and costly is just... absurd. I've vibe coded the same exact thing multiple times. It works, but it's only as useful as the philosophy of the person using it allows it to be.
So why would someone choose your solution? A vector database hosted in S3 is effectively trivial to set up at this point in time. What are you offering that I can't get from prompting a powerful enough model? If the answer to that question isn't the first thing people read when they open this post, then you can just consider all of this worthless and save yourself the hassle.
When I started, I was using what was available out in the world. The vector dbs I used and even the first version I built weren't really optimized to use RAM and resources conservatively. One of the aspects of Polign is it's optimized towards cold queries and only warms the cache when needed, all while keeping the recall accuracy in acceptable range. I accepted slower first-query latency on cold data as the tradeoff. For example, the demo serves 12.5 million passages from S3 with the server idling around 37 MiB RSS (I realized there is a 20 MB gcp sdk in there).
Hosted db have query costs that grow with the corpus, and self hosted have operational overheads. They do add up over time and I wanted cost flat, which took a while to get it right.
If a vibe-coded version covers your use case, you don't need this. I have added my own experience working and optimizing the storage into this, and Im certain it holds up well for a growing corpus and with simplicity to use it across multiple readers.
I get the closed source open binary approach - I would test it if I woild be in a need!
For a coding agent, just build an agent memory that is repo-aware and stores its files in respective repos. you can do this very quickly with any agent, just ask it to research memory systems like coala and propose an architecture
This looks promising! Curious why you named it `Polign`?
It's wordplay. I wanted it to be lightweight like pollen, but carrying all the information you need to build on top of it. The 'align' part nods to the core vector search aligning with your queries.
Closed source - for those who maybe miss this. litestream with sqlite vector based design would be more apt for someone.
Thanks for taking a look. Yes, I kept it closed source for now. I'll mention that on the page.
Litestream with SQLite would solve some of these use cases, and backing up to S3 or GCS works well.
Here I was focused on more dynamic workloads. For example, larger indexes and corpus that can be accessed by multiple readers. I didn't want to invest in local storage, so the data is made to stay cold until it's actually accessed into warm cache.
Also, one node can serve all of that in one collection while serving typed agent memory in another.
Perhaps I missed something, but storage, memory, and operational overhead is something I wanted to worry less about.