What Goes Into an AI Agent Knowledge Base, and What Doesn't

Part of our complete guide to AI agent memory.

Dumping docs into a vector store isn't enough. A team shipped a support agent last week pointed at 8,000 help articles, 40,000 old tickets, and a customer database — similarity search, top-k retrieval, standard RAG stack. It worked for simple questions. It fell apart on anything that required connecting facts: "did this customer file a similar ticket before, and how did we resolve it?" Three documents mentioned the customer. The agent couldn't tell they were about the same person.

The fix is a different kind of storage. An AI agent knowledge base is a structured record of what an agent needs to reason — not a pile of pages it has to re-read every turn.

This post is about what actually goes into one. For the conceptual case behind it, see why memory alone isn't enough for reasoning agents; for the foundation work on graph storage itself, building blocks of knowledge graphs covers the primitives.

What counts as an AI agent knowledge base

A knowledge base for a human is usually a searchable pile of articles, optimized for browsing. A knowledge base for an AI agent is a different shape entirely: the agent doesn't browse, it asks questions with specific structure — "who resolved this," "what changed since last quarter," "which fixes applied to this customer" — and expects answers it can act on.

An AI agent knowledge base is a structured, queryable repository the agent uses to ground its reasoning: entities, relationships between them, and a history of how both change over time.

Two things matter in that definition. Structured means typed: a customer, an incident, a product are first-class objects, not chunks of text. We've covered the typed-vs-untyped distinction in structured vs. unstructured data. Over time means versioned — what was true last April isn't erased when the new version arrives, and both are queryable.

Three layers of content that actually belong in one

A useful agent knowledge base has three layers. Teams that skip one end up with agents that hallucinate, drift, or stop improving.

Reference data is the stable-ish structured record of your domain. Customer accounts, product catalogs, SKUs, known issues, org charts, schemas. This is what the agent consults to answer factual questions. It usually already lives somewhere — a relational database, a docs site, a spreadsheet. The job of the knowledge base is to turn that into entities and relationships the agent can traverse. We've shown the relational-to-graph path in relational database to knowledge graph with cognee + dlt and the document path in from data points to knowledge graphs.

Operational data is the running record of what the agent has seen, decided, or done. Past conversations, closed tickets, resolved incidents, code reviews, decisions. This is the institutional memory the agent can't afford to re-derive every session. Every production agent accumulates this data whether or not it's captured intentionally.

Feedback data is the quality signal. Which recalls helped, which hallucinated, which resolutions stuck. A knowledge base that doesn't capture this never improves — it just gets bigger. Feedback is the layer most "KB" products skip, and it's the one that separates a static lookup from a system that compounds.

Flat doc dump vs. structured KB

Take a real question: "Which known issue is this customer hitting, and has it been resolved for anyone else?"

The flat version works until the question requires stitching across sources; the structured version works because the stitching happened at ingest, not at query time. The same trade-off, viewed from the storage side, is laid out in vectors and graphs in practice.

How docs become a knowledge base

The ingestion step is where an agent KB earns its complexity.

  raw sources ──▶ Extract ──▶ Cognify ──▶ Load ──▶ hybrid store
    │                │           │          │          │
    docs, PDFs,    entities +  dedup +    graph DB +  agent
    transcripts,   relations   version    vector idx  queries
    SQL tables,
    code, emails

Extract. An LLM reads each source and pulls out entities and the relationships between them. A support ticket becomes a Customer node, an Incident node, a resolved_by edge to an Engineer node, plus the original text attached for provenance. A PDF becomes chapters, sections, and the concepts each one covers. A relational database becomes entities whose schema the KB learns from foreign keys. The full pipeline is documented in how cognee builds AI memory.

Cognify. The system reconciles what came out of extract. The same customer mentioned in five places is one node now. The three tickets about the same bug are one incident. Facts that changed get versioned rather than overwritten. Ontology validation is what makes the dedup reliable — we covered the mechanism in grounding AI memory with ontologies.

Load. The result is written into a graph store and a vector index at the same time. The graph is for traversal — "all incidents for this customer." The vector index is for fuzzy matching — "any ticket that feels like this one." Good retrieval uses both. Cognee's GraphRAG approach shows the hybrid retrieval in action.

Staying current

Static knowledge bases rot. Customers churn, products deprecate, docs get rewritten, incidents get reclassified, and an agent trained on a January snapshot will quote February facts with full confidence. The only fix is re-ingestion as a standing process: new tickets in the graph within hours, updated articles replacing old nodes without orphaning their edges, deleted records actually deleted. The operational layer changes fastest and is the hardest to keep fresh, which is also why it's the most valuable to capture — if you don't pipeline today's sessions into tomorrow's knowledge, the agent stays as smart as it was on day one.

Building one with cognee

Cognee's ingestion is the same handful of verbs regardless of source type.

import cognee

# Reference data: a PDF from your docs
await cognee.remember(open("product_manual.pdf", "rb"))

# Operational data: a ticket transcript from your support system
await cognee.remember(ticket_text, dataset_name="support_tickets")

# A relational source: cognee extracts entities from table rows and foreign keys
await cognee.remember(customer_db_rows, dataset_name="customers")

# Query the combined knowledge base. Pass session_id so the Q&A is
# captured to the session — that's what makes feedback attachable.
results = await cognee.recall(
    "Which known issue is Customer 9132 hitting, and has it been resolved before?",
    session_id="ops_session_42",
)

# Feedback: rate the answer the agent just gave. The signal lives
# alongside the Q&A and feeds back into ranking next time.
qas = await cognee.session.get_session(session_id="ops_session_42")
await cognee.session.add_feedback(
    session_id="ops_session_42",
    qa_id=qas[-1].qa_id,
    feedback_score=5,
    feedback_text="resolved on first try",
)

Each remember call runs the Extract → Cognify → Load pipeline against whatever you feed it; dataset_name separates concerns when you want them separate; recall auto-routes across graph traversal and vector search. The session API turns each Q&A into a feedback target, which is what makes the third architectural layer real rather than aspirational.

When a flat doc store is enough

Not every agent needs a structured KB. Single-turn FAQ bots over a static doc set are fine with plain vector RAG, and agents whose entire domain fits in a hundred documents probably won't see the payoff. Structured knowledge bases earn their complexity on systems where the data changes, the questions require traversal, or yesterday's agent decisions are worth recalling tomorrow — not on systems that have none of those.

Getting started

pip install cognee

Star cognee on GitHub and read the docs. For the concept of memory vs. knowledge, read about why memory alone isn't enough for reasoning agents. For the numbers behind structured-vs-chunk retrieval, the benchmarks post has the head-to-head data, and the underlying research is in the cognee paper on arxiv.

A knowledge base for humans is for browsing. A knowledge base for agents is for reasoning. Most teams shipping AI agents still have the first and wonder why the agent can't do the second.

---

FAQ

What is an AI agent knowledge base? A structured, queryable repository an AI agent uses to ground its reasoning. It stores entities (customers, products, incidents), relationships between them (resolved_by, depends_on), and versioned history of how both change. Unlike a human knowledge base, which is optimized for browsing, an agent knowledge base is optimized for traversal and typed retrieval.

How is an AI agent knowledge base different from RAG? RAG retrieves text chunks by similarity and passes them to the model. An agent knowledge base adds structure on top of retrieval — typed entities, relationships, versioned facts. A good agent KB uses RAG as one retrieval mode among several, not as the whole system.

What should I put in an AI agent knowledge base? Three layers. Reference data (your stable domain — accounts, products, schemas). Operational data (conversations, tickets, decisions the agent has made). Feedback data (which recalls were correct, which hallucinated). Systems that skip the feedback layer don't improve over time.

How do I keep an AI agent knowledge base current? Treat ingestion as a standing process, not a one-time load. New data should enter the graph within hours, updated data should replace old nodes without orphaning edges, deleted data should actually delete. Most "agent KB" failures are freshness failures.

Do I need a graph database for an AI agent knowledge base? You need structured representation — entities and relationships — which a graph database gives you cleanly. Cognee defaults to Kuzu (no setup), and supports Neo4j, Neptune, and Postgres when you want to scale. A flat vector store alone is not enough for multi-hop reasoning.

---

Last updated: January 2026.