When to use it
==============

``cognee-agensgraph`` is for teams that want an **AI-memory layer** — ``add`` data, ``cognify``
it into a knowledge graph plus embeddings, then ``search`` it many ways — backed by AgensGraph.

**Good fits**

- **Persistent agent memory.** Give an assistant a memory it builds up over time from mixed
  sources and recalls on demand.
- **One memory, many query styles.** Answer the same memory with graph-grounded completion,
  chain-of-thought reasoning, plain vector RAG, raw entity-relation triplets, document
  summaries, natural-language → Cypher, or hand-written Cypher.
- **Domain-aligned graphs.** Supply an ontology so extraction follows your own vocabulary
  (``EntityType`` nodes and ``ontology_valid`` flags), keeping the graph consistent with your
  domain.
- **Code knowledge graphs.** Turn a Python repository into a graph of modules, classes, and
  functions and search it with ``SearchType.CODE``.
- **Inspecting and visualizing.** Read the graph directly through ``get_graph_engine()`` —
  metrics, traversal, raw Cypher — or render it to an interactive HTML file.

**How it compares**

- Pick **cognee** when you want a memory layer with many ways to query and inspect it, plus
  ontology-typed extraction and code graphs.
- Pick **LightRAG** if your focus is document graph RAG with dual-level retrieval and
  multi-tenancy.
- Pick **LangChain** or **LlamaIndex** when you want to assemble retrieval inside one of those
  frameworks.

**Consider an alternative when**

- You want an agent to use AgensGraph directly through tools — use the **MCP servers**.
- You need fine-grained control over chunking, extraction, and retrieval — a framework build
  gives you more control.