LlamaAgents

What does this agent do, and when should you use it?

LlamaAgents is an open-source Python framework for building and shipping document-centric agent applications. Its Agent Workflows core models execution as asynchronous steps that consume and emit events, with support for branching, loops, parallelism, persisted state, and failure recovery. A workflow can run inside a script or notebook, live within a FastAPI or Starlette application, or be exposed through llama-agents-server as a REST API with streaming, persistence, and human-in-the-loop support. llama-agents-client supplies the matching asynchronous client, while llamactl covers project initialization, local development, and deployment. Applications can be delivered to LlamaParse, AWS Bedrock AgentCore, or private infrastructure as headless workflow services, MCP servers, or full-stack applications.

Developers subclass Workflow and mark asynchronous Python functions with @step; each step consumes an event such as StartEvent and returns or emits another event such as StopEvent. Application code can connect OCR, model calls, structured extraction, classification, image analysis, custom validation, and human review, although those processing functions must come from user code or integrated services. The runtime coordinates branches, loops, parallel work, persisted execution state, and recovery from failures, then exposes outputs through values such as StopEvent.result. Workflows can execute in-process through await workflow.run(...), or be registered with WorkflowServer for REST access, streaming responses, persistence, and calls from llama-agents-client. The llamactl CLI initializes projects, runs local development with hot reload, and creates deployments targeting LlamaParse, AWS Bedrock AgentCore, or an organization's own infrastructure.

1. A document-processing team needs to coordinate OCR, extraction, classification, custom validation, and human review in one Python workflow.
2. A Python developer is proving a contract-processing flow in a notebook and wants the same workflow code to move into production later.
3. An enterprise processes high invoice volumes and must execute the application behind a customer's firewall or in another restricted environment.
4. A backend team wants to mount an asynchronous workflow in an existing FastAPI or Starlette application and expose it as a REST service.
5. An engineering team frequently revises extraction logic and needs persisted state and recovery to avoid restarting long-running document jobs.
6. An application team wants a CLI path from a starter project and local hot reload to deployment on LlamaParse, AWS Bedrock AgentCore, or private infrastructure.

How do you install or deploy this agent?

Install the core library mode with:

pip install llama-index-workflows

The supplied material identifies Python as the runtime but does not state a minimum Python version, virtual-environment procedure, or complete dependency matrix. No credentials are documented for a basic in-process workflow. Accounts, credentials, and configuration for LlamaParse, AWS Bedrock AgentCore, or other external services are not specified. To use the deployment CLI, install llamactl with:

uv tool install llamactl

How do you use this agent?

Define a minimal workflow:

from workflows import Workflow, step
from workflows.events import StartEvent, StopEvent

class HelloWorkflow(Workflow):
    @step
    async def greet(self, ev: StartEvent) -> StopEvent:
        return StopEvent(result=f"Hello, {ev.name}")

The documented in-process interface is await workflow.run(...), but the source does not supply a complete executable entry point or the exact event arguments for this example. To register the workflow with a server:

from llama_agents.server import WorkflowServer

server = WorkflowServer()
server.add_workflow("greet", HelloWorkflow())

The supplied material does not include the server launch command, port configuration, or a client request example. The documented llamactl flow is:

llamactl init
llamactl serve
llamactl deployments create

llamactl serve is described as supporting local development with hot reload; authentication and target-specific deployment configuration are not provided.

What are this agent's strengths and limitations?

How does this agent compare with similar options?

Key facts side by side with the most closely related agents.

How does FollowAgents rate this agent?

Recent releases

Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.

1. [email protected] 2026-10-23
   Release notes excerpt

   Patch Changes - 9bf7f4a: Release the chart whenever the operator, appserver, or control plane image it ships is bumped.

   View on GitHub ↗
2. [email protected] 2026-10-23
   Release notes excerpt

   Patch Changes - 64fbd6c: Builds link the UI output at /opt/app/.llama-ui so nginx serves the UI for pushed deployments. - 3ac8112: Keep UI directory redirects on the public host when serving built files behind a proxy.

   View on GitHub ↗
3. [email protected] 2026-10-23
   Release notes excerpt

   Patch Changes - 64fbd6c: Builds link the UI output at /opt/app/.llama-ui so nginx serves the UI for pushed deployments.

   View on GitHub ↗

FAQ