Examples Index

Purpose and Scope

The examples collection is the best next stop after a starter application because it shows LlamaIndex components in realistic combinations rather than in isolation. A starter example usually teaches the minimum loop: load data, build an index, ask a question, and inspect the response. The examples index expands that loop into families of use cases, including agents, agentic workflows, LLM integrations, RAG workflows, and connector-based data loading. Use this page as a learning map: choose the example family that matches the system you want to build, then cross-check the associated API reference when you need exact import paths and supported classes.

The official examples page frames the collection as a broad set of notebooks demonstrating use cases, integrations, and framework features. It calls out agent examples such as Function Calling Agent, ReAct Agent, Code Act Agent, and Multi-Agent Workflow, and it also points to workflow examples such as basic RAG and advanced text-to-SQL. For data-centric applications, the reader API reference files in this repository show how connector examples map back to importable reader packages. That mapping matters because most RAG examples begin by turning an external system into LlamaIndex documents before indexing or retrieval happens.

Sources: docs/api_reference/api_reference/readers/azstorage_blob.md, docs/api_reference/api_reference/readers/github.md, docs/api_reference/api_reference/readers/agent_search.md, docs/api_reference/api_reference/readers/airbyte_cdk.md, docs/api_reference/api_reference/readers/airbyte_gong.md, docs/api_reference/api_reference/readers/airbyte_hubspot.md

Recommended Learning Path

Start with examples that are closest to the starter application before jumping into specialized integrations. If you are learning RAG, begin with notebooks that show basic indexing and querying, then move to ingestion, metadata extraction, evaluation, and observability. If you are learning agents, start with a Function Calling Agent because it presents the clearest contract between an LLM, a tool schema, and an execution loop. After that, compare ReAct and CodeAct examples to understand how prompting strategy changes tool use while preserving the same high-level idea of an agent that reasons, calls tools, and returns an answer.

Once the basic patterns are familiar, use integration examples to replace toy inputs with real systems. Reader integrations are especially important because they define how data enters the application boundary. The targeted API reference pages document reader entry points for Azure Blob Storage, GitHub repositories, Agent Search, and Airbyte-backed sources such as CDK, Gong, and HubSpot. In practice, an example notebook might show credentials, loading calls, and downstream indexing, while the API reference confirms the public class name and module that should remain stable across examples and production code.

Reader Examples and API Mapping

A reader is a data-loading component that connects an external source to LlamaIndex. The reader pages in the API reference are generated around concrete modules and member lists, which makes them useful checkpoints while following examples. For example, the Azure Blob Storage reader page exposes llama_index.readers.azstorage_blob and the AzStorageBlobReader member. The GitHub reader page exposes llama_index.readers.github with repository-oriented readers for collaborators, issues, and general repository content. Airbyte pages expose separate reader classes for CDK, Gong, and HubSpot, which signals that Airbyte-backed examples may share a pattern while still using source-specific packages.

Example area	API module	Public members shown in the reference
Azure Blob Storage loading	`llama_index.readers.azstorage_blob`	`AzStorageBlobReader`
GitHub repository loading	`llama_index.readers.github`	`GitHubRepositoryCollaboratorsReader`, `GitHubRepositoryIssuesReader`, `GithubRepositoryReader`
Agent Search loading	`llama_index.readers.agent_search`	`AgentSearchReader`
Airbyte CDK loading	`llama_index.readers.airbyte_cdk`	`AirbyteCDKReader`
Airbyte Gong loading	`llama_index.readers.airbyte_gong`	`AirbyteGongReader`
Airbyte HubSpot loading	`llama_index.readers.airbyte_hubspot`	`AirbyteHubspotReader`

Treat this table as a bridge between notebooks and production code. Examples often prioritize a smooth narrative: create credentials, instantiate a reader, call a loading method, build an index, and query it. The API reference prioritizes stable names: module paths and exported classes. When an example is older than the package version you installed, the member list is the fastest way to verify that you are using the current reader class. When an example uses a high-level helper, the module page tells you which integration package owns the behavior and where to look for more detailed options.

Relevant Source Files

docs/api_reference/api_reference/readers/azstorage_blob.md: declares the Azure Blob Storage reader API page for llama_index.readers.azstorage_blob and the AzStorageBlobReader member.
docs/api_reference/api_reference/readers/github.md: declares the GitHub reader API page and lists repository, issue, and collaborator reader members.
docs/api_reference/api_reference/readers/agent_search.md: declares the Agent Search reader API page and the AgentSearchReader member.
docs/api_reference/api_reference/readers/airbyte_cdk.md: declares the Airbyte CDK reader API page and the AirbyteCDKReader member.
docs/api_reference/api_reference/readers/airbyte_gong.md: declares the Airbyte Gong reader API page and the AirbyteGongReader member.
docs/api_reference/api_reference/readers/airbyte_hubspot.md: declares the Airbyte HubSpot reader API page and the AirbyteHubspotReader member.

These files are compact, but they are still valuable because they encode the generated documentation contract. Each page uses a module directive and an explicit member list, so the documentation system knows which integration class belongs on the public reference page. For an examples index, that means connector examples are not just ad hoc notebooks; they correspond to documented reader surfaces. When you move from a notebook into an application, keep the example for task flow and use these API pages to confirm the precise integration class you should import.

How to Use the Examples Collection

A practical way to navigate the examples is to decide which layer of the application you are changing. If you are changing the data source, choose reader and ingestion examples first. If you are changing the reasoning loop, choose agent or workflow examples. If you are changing model behavior, choose LLM or embedding integration examples. If you are changing quality controls, choose evaluation and observability examples. This layered approach prevents a common mistake: copying a large notebook without knowing whether the important lesson is the connector, the index, the retriever, the agent loop, or the model configuration.

For connector-heavy examples, write down three facts before adapting the notebook: the external service, the reader class, and the downstream LlamaIndex primitive that consumes the loaded data. The source-backed reader classes on this page cover storage-backed loading, repository loading, search-backed loading, and Airbyte-backed business sources. After the reader returns documents, the rest of the example usually follows the same framework path as simpler tutorials: parse or chunk content, build an index, retrieve relevant context, synthesize a response, and optionally evaluate the result. That repetition is intentional because examples are meant to teach reusable composition patterns.

Your next step should be to choose one example family and read it with an API reference page open beside it. For a first production-style RAG path, start with a reader example that matches your data source, then continue to indexing, retrieval, and evaluation pages. For an assistant or automation path, start with a Function Calling Agent example, then add tools and workflow structure. When an example imports one of the reader classes listed here, use the matching API page to confirm the package boundary before pinning dependencies or writing deployment code.

Ask a question...