Storage and retrieval architectures

Our position. We treat a knowledge-graph schema as context architecture (opens in a new tab). Graph retrieval shows its path, which turns an answer you accept into one you can review, at the cost of an ingestion pipeline and entity resolution. That is worth paying when answers must be traceable, and overkill when a search box would do.

Which storage technology fits which context need?

The store follows the shape of the question: similarity, relevance, relationships, or working state. The “Domain Context Service” should not be a single monolithic service but a facade that intelligently routes requests to the appropriate backend—be it a search engine, a graph database, or another system—based on the metadata of the requested Context Product.

For Semantic Relevance: Vector Databases vs. Enterprise Search Engines

The rise of Retrieval-Augmented Generation (RAG) has been closely associated with vector databases. However, for enterprise use cases, a critical distinction must be made between finding documents based on semantic similarity and retrieving documents with the highest relevance to a user’s query (Coveo - Why Search Engines Outperform Vector Databases for RAG (opens in a new tab)).

Vector databases excel at similarity search. They embed text into a high-dimensional space and find the “nearest neighbors” to a query vector. This is powerful for finding conceptually related content but often fails when precision is required (Meilisearch - Why you shouldn’t use vector databases for RAG (opens in a new tab)). For example, a search for a specific error code or a product SKU may be poorly served by a pure vector search that returns conceptually similar but incorrect results.

True relevance in an enterprise context requires a hybrid search approach, which is a core competency of modern enterprise search engines. These systems combine multiple retrieval signals into a single, tunable ranking algorithm:

• Vector Search: To capture the semantic meaning and intent behind a query.
• Lexical Search (e.g., BM25): To provide high precision for keywords, exact phrases, and specific identifiers.
• Metadata Filtering: To narrow down results based on structured attributes like author, creation date, document type, or security tags.
• Tunable Ranking: To allow business logic to influence results, such as boosting official documentation over forum posts or prioritizing more recent documents.

Furthermore, enterprise search platforms are mature technologies built to handle large-scale, real-time indexing and updates, a domain where some vector-only databases can face challenges with cost and complexity when dealing with highly dynamic datasets (Coveo - Why Search Engines Outperform Vector Databases for RAG (opens in a new tab)).

For Relational Understanding: The Power of GraphRAG

For many complex questions, the answer is not contained within a single document but is synthesized from the relationships between multiple pieces of information. Standard RAG, which retrieves a list of independent text chunks, is poorly suited for these tasks. This is where knowledge graphs and the GraphRAG pattern provide a distinct advantage (DZone - Enhancing Code Analysis With Code Graphs (opens in a new tab)).

A knowledge graph stores information as a network of entities (nodes) and their relationships (edges). This structure is ideal for representing complex systems like codebases, organizational charts, or supply chains. The GraphRAG workflow fundamentally differs from standard RAG:

1. Anchor Node Identification: The user’s query is first used to find one or more starting points, or “anchor nodes,” within the graph. This initial step can itself use hybrid search on the properties of the nodes.
2. Graph Traversal: From these anchor nodes, the system programmatically traverses the graph, following specific relationship types to gather a rich, interconnected neighborhood of relevant context.
3. Subgraph Serialization: The resulting subgraph—not just a list of text snippets—is then serialized into a format the LLM can understand (e.g., text descriptions of the nodes and relationships) and included in the prompt.

This approach enables agents to answer multi-hop reasoning questions (Neo4j (opens in a new tab)). For instance, using the Code Knowledge Graph, a query like, “Which API endpoints are affected by the deprecation of the LegacyBilling class?” can be answered by finding the LegacyBilling node and traversing INHERITS_FROM, CALLS, and DEFINED_IN relationships to identify the connected functions and the files that expose them as API endpoints. Such a query is nearly impossible for a document-centric RAG system (DZone - Enhancing Code Analysis With Code Graphs (opens in a new tab)).

For Agent Memory: Version-Controlled Context in Git

For AI agents performing long-running, multi-step tasks, memory is not just a record of past conversations but a workspace for planning, execution, and reflection. Traditional agent memory is often ephemeral and unstructured (From Token Streams to Version Control: Git-Style Context Management for AI Agents (opens in a new tab)). A novel and powerful pattern for providing persistent, structured, and auditable agent memory is the Git-Context-Controller (GCC) (arXiv - Git Context Controller: Manage the Context of LLM-based Agents like Git (opens in a new tab)).

This pattern treats an agent’s memory as a Git repository, managed within a dedicated .GCC/ directory in the agent’s workspace. The structure is hierarchical and semantically meaningful:

• main.md: A file at the root that stores the agent’s high-level goal, plan, and to-do list.
• Branches: The agent can create branches (git branch explore-new-approach) to explore alternative strategies without corrupting its main line of reasoning. Failed experiments can be discarded, and successful ones can be merged back.
• Commits: The agent uses a COMMIT command to create atomic checkpoints of meaningful progress. Each commit has a message summarizing the achievement and is associated with detailed logs.
• log.md: Contains the fine-grained, step-by-step trace of the agent’s observations, thoughts, and actions (OTA).
• metadata.yaml: Stores structured information about the environment, such as file structures or dependencies.

The GCC pattern provides significant benefits for advanced agentic workflows. It enables milestone-based memory, allows for risk-free exploration of different solution paths, and creates a fully auditable history of the agent’s reasoning process. Crucially, it facilitates seamless collaboration and handover; a new agent (or even a different LLM) can take over a task by simply cloning the context repository and checking out the latest state (From Token Streams to Version Control: Git-Style Context Management for AI Agents (opens in a new tab)). This approach is highly complementary to managed memory services like Zep; GCC excels at providing auditable, versioned memory for complex, stateful tasks like code generation, while Zep is optimized for managing the dynamic, conversational context of user interactions.

---

Related

• Engineering context products: how the code knowledge graph and document indexes get built.
• Just-in-time retrieval: why coding agents often load data through tools instead of an index.
• Persistent agent memory: the forgetting problem every memory store has to solve.
• Governance and operations: how each store filters by role and stays fresh.

Resources

Articles

• Enhancing Code Analysis With Code Graphs (opens in a new tab) - DZone article on code knowledge graphs answering multi-hop impact questions that document-centric retrieval cannot.
• From Token Streams to Version Control: Git-Style Context Management for AI Agents (opens in a new tab) - Blog post explaining Git-style agent memory, with branches for exploration and commits for checkpoints that another agent can clone.
• How to improve multi-hop reasoning with knowledge graphs and LLMs (opens in a new tab) - Neo4j article on GraphRAG, traversing from anchor nodes to answer questions that span several connected facts.
• Why Search Engines Outperform Vector Databases for RAG (opens in a new tab) - Coveo article, from a search vendor, separating semantic similarity from relevance and arguing for hybrid enterprise search in RAG.
• Why you shouldn’t use vector databases for RAG (opens in a new tab) - Meilisearch article, from a search vendor, on where pure vector search fails at precision, such as error codes and SKUs.

Papers and reports

• Git Context Controller: Manage the Context of LLM-based Agents like Git (opens in a new tab) - arXiv paper introducing the Git-Context-Controller, which keeps agent memory as a repository with goals, branches, commits and logs.

Posts

• Context architecture (opens in a new tab) - LinkedIn post treating a knowledge-graph schema as context architecture, worth its ingestion cost where answers must be traceable.