The most direct path is through the VCT Launcher, the free desktop hub (Tauri 2) that manages installing and wiring up agents, skills, hooks, and MCP servers. The onboarding wizard detects your system, downloads the local AI models needed to generate embeddings, and starts the knowledge graph services.

git clone https://github.com/hotak92/vibecoded-orchestrator
cd vibecoded-orchestrator

If you prefer the manual route without the launcher, the GitHub repository includes the command-line install script. The launcher remains the fastest path if you don't want to manage containers and local models by hand.

Once the orchestrator is installed, register the folder of the project you want to work on. This step creates the .claude/ structure inside the project: this is where agents, skills, automation hooks, and the knowledge/ folder live, where the knowledge graph keeps its nodes as Markdown, not in a closed binary database.

The practical advantage of readable .md files: you can open them, edit them by hand, version them with git like any other project file. There's no proprietary storage to depend on.

With the Claude Code extension in VS Code (the primary target) or the standalone CLI, open the folder of the project you just registered. Agents, skills, and hooks are already active. From this point on, every time the AI writes a relevant architectural decision to a knowledge graph node, a PostToolUse hook intercepts the save, generates the embedding, and indexes it automatically within seconds. You don't call any "memory.add()" function by hand: it happens on its own when you write or edit a file inside knowledge/.

This is where the practical difference lies compared to leaving everything scattered across commits or code comments. When you make a decision you want to survive future sessions (why you chose JWT over sessions, why an endpoint is structured a certain way, which library you ruled out and why), write it as a knowledge node:

Authentication strategy
Chose short-lived JWTs with refresh tokens instead
of server-side sessions.
Why: the service needs to scale horizontally
without shared state between instances. Sessions
would require a centralized store (Redis), complexity
that isn't needed at the current volume.
Related to: [[uses::FastAPI]], [[extends::Base Auth Middleware]]

The double square brackets ([[uses::FastAPI]]) are typed wikilinks: they connect this node to other concepts in the graph, so a future search can trace not just the text but the relationships between decisions.

From here on, in a future session (even weeks later, even in a different project if you use the cross-project shared collection), instead of re-explaining the context you can simply ask. The agent queries the knowledge graph with a targeted question and gets back only the relevant nodes, not the entire project history:

What did we decide about the authentication strategy
and why?

The search (hybrid_search in VCO's case) combines semantic similarity with traversal of typed links: it doesn't just find text that resembles the question, it can follow the found node to connected concepts, for example reaching the middleware that depends on that choice.

With daily use, the graph grows alongside the project. A dedicated knowledge-curation agent (in VCO's case, called knowledge-curator) periodically reviews new nodes, proposes missing links between similar concepts, and flags content that's become outdated. It's not a step you run manually every week: it's meant to run in the background, so the cost of maintaining memory stays low even as the number of nodes grows.