They already have. The tool is called bash and optimized api is grep, the storage is the file system. We’ve been here many months.

What people are exploring are other options as far as I can tell.

What you are offering is “don’t do that, this already works”. Which I guess is fine, but apparently not everyone is fully satisfied with the current generation of tooling.

▲

DarmokTanagra 4 hours ago | parent [-]

I was responding specifically to the parent comment that was suggesting generating ad-hoc sql.

Also fwiw grep is pretty poorly suited to semantic search and will only return the most basic of matches.

If you are really trying to build a useful memory search tool there are much better options than plain text search.

	▲	phoghed 3 hours ago \| parent [-]
		Yeah but probably the whole of the memories for any given project will likely fit into context, and the agent can’t extract whatever it wants for the given task. Grep only comes in if they choose to narrow down the candidate memory files, and they are usually searching many keywords and synonyms. Of course a real search system with ranking and whatnot would be better, but you’re paying a different cost there. I’m personally more interested in how the memory files get created and updated and generally managed, retrieving the correct ones doesn’t seem to be a big problem at the moment. I primarily use gh copilot and they are by default hidden from the user. It’s also not great that they aren’t in the repo and every contributor has their own set of memories of different freshness, likely conflicting.