Core Concepts Primer
Purpose and Scope
LlamaIndex is a framework for building LLM-powered applications that need access to data outside the model’s pretraining set. The framework documentation describes it as a way to build agents over your data with LLMs and workflows, and frames the central problem as context augmentation: making private, domain-specific, or operational data available to an LLM at inference time. This page gives a conceptual map before you dive into APIs, tutorials, or integrations. It explains the common nouns used across the codebase and docs so that terms like loader, node, index, retriever, engine, agent, and workflow have a clear place in the overall system.
Sources: docs/src/content/docs/framework/index.md, llama-index-core/README.md
The core package is intentionally not the whole product surface. llama-index-core contains foundational abstractions for LLM applications, especially RAG, including LLMs, vector stores, embeddings, storage, callables, and other extension points. Real applications commonly combine that core with integration packages from the monorepo, such as model providers, readers, vector stores, callback integrations, or tools. This split matters because most concepts are defined in core, while many concrete production choices are supplied by integrations.
Sources: llama-index-core/README.md, docs/api_reference/api_reference/index.md
Relevant Source Files
README.md— identifies the repository as the LlamaIndex OSS project and anchors the top-level project context.llama-index-core/README.md— defines the core Python package as the home of foundational LLM application abstractions, including RAG, LLMs, vector stores, embeddings, storage, and callables.docs/src/content/docs/framework/index.md— provides the first-party framework overview for agents, workflows, context augmentation, data connectors, data indexes, and engines.docs/api_reference/api_reference/index.md— establishes the API reference as the navigation surface for modules and integrations used in the framework.
Core Primitives
The first primitive is the data connector, also called a reader in many guides. A connector loads information from its native place and format, such as APIs, PDFs, SQL databases, websites, or files. Loading does not by itself make the data useful to an LLM application; it brings external material into the application’s workflow so it can be normalized, chunked, indexed, stored, retrieved, and passed to a model. The framework overview explicitly lists data connectors as tools for ingesting existing data from native sources and formats.
Sources: docs/src/content/docs/framework/index.md
The second primitive is the Document/Node pair. A Document is a generic container around a source item, while a Node is a chunk derived from a document or otherwise constructed as a first-class unit for indexing and retrieval. The official guides describe documents as containers for text plus metadata and relationships, and nodes as chunks that can inherit metadata and relationships from source documents. In practice, this split lets you keep source-level identity while building retrieval-level units that are appropriately sized for embeddings, prompts, or storage.
Sources: llama-index-core/README.md, docs/src/content/docs/framework/index.md
The third primitive is the index. An index is an intermediate representation of data that is easier and more performant for LLMs to consume. In RAG, indexing often means producing vector embeddings, but the concept is broader than a single vector store. The framework overview names data indexes as structures for intermediate representations, and the core package README includes vector stores, embeddings, and storage among its foundational abstractions. Indexes are the bridge between raw loaded data and application-time retrieval behavior.
Sources: docs/src/content/docs/framework/index.md, llama-index-core/README.md
The fourth primitive is the engine. Engines expose natural-language access to indexed or otherwise prepared data. Query engines answer one-off questions, while chat engines maintain a conversational interface and may use memory or chat state. The framework overview groups engines under the tools LlamaIndex provides for context-augmented applications. Engines are important because they hide much of the orchestration between a user request, retrieval, prompt construction, LLM calls, and response assembly behind an application-facing interface.
Sources: docs/src/content/docs/framework/index.md
The fifth primitive is the agent, with workflows providing a related orchestration layer. The framework overview defines agents as LLM-powered knowledge assistants that use tools to perform tasks such as research and data extraction. Workflows are event-driven multi-step processes that can combine agents, data connectors, and tools into production-oriented applications. A RAG pipeline can be one tool available to an agent, rather than the entire application. That framing helps explain why LlamaIndex documentation covers both classic RAG and agentic systems.
Sources: docs/src/content/docs/framework/index.md
RAG Flow from Data to Answer
Retrieval-Augmented Generation, or RAG, is the most common context-augmentation pattern in LlamaIndex. The official docs describe RAG as adding your data to the data an LLM already has access to. The practical flow is: load data, parse it into documents and nodes, index the nodes, store the resulting structures, retrieve relevant context for a query, and synthesize a response with an LLM. Query engines, chat engines, and agents can all use this pattern, even when the end-user experience looks different.
Sources: docs/src/content/docs/framework/index.md, llama-index-core/README.md
A useful mental model is that indexing happens before the user asks a question, while retrieval and synthesis happen when the question arrives. During ingestion, readers and parsers prepare the application’s knowledge substrate. During querying, the user request is transformed into a search or retrieval operation over that substrate. Retrieved context is then combined with the user query and prompt instructions so the LLM can produce an answer grounded in the application’s data. This separation is why persistence and storage are first-class concerns: expensive ingestion and indexing should not have to run for every user request.
Sources: llama-index-core/README.md, docs/src/content/docs/framework/index.md
System-to-Code Mapping
| Concept | What it means | Where to look next |
|---|---|---|
| Core package | Foundational abstractions for LLM apps and RAG | llama-index-core/README.md |
| Framework overview | Reader-facing map of agents, workflows, context augmentation, connectors, indexes, and engines | docs/src/content/docs/framework/index.md |
| API reference | Generated/reference documentation for modules and integrations | docs/api_reference/api_reference/index.md |
| Integration ecosystem | Provider, reader, vector store, callback, tool, and utility packages used with core | llama-index-core/README.md |
The mapping is deliberately layered. Start with the framework overview to understand product-level intent, then use the core README to understand what belongs to the reusable Python foundation. When you need a concrete class, constructor, method, or integration package, move to the API reference. The API reference page itself is short, but it sets the expectation that LlamaIndex documents both framework modules and integrations, which is essential in a repository where the core package and integration packages evolve together.
Sources: docs/src/content/docs/framework/index.md, llama-index-core/README.md, docs/api_reference/api_reference/index.md
API Components and Extension Points
At the API level, the concepts become importable classes, protocols, and modules. Official examples show Document, VectorStoreIndex, and SentenceSplitter as common building blocks for creating documents, parsing them into nodes, and building a vector index. The core package README also names LLMs, vector stores, embeddings, storage, and callables as foundational abstractions. These are extension points: you can swap model providers, embedding models, storage backends, vector databases, tools, or callbacks while keeping the same conceptual flow.
Sources: llama-index-core/README.md, docs/api_reference/api_reference/index.md
The API reference should be used as a precision layer rather than a learning path. Once you understand that a query engine is an interface over retrieval and synthesis, the reference helps you find the exact class or method for a chosen index or integration. Once you understand that agents use tools, the reference helps you identify tool classes, callback managers, instrumentation types, and provider-specific packages. This separation keeps the conceptual model stable while allowing concrete implementations to vary by application requirements.
Sources: docs/api_reference/api_reference/index.md, llama-index-core/README.md
How to Read the Rest of the Wiki
If you are new to the framework, read installation and the starter example before trying to choose every component. Then use this concepts page as the glossary for deeper pages: Documents and Nodes for schema and parsing, Indexes and Vector Store Indexing for data structures, Retrievers and Query Engines for RAG execution, Chat Engines and Sessions for conversational state, and Agents, Tools, and Workflows for task-oriented orchestration. If you already have a production target, identify your required integrations early, because model, embedding, storage, and vector-store choices shape performance, cost, and deployment behavior.
Sources: docs/src/content/docs/framework/index.md, llama-index-core/README.md, docs/api_reference/api_reference/index.md