DSP (Data Structure Protocol): how to give LLM agents "long-term memory" of a large repository

There’s a pattern everyone who works with agents recognizes: the first 5–15 minutes are spent not on the task, but on “getting oriented.” Where is the entry point? Where do the dependencies come from? Why this library and not another one? Who considers this a public API? In a small project it’s annoying. In a large one, it becomes a constant tax on tokens and attention. DSP (Data Structure Protocol) “externalizes the project map” — into a simple, versioned, language-agnostic graph that lives alongside the code and is available to the agent as persistent memory. k-kolomeitsev/data-structure-protocol The goal is phrased in the architecture like this: 1) Goal and scope The goal of DSP is to store minimal, but sufficient context about a repository / artifact system as a graph “entities → dependencies / public API”, so that an LLM can: - quickly locate the necessary fragments by UID, - understand why entities exist and how they are connected, - avoid having to load the entire source tree in