Use LlamaIndex when data, retrieval, and agent workflows meet.
The agent inherits the quality of the index.
Learners place LlamaIndex around data-centric applications.
Why this matters: This avoids using agents to compensate for weak retrieval.
Problem anchor: a research assistant answers over product manuals, policy PDFs, and support tickets. The hard part is loading, parsing, indexing, retrieving, and citing data. LlamaIndex gives those steps first-class objects.
An agent can call query engines as tools, but the query engine must already retrieve useful source nodes. Tool orchestration cannot fix bad parsing.
One query engine covers product manuals and another covers release notes. The agent chooses which engine to query, then synthesizes an answer with source nodes.
If release note parsing drops version headings, the agent cannot recover that provenance later.
LlamaIndex agents can combine data tools with action tools.
Learners map query engines to agent tools.
Why this matters: A query tool and a side-effect tool need different policies.
A query engine tool should have a narrow name, description, and source scope: search_product_manual, search_release_notes, or search_policy. This helps the model choose the right evidence source.
Ordinary functions can also be tools, such as calculators or ticket lookups. Side-effecting tools need the same validation and approval discipline as any agent framework.
| Option | Tool | Use when | Risk | When to choose | Cost | Complexity |
|---|---|---|---|---|---|---|
| Query engine tool | Ask indexed data for cited evidence. | Answers depend on documents. | Bad nodes lead to weak citations. | Use for RAG-backed answers. | Medium | Medium |
| Function tool | Run calculation or API operation. | Task needs non-document action. | Side effects need policy. | Use with validation and approval. | Medium | Medium |
| All-purpose search | One broad tool for every corpus. | Rarely. | Model cannot choose source reliably. | Avoid for production teaching. | Low | Low |
Workflows organize event-driven data/agent processes.
Learners distinguish simple agents from workflow processes.
Why this matters: Some data tasks require explicit steps beyond one agent loop.
A document assistant may need to ingest a file, extract entities, query related notes, ask an agent to draft, and run a faithfulness check. A workflow gives that process named steps.
Use workflows when ordering, branching, or review matters. Use a simple query engine when the task is direct Q&A.
A support-ticket workflow extracts product/version, queries manuals and release notes, drafts a response, then verifies that cited source nodes support every claim.
Unsupported claims route to revision or refusal.
A LlamaIndex agent should expose the evidence path.
Learners see how data tools feed agent answers.
Why this matters: Source-node inspection catches weak retrieval before trust.
A minimal example should load documents, create an index, expose the query engine, and show the source nodes behind the response. The agent layer is only useful when evidence remains visible.
Spaced recall: from RAG faithfulness, final claims must map to retrieved context. LlamaIndex source nodes are the review surface.
from llama_index.core import Document, VectorStoreIndex manuals = [Document(text="Refund exceptions for enterprise plans require finance approval.", metadata={"source": "billing.md"})] index = VectorStoreIndex.from_documents(manuals) query_engine = index.as_query_engine(similarity_top_k=2) def search_billing_policy(question: str) -> str: response = query_engine.query(question) sources = [n.metadata.get("source") for n in response.source_nodes] return f"{response} Sources: {sources}" print(search_billing_policy("Who approves enterprise refund exceptions?"))
billing.md should appear because the document contains the finance-approval fact.
Data eval is the release gate.
Learners set production checks for LlamaIndex agents.
Why this matters: Agent workflows can amplify retrieval errors if not tested.
Evaluation should record question, expected source nodes, retrieved nodes, final answer, and claim support. Tool selection matters too: the model should choose manuals for policy questions and release notes for version questions.
Failure modes include bad parsing, wrong index, weak tool descriptions, overbroad query engines, missing refusal behavior, and source nodes that do not support claims.
Review answer, selected tool, and source nodes.
Retrieval prompt: reconstruct LlamaIndex agents by naming readers, nodes, indexes, retrievers, query engines, tools, FunctionAgent, workflows, and source-node evaluation.
Design a LlamaIndex research assistant with two query-engine tools, one calculator tool, source-node inspection, and a workflow step that refuses unsupported claims. Next rung: compare with LangChain and LangGraph.
A teammate suggests using LlamaIndex to build a customer-support agent that answers questions from a large internal knowledge base. Which property of LlamaIndex makes it the strongest fit for this use case?
LlamaIndex is data-centric: its document → node → index → query engine pipeline is specifically designed to make retrieval the first-class citizen, which is exactly what retrieval-heavy products need.
You are writing a tool description for a query engine that searches a product-returns policy document. Which description best guides the model to choose this tool correctly?
Tool descriptions should be specific about the data source and the kinds of questions it can answer so the model can reliably select the right tool — vague descriptions cause mis-routing.
Your LlamaIndex workflow must extract structured fields from uploaded contracts and then flag any missing fields for human review. Which workflow design is safest?
Separating extraction from review as distinct workflow steps — and surfacing data errors explicitly — keeps failures visible and debuggable instead of silently swallowed by the agent.
You have built a query-engine-backed agent with two tools: search_faq and search_pricing. A user asks "What is the refund window for annual plans?" After the agent responds, how would you inspect which tool was actually used and what source nodes it retrieved?
Inspecting the tool call log tells you which tool was selected, and examining the source nodes on the query engine's response confirms exactly which document chunks grounded the answer.
Before wiring a query engine into an agent, you run retrieval evaluation. Which combination of checks gives you the most complete picture of retrieval quality?
A complete retrieval evaluation covers source-node presence (did we retrieve the right chunk?), faithfulness (is the answer grounded in those chunks?), and no-answer behavior (does the agent abstain when it should?) — together these catch the most common failure modes before the agent goes live.