Agents Overview

Purpose and Scope

Agents in LlamaIndex are LLM-powered systems that combine a model, memory, and tools to handle user input and decide what to do next. The deployment guide uses a narrower definition than the general word agentic: an agent is a concrete system with an LLM, memory, and tools, while agentic describes the broader class of software that includes LLM decision-making. This page orients developers to the first-party agent model, the workflow-based API surface, the basic execution loop, and how integration packages can provide specialized agents without abandoning the core workflow contract.

Sources: docs/src/content/docs/framework/module_guides/deploying/agents/index.mdx, docs/api_reference/api_reference/agent/index.md

Use this page when you need to decide which agent primitive to start from, how tools and memory fit into an agent run, or how representative integrations such as Azure Foundry Agent relate to core LlamaIndex. It is intentionally an overview rather than a full tools, memory, or workflow reference. After reading it, you should be able to recognize the main agent classes, understand the loop behind a tool-using call, and know which adjacent pages to open for configuration, tools, multi-agent orchestration, sessions, or streaming.

Relevant Source Files

• docs/api_reference/api_reference/agent/index.md - Declares the agent API reference entry point for llama_index.core.agent.workflow and lists the public workflow-agent members exposed in the generated docs.
• docs/src/content/docs/framework/module_guides/deploying/agents/index.mdx - Defines agents, shows a minimal FunctionAgent example, explains the tool-calling loop, and introduces tools, memory, multimodal inputs, and streaming behavior.
• llama-index-core/llama_index/core/agent/react/types.py - Provides the typed reasoning-step models used by ReAct agents, including action, observation, and response steps.
• llama-index-integrations/agent/llama-index-agent-azure/README.md - Documents the Azure Foundry Agent integration, its installation, prerequisites, stateful Azure resources, and compatibility with workflow-based orchestration.

Core Agent Primitives

The central workflow-agent API is documented under llama_index.core.agent.workflow. The reference page lists AgentWorkflow, BaseWorkflowAgent, FunctionAgent, ReActAgent, CodeActAgent, AgentInput, AgentStream, AgentOutput, ToolCall, and ToolCallResult. That list is useful because it separates agent implementations from the data structures that move through a run. FunctionAgent, ReActAgent, and CodeActAgent are concrete strategies; BaseWorkflowAgent and AgentWorkflow provide workflow-compatible structure; the input, output, stream, and tool-call types describe what an application can observe or compose.

Sources: docs/api_reference/api_reference/agent/index.md

FunctionAgent is the shortest path for most new agent applications when the selected LLM provider supports function or tool calling. The deployment guide constructs one with a Python function tool, an OpenAI LLM, and a system_prompt, then awaits agent.run(...). ReActAgent and CodeActAgent are presented as alternative agent types that use different prompting strategies to execute tools. In practice, this means the core decision is not whether an agent can use tools, but which execution strategy best matches the model, task, and level of control you need.

Sources: docs/src/content/docs/framework/module_guides/deploying/agents/index.mdx

Tools are the agent’s action surface. The deployment guide shows that a tool can be a plain Python function such as multiply(a: float, b: float) -> float, and it also points to richer classes such as FunctionTool and QueryEngineTool plus pre-defined Tool Specs. Memory is the state surface. By default, LlamaIndex agents use ChatMemoryBuffer, and the guide shows that you can construct a custom buffer with ChatMemoryBuffer.from_defaults(token_limit=40000) and pass it into agent.run(..., memory=memory). Together, tools determine what the agent can do, while memory determines what context it carries between turns.

Sources: docs/src/content/docs/framework/module_guides/deploying/agents/index.mdx

Execution Flow

A LlamaIndex agent run is a loop rather than a single model call. The guide describes the sequence as: get the latest message and chat history, send tool schemas and chat history to the API, receive either a direct answer or tool calls, execute every requested tool call, append tool results to chat history, and invoke the agent again. This repeats until the agent returns a direct response or the selected strategy concludes. Understanding that loop helps explain why good tool descriptions, bounded memory, and observable intermediate events matter in production systems.

Sources: docs/src/content/docs/framework/module_guides/deploying/agents/index.mdx

A minimal asynchronous agent shape looks like this:

import asyncio
from llama_index.core.agent.workflow import FunctionAgent
from llama_index.llms.openai import OpenAI
 
def multiply(a: float, b: float) -> float:
    '''Useful for multiplying two numbers.'''
    return a * b
 
agent = FunctionAgent(
    tools=[multiply],
    llm=OpenAI(model='gpt-4o-mini'),
    system_prompt='You are a helpful assistant that can multiply two numbers.',
)
 
async def main():
    response = await agent.run('What is 1234 * 4567?')
    print(str(response))
 
if __name__ == '__main__':
    asyncio.run(main())

The same execution model extends to multimodal inputs when the model supports them. The deployment guide uses ChatMessage with content blocks such as TextBlock and ImageBlock to send text and images to an agent for reasoning. That is important because the agent abstraction is not limited to plain strings; it can receive structured chat messages and still use tools. The guide also notes that streaming is enabled by default for FunctionAgent, but some models may not support streaming LLM output, so FunctionAgent(..., streaming=False) is the escape hatch when a provider raises a streaming-related error.

Sources: docs/src/content/docs/framework/module_guides/deploying/agents/index.mdx

ReAct Reasoning Model

ReAct agents expose a more explicit reasoning pattern in the core types. BaseReasoningStep defines the contract for a step: it must provide get_content() and an is_done property. ActionReasoningStep stores a thought, an action, and an action_input, renders those fields as a thought/action/action-input block, and is never done. ObservationReasoningStep stores an observation and can mark completion with return_direct. ResponseReasoningStep stores the final thought and response, supports a streaming display variant, and is always done.

Sources: llama-index-core/llama_index/core/agent/react/types.py

These types make the ReAct loop legible to developers. An action step is the agent deciding which external operation to call. An observation step records what came back from that operation. A response step is the final answer to the user, with special formatting when streaming has only produced the beginning of an answer. Even if you start with FunctionAgent, these classes are useful for understanding how LlamaIndex represents agent progress: tool-oriented agents do not simply produce text; they move through typed intermediate states that can be inspected, streamed, logged, or tested.

Sources: llama-index-core/llama_index/core/agent/react/types.py

Integration Agents and Azure Foundry

The agent API is also an extension point for integration packages. The Azure Foundry Agent README says that AzureFoundryAgent inherits BaseWorkflowAgent, which makes it compatible with workflow-based multi-agent orchestration. That inheritance detail matters: the integration can delegate agent execution to Azure AI Agent Service while still fitting the LlamaIndex workflow-agent family. Developers can use a managed Azure agent service for compute, storage, and scaling concerns while preserving the LlamaIndex pattern of tools, instructions, and agent.run(...). Sources: llama-index-integrations/agent/llama-index-agent-azure/README.md

The Azure integration has its own operational shape. It is installed with pip install llama-index-agent-azure, requires an Azure account and an Azure AI Project or Azure OpenAI compatible endpoint, and expects AZURE_PROJECT_ENDPOINT plus standard Azure authentication variables recognized by DefaultAzureCredential. Its example constructs AzureFoundryAgent with endpoint, model, name, instructions, verbose, tools, and run_retrieve_sleep_time. The README also warns that Azure agents and threads are stateful resources on Azure, so cleanup may need to happen through the Azure portal or SDK.

Sources: llama-index-integrations/agent/llama-index-agent-azure/README.md

from llama_index.agent.azure_foundry_agent import AzureFoundryAgent
 
agent = AzureFoundryAgent(
    endpoint=azure_project_endpoint,
    model='gpt-4o',
    name='my-azure-agent',
    instructions='You are a helpful assistant that can provide information and use tools.',
    verbose=True,
    tools=[get_weather],
    run_retrieve_sleep_time=2,
}
response = await agent.run('What is the capital of France and what is the weather there?')

Compact API Reference

Sources: docs/api_reference/api_reference/agent/index.md, llama-index-core/llama_index/core/agent/react/types.py, llama-index-integrations/agent/llama-index-agent-azure/README.md

Next Steps

Start with FunctionAgent when you need a practical tool-using assistant and your model provider supports function calling. Move to ReActAgent when you want the reasoning/action/observation pattern to be central to the agent’s behavior, or explore CodeActAgent for code-writing and execution workflows. If your application needs managed Azure agent infrastructure, install the Azure integration and treat Azure resource lifecycle as part of your deployment plan. For deeper implementation work, continue to the agent configuration, tools, sessions, streaming, workflows, and multi-agent workflow pages.