| Many interesting ideas in there. To move forward, I suggest thinking less about the implementation details and more about the concepts around your approach in this system. For example a database storing files accessible remotely by multiple users is really a file server and can be implemented in multiple ways. And that's not the problem you're trying to solve here. Depending on where your sandboxes live, a bind or network mount and a gitwatcher outside of the sandbox would accomplish something very similar with less customization. You mentioned not having a solution for concurrency. So think about that first, without limiting yourself to a single implementation. Maybe the storage should not be per file, but be a knowledge graph that is presented as a file to the LLM in the sandbox. Concurrent mutations in knowledge graphs may be easier to solve, especially with the help of LLMs. Or perhaps it starts to work well already by simply showing the git merge conflicts to an LLM and having it reconcile the separate writes. Maybe even let it "post feedback" to the LLMs in the container, when a concurrent write has happened to a memory or skill to tell it "hey while you were working I also learned this potentially related update". |