Knowledge Base

5 min read

Description

A knowledge base is any structured or semi-structured information surface an agent can query to support reasoning, planning, and execution.

A knowledge base is not one storage type. It is a retrieval-reasoning system that can range from markdown repositories to vector and graph-backed systems.

Core Framing

Knowledge base behavior sits on a continuum:

Focused retrieval for specific lookups
Exhaustive reasoning for cross-corpus synthesis
Hybrid routing that selects the right path per query

This reflects the RAG + RLM architecture model: retrieval and reasoning are complementary, not competing.

Knowledge as a Controlled Boundary

A task agent does not need direct access to an entire corpus or its storage credentials. A dedicated knowledge layer can own discovery, retrieval, grounding, and evidence packaging, then return only the context needed for the current task.

That boundary is also the natural place to enforce retrieval policy consistently. It can decide which collections may be searched, which schema or ontology applies, how much evidence is sufficient, whether provenance meets the required standard, and whether a result is too stale or sensitive to release.

Separating retrieval from task execution also allows each workload to use different infrastructure and models. A smaller or locally hosted model can perform extraction and retrieval while a more capable model handles planning or synthesis. This can reduce cost and limit how much of the source corpus enters an external model context, but it is not an automatic confidentiality guarantee. Authorization, redaction, collection-level policy, audit, and output controls remain necessary.

Source Artifacts and Derived Retrieval Surfaces

Documents, images, recordings, tables, and structured records should retain their identity as source artifacts. Transcripts, captions, chunks, embeddings, entities, and relationships are derived retrieval surfaces rather than replacements for the original evidence.

Keeping those layers linked allows an agent or reviewer to return to the source when extracted data is incomplete or disputed. It also makes deletion and reprocessing tractable: when a source changes, the system can identify the representations derived from it.

Ontologies can constrain which classes, properties, and relationships are extracted from unstructured evidence. They improve consistency and enable domain-specific queries, but introduce ownership, versioning, migration, and evaluation costs. A schema that is too loose provides little control; one that is too rigid can hide facts that do not fit its current vocabulary.

Provenance, Trust, and Grounding

Provenance should remain queryable alongside facts and retrieved context. A useful lineage chain can answer where a claim originated, which source fragment produced a relationship, which evidence grounded a response, and which retrieval path or model configuration participated.

The chain should also identify the human, agent, crawler, connector, or scheduled process that contributed the source, together with its authorization and collection time.

Provenance proves lineage, not truth. Confidence, recency, corroboration, source authority, and conflict resolution are separate judgments that a knowledge system must model or enforce.

Knowledge Lifecycle

A useful knowledge system cannot stop after its first import. Documentation changes, incidents invalidate assumptions, people move teams, and yesterday’s correct answer can become tomorrow’s context poisoning.

A complete lifecycle needs policies and automation for:

detecting changed, deleted, or superseded sources
retracting derived triples and embeddings when their source is removed
resolving contradictions between old and new evidence
attaching expiry, authority, and confidence to knowledge
measuring usage so low-value material can be archived or unloaded
compacting repeated evidence without destroying provenance
reprocessing knowledge when an ontology or extraction model changes
evaluating retrieval quality after every lifecycle operation

Ingestion is only the beginning. The harder problem is deciding what should no longer be believed and ensuring every derived representation follows the source through updates, replacement, and deletion.

Codebase Knowledge: Agentic Search vs RAG

The retrieval-reasoning spectrum above is about general corpora. Code is a special case, and the field has converged on a counter-intuitive default for it: agentic search (grep / glob / read on the live filesystem) beats embedding-based RAG for most coding tasks. Claude Code dropped its vector database for exactly this reason.

Why exact-symbol agentic search wins for code:

Freshness. An index is wrong the moment a file changes; grep reads current state. Decisive during active development.
Precision. Code symbols are exact a function name is present or it is not. Fuzzy vector matches inject “conceptually adjacent but textually unrelated” noise that rarely helps.
Security. No index means no extra attack surface; code embeddings can leak source via inversion attacks (see Security).
Simplicity. No vector DB, no sync pipeline, no staleness to manage.

Where a semantic or graph layer still earns its place added narrowly, not as the default:

Renamed symbols intent survives renames that break grep.
Unfamiliar codebases you cannot grep for a name you do not yet know; semantic search helps onboarding.
Structural queries “who calls X”, “where is this used”, cross-file data flow answered by a code knowledge graph (containment, call, import, inheritance, and data-flow edges keyed by qualified name), not by chunk retrieval.

A cheaper middle path is the repo map (Aider’s approach): a tree-sitter symbol graph ranked by PageRank and fitted to a token budget, deterministic, fresh, and far cheaper than embedding search for selecting what an agent sees. See Agent-Computer Interface for the repo map.

Default posture: use agentic grep/glob/read for precision and freshness with zero infrastructure; add a graph or semantic layer specifically for rename resilience, onboarding, and structural queries. Do not pre-index by default. The Adoption Sequence (retrieval first, route, then exhaustive reasoning) applies here too.

Context - Context density and discoverability constrain answer quality.
Smart Routing - Routing logic extends beyond model selection to retrieval strategy selection.
Execution Ledger - Routing decisions and outcomes should be logged for audit and optimization.

TrustGraph - Context graphs, GraphRAG, Ontology RAG, queryable provenance, Context Cores, and multimodal processing in one knowledge platform.