LlamaIndex Built the Data Framework for LLM Applications. The Data Objects Have No Agent Schema.
by Nick Clark | Published March 28, 2026
LlamaIndex has built one of the most capable data frameworks in the LLM application ecosystem. Its retrieval-augmented generation pipelines, query engines, and node parsers turn heterogeneous source material into LLM-accessible context with minimal ceremony. LlamaParse extracts structured content from PDFs, slide decks, and tables that defeat naive text extractors. LlamaHub assembles a connector catalog spanning hundreds of data sources. LlamaCloud productizes the indexing and parsing pipeline as a managed service. On top of this data substrate, LlamaIndex offers agentic workflows through AgentRunner and AgentWorker abstractions, letting developers compose agents that route queries across multiple tools and indexes. The framework excels at making data accessible to language models. But LlamaIndex agents are assembled from query engines, tools, and chat memory without a canonical schema; there is no structural definition of what an agent is beyond its accumulated components. The gap is between excellent data integration tooling and a canonical agent definition that makes agents validatable, governable, and interoperable.
What LlamaIndex actually delivers
LlamaIndex is best understood as a data framework first and an agent framework second. The core value is the pipeline that takes raw documents — PDFs, web pages, database rows, Slack threads, GitHub issues — and turns them into a vector index, a keyword index, a knowledge graph, or some composition of these, all queryable through a common Query Engine interface. The retrieval quality of these indexes, the flexibility of the node parsing, and the breadth of LlamaHub connectors are what make LlamaIndex a default choice for serious RAG work. LlamaParse extends the framework to documents whose structure resists ordinary extraction. LlamaCloud removes the operational burden of running indexing infrastructure in production.
The agent surface — AgentRunner driving an AgentWorker that selects among query-engine-backed tools — sits on top of this data substrate. It is genuinely useful: a developer can wrap several indexes as tools, hand them to an agent, and get reasonable multi-step retrieval behavior with very little code. The gap analyzed here does not contest the agent's capability. It concerns the absence of any canonical schema describing what an agent is, structurally, beyond the assemblage of components a particular developer happened to combine.
Agents assembled from components, not structurally defined
A LlamaIndex agent is, in practice, a Python object holding a language model, a list of QueryEngineTool or FunctionTool instances, an optional ChatMemoryBuffer, and a routing strategy implemented by an AgentWorker. The agent is capable. But it has no canonical schema. Two agents constructed by two teams in the same organization can present entirely different shapes: one carries memory and one does not, one exposes tool descriptions and one relies on convention, one tracks tool-invocation lineage and one discards it after each step. There is no required field for governance attestation, no typed identity that survives across sessions, no schema-enforced lineage record describing which tools an agent has actually consulted on behalf of which user. The agent is what its components happen to be.
This shapelessness is consistent with LlamaIndex's positioning as a flexible data framework rather than an agent platform. The cost shows up at the boundaries: an agent built in this style cannot be straightforwardly registered with a governance system that expects typed identity, cannot be validated against a schema by an external auditor, and cannot be safely interchanged with an agent built under a different framework that happens to expose the same tool surface. The agent is a snapshot of how someone wired components together on a particular afternoon, not an artifact whose structure is recoverable from inspection.
Chat memory without governed persistence
LlamaIndex provides chat memory modules — ChatMemoryBuffer, ChatSummaryMemoryBuffer, and the newer composable memory primitives — for maintaining conversation context across an agent's interactions. Memory is a useful feature, well-implemented within its scope. But it is an optional component, not a required typed field of any canonical agent definition. An agent can be constructed without memory, with a default buffer that silently truncates context, or with a custom memory implementation that has no relationship to the memory carried by another agent in the same system.
More importantly, the memory has no governance constraints attached at the schema level. There is no required record of which tenant the memory belongs to, no typed lineage describing which retrieval results contributed to which remembered turn, no structural relationship between the memory's contents and the agent's identity. It is a conversation buffer that happens to be persistent if the developer chose a persistent backend. It is not governed memory in the sense the agent-schema primitive requires: a typed, identity-bound, lineage-tracking field that an external system can inspect and reason about.
What a canonical agent schema provides
A canonical agent schema would give LlamaIndex agents the structural definition the current framework leaves to convention. Memory would be a required typed field with declared lineage and governance scope. Identity would be a typed field that persists across sessions and is verifiable against an external authority. Tool inventories would carry signed manifests describing which tools the agent is authorized to invoke under which conditions. Lineage records would capture, in a schema-defined way, which tool invocations contributed to which agent outputs. Governance would be intrinsic to the agent rather than glued on through wrapper classes.
The composition with LlamaIndex is natural. LlamaIndex's data integration continues to provide the retrieval capability — query engines, indexes, parsers, connectors — that the framework already does well. LlamaParse continues to handle the documents nothing else can. LlamaCloud continues to operate the pipeline. The schema sits at the agent layer, providing the structural definition that makes agents validatable, interoperable across frameworks, and governable by external systems. AgentRunner and AgentWorker become the runtime that drives schema-conformant agents rather than the place where the agent's shape is defined ad hoc. Developers gain a contract describing what an agent must be, beyond what its components happen to be, and the rest of the LlamaIndex stack becomes more valuable for being plugged into that contract.
