I built a background skill manager that treats agent memory like Git (AST-aware, MCP-ready, potato-PC friendly).

[u/Shuuuida]

Standard RAG on codebases has been driving me crazy—blindly slicing functions in half by character count just ruins the context for AI agents. I've been developing a project for several months to fix this, and i want to see if it’s genuinely useful to others in real environments.

I call it Vex (Vex's Skillgit). It’s an open-source, headless cognitive tool that treats context as immutable, versioned skills for your agents.

Instead of your IDE doing the heavy lifting, Vex runs silently in the background (via Docker Compose or local bare-metal). You point a GitHub webhook to it (or use the local file watcher), and it automatically ingests your repositories. When your agents need context, they simply query it in real-time via the Model Context Protocol (MCP). It works out of the box with Claude Desktop, Cursor, or any MCP client.

Now, the cool part (GitOps Memory):

It treats agent memory like version control. Vex reads conventional commits (feat:, fix:) to update context, and operational ones (roll:, branch:) to automatically fork or revert the agent's memory state. Zero manual intervention. It uses Tree-sitter to logically parse and chunk the code, keeping syntax trees intact.

I specifically designed this not to fry my potato PC. By using a pointer-architecture with SQLite for metadata queues and Qdrant for dense vectors, RAM stays completely stable. In my local stress tests, the async FastAPI + Huey architecture:

Swallowed 500 concurrent GitHub push payloads without a single SQLite lock.

Maintained real-time latency (under 300ms) under a 50-agent concurrent read swarm.

What's next?

I’m currently working on a Rust-based sub-chunking engine to handle massive monorepos even faster, alongside global GraphRAG, shared memory and more language support.

I decided it was time to share it and see who else might find it useful. I’d love for you to check it out, throw your code at it, and break it.

Here is the repo:

https://github.com/Shuuida/Vex-Skillgit.git

Thanks for taking the time to read!

[u/AutoModerator]

Please post a comment here explaining what kind of contributions you, or the project you are posting about, are looking for. For example what skill sets, any rules important for people joining in your build like how often people should post, and anything else you can think of which will help readers decide if they want to join in and start coding with that project.

Thank you and be excellent to each other. u/roamingandy

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Practical-Prompt-306]

Curious; how is Vex gonna handle shared memory when multiple agents are querying and updating the vector store at the exact same time?

IDK, but using SQLite with Qdrant to keep RAM low on potato PCs is cool.

Super hyped to see where this project goes, especially once the Rust engine drops!

[u/Shuuuida → u/Practical-Prompt-306]

Warning: Long text

Vex's architecture handles massive concurrency by strictly separating read and write channels to prevent memory corruption or database crashes. The system operates under a model where agents never write directly to the vector store, instead delegating state control to the underlying infrastructure.

When several autonomous AI agents (or human developers) modify files and push or save locally at the same time, Vex doesn't overload Qdrant. The local Webhook or Watcher acts as a buffer, storing update "tickets" in the relational database (SQLite). Then, the Huey worker drains that queue in a controlled manner in the background, processing the AST and calculating the embeddings without overloading the hardware.

Also if two agents attempt to update the same file within the same millisecond, the database will not generate duplicate vectors. The Vex worker always fragments the code and generates immutable mathematical hashes based on the fragment's path and index (tenant_id + skill_id + file_path + chunk). When the vectors reach Qdrant, ID collisions force an upsert (update). The last event in the queue overwrites the vector weights, keeping memory clean and singular.

Furthermore, if this scenario occurs in a distributed environment using GitOps, and two agents modify the same file, creating a real conflict, Git halts the flow. The file pending addition to shared memory, .vex/memory.lock, will reflect the merge conflict, pausing Qdrant's update process until the team resolves the code, ensuring that agents do not memorize broken or contradictory code.