Replies: 1 comment
|
Hello, thank you for your proposal. It is an honor to receive your interest in a sufficiently popular and excellent project. However, there are some differences between your project and ours. First, PM Soul is not a single architecture but a component of the entire architecture. Therefore, it is difficult to separate this one and operate it separately. Additionally, as I understand your company's project, it is as follows. Markdown (veritable) + SQLite (relationship) + LanceDB (vector) 3-tier stack We have an agent-based memory curator + project manager + evolving regulation that operates dynamically and is connected to an agent-based ontology chip. In particular, we honestly do not look for twists or turns of specific past events based on search results. The focus is on organizing and managing memory well. RAG and vector search technology level up over time, but our philosophy is that the rules and regulations should not change. We will soon publish the relevant benchmark results on Hugging Face. Thank you. |
Uh oh!
There was an error while loading. Please reload this page.
Hi Agentlas team, I’m one of the maintainers of EverOS at @EverMind-AI. The PM Soul boundary is close to a question we’re validating in EverOS: how much durable project memory should an orchestrator expose to specialists without letting handoff briefs grow into transcript-sized context?
Would you be open to a small public interoperability benchmark? We could define one synthetic four-week project with decisions, rejected options, one superseded fact, and two specialist handoffs, then run the same fixture against PM Soul and EverOS.
Proposed metrics: repeated-context events, stale-fact resurrection, handoff size, and decision recovery. We’d publish the fixture and raw results regardless of outcome.
All reactions