Tested with Agno 3.0.10 · Python 3.14 · Ollama 0.34.1 · LangGraph 1.2.11 · verified

Updated: 2026-09-16

Agno is a Python framework for building AI agents whose main selling point is performance. In our test with version 3.0.10, creating an agent took about 4 microseconds and 5.5 KiB of memory. It was formerly called Phidata and, in January 2025, was renamed to Agno. Version 3.0, released on 24 August 2026, breaks compatibility with 2.x and requires a database migration.

In this guide you will see what Agno is and how it organises work into agents, teams and workflows. You will also see how much an agent really weighs, a tools example tested against a local model, how to migrate from 2.x to 3.x and how Agno differs from CrewAI. The same explanation is available in Spanish.

Key takeaways

  • Agno is an open-source agent framework (Apache-2.0 licence) written in Python; it has over 42,200 stars on GitHub and is on version 3.0.10, released on 16 September 2026.
  • Version 3.0.0 (24 August 2026) brings breaking changes: runs move to their own table, you must run MigrationManager(db).up() before serving traffic, and parameters such as enable_user_memories and reasoning=True are gone.
  • It was formerly called Phidata: the project was renamed to Agno in January 2025 and the GitHub organisation moved to agno-agi, so tutorials written before that date still cite the old name.
  • Its flagship trait is performance: we measured 3.9 microseconds and 5.5 KiB per agent, and about 200 times less time than LangGraph to create an agent with one tool.
  • It organises work into three pieces: individual agents, teams of agents that collaborate with each other and deterministic step-based workflows, all served by its AgentOS runtime.
  • It is model-agnostic: its documentation lists 51 provider guides (OpenAI, Anthropic, Gemini, DeepSeek, Mistral, Groq, Bedrock and models you run on your own machine with Ollama), and its PyPI metadata requires Python 3.9 or higher.

What is Agno (formerly Phidata)?

Agno is a framework and a runtime for AI agent platforms. It started life as Phidata, a more data-oriented tool, and in January 2025 was renamed to Agno; the GitHub organisation moved to agno-agi and the PyPI package became agno. Version 2 rewrote the core to cut framework overhead to the minimum. Version 3.0 changed storage: each run is now a row in the agno_runs table instead of a JSON blob inside the session.

The project is free software under the Apache-2.0 licence and holds more than 42,200 stars on GitHub. The latest release is 3.0.10, published on 16 September 2026; we tested it with Python 3.14.7. It installs with pip, together with the packages this guide’s example uses:

pip install -U agno

# Ollama client and web search used by the example
pip install -U openai ollama ddgs

# Only if you will serve agents with AgentOS
pip install -U "agno[os]"

You need the openai package even if you use Ollama: in 3.0.10, from agno.models.ollama import Ollama fails with ImportError when it is missing, because the Ollama module imports the OpenAI one. The os extra adds FastAPI, Uvicorn and the rest of the server dependencies.

Its GitHub README describes it as "a framework and runtime for agent platforms": you not only write agents, you also deploy them as a service and manage them from a web interface. That product-minded ambition sets it apart from other libraries that stop at the code layer.

Agents, teams and workflows

Agno organises work into three abstractions worth understanding from the start. An agent is the basic unit: a model with instructions, tools and, optionally, memory and knowledge. It is what you use for one-off tasks.

When a problem calls for more than one speciality, you assemble a team (Team): agents that collaborate and split the work, an approach similar to the one popularised by CrewAI with its agent crews. And when you need a repeatable, predictable process, you define a workflow (Workflow): a sequence of steps where each step’s output feeds the next, with state persisted between runs. Unlike an agent, which decides on the fly, a workflow is deterministic and auditable. In 3.0, Workflow only accepts keyword arguments, while Team([agent_1, agent_2]) works as before.

Above the three sits AgentOS, the runtime that serves agents, teams and workflows as production APIs. It is stateless and horizontally scalable: state (the sessions) is stored in a database you control, not in the process. It also ships a web interface to observe and manage the platform. If you come from the state graphs of LangGraph, you will recognise the idea of separating agent logic from deployment.

Version 3.0 adds a queue for background runs to AgentOS, capped at 32 concurrent runs per replica. With QueueConfig(durable=True), every request is stored in the database and survives restarts and deploys.

Performance and low memory use

Agno gets noticed for how little it costs to create an agent, and we measured it with 3.0.10. Its PerformanceEval tool creates the agent one thousand times and measures memory with tracemalloc, subtracting what an empty function uses:

from agno.agent import Agent
from agno.eval.performance import PerformanceEval


def create_agent():
    return Agent(system_message="Be concise, reply with one sentence.")


evaluation = PerformanceEval(func=create_agent, num_iterations=1000)
evaluation.run(print_summary=True)

On our machine (arm64, 18 cores, no GPU and a load average of 0.9), the output was this:

             Performance Summary
┏━━━━━━━━━━━┳━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┓
┃ Metric    ┃ Time (seconds) ┃ Memory (MiB) ┃
┡━━━━━━━━━━━╇━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━┩
│ Average   │ 0.000004       │ 0.005354     │
│ Minimum   │ 0.000004       │ 0.005249     │
│ Maximum   │ 0.000023       │ 0.005356     │
│ Std Dev   │ 0.000001       │ 0.000013     │
│ Median    │ 0.000004       │ 0.005356     │
│ 95th %ile │ 0.000004       │ 0.005356     │
└───────────┴────────────────┴──────────────┘

Across three repetitions, the average was 3.9 microseconds and 5.5 KiB per agent; with WebSearchTools, the median time rose to 16 microseconds and average memory to 12 KiB.

Agno no longer publishes comparisons in its README. The last one (v2.4.0, October 2025) gave Agno 3 microseconds and 6.6 KiB against 1,587 microseconds and 161 KiB for LangGraph. The "10,000 times faster" this guide used to quote came from 1.2.0, from March 2025.

With the repository’s comparison script, which creates an agent with one tool, Agno 3.0.10 took between 6.0 and 7.1 microseconds and used 7.5 KiB. LangGraph 1.2.11 took between 1.29 and 1.43 ms and used 153 KiB, about 200 times more time and 20 times more memory. We ran three repetitions at a load average of 5 to 6, and LangChain demands a dummy key in OPENAI_API_KEY even though it never calls the model.

It is worth understanding exactly what those figures measure: the framework overhead, that is, the time and memory it costs to set up the agent before calling the model. In a real request, latency is dominated by the language-model call. In the example in the next section, the answer took 16.3 s with a local 4B model on CPU.

Where the saving does count is concurrency. Picture a service that spins up thousands of agents per second, one per user request, say. There a startup cost of microseconds and a few KiB per agent make the difference between a comfortable server and one that chokes. For an agent you run occasionally, the difference is imperceptible; for a large-scale multi-tenant platform, it is exactly what you need.

A worked tools example

A useful agent needs to act on the world, and in Agno you do that by passing it tools: Python functions, or ready-made kits from its catalogue of over one hundred integrations. The following example creates an agent with a local model served by Ollama and the WebSearchTools web-search toolkit, and asks it for a summary with sources. First, download the model with ollama pull qwen3.5:4b (3.4 GB):

from agno.agent import Agent
from agno.models.ollama import Ollama
from agno.tools.websearch import WebSearchTools

agent = Agent(
    model=Ollama(id="qwen3.5:4b"),
    tools=[WebSearchTools()],
    instructions="Always cite your sources.",
    markdown=True,
)

agent.print_response(
    "Search what the Agno framework is and sum it up in two sentences",
    stream=True,
)

Agno connects to Ollama at localhost:11434, or at the address in the OLLAMA_HOST variable. This is the real output with Agno 3.0.10 and Ollama 0.34.1, on CPU:

┏━ Message ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃                                                              ┃
┃ Search what the Agno framework is and sum it up in two       ┃
┃ sentences                                                    ┃
┃                                                              ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
┏━ Tool Calls ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃                                                              ┃
┃ • web_search(query=Agno framework, max_results=5)            ┃
┃                                                              ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
┏━ Response (18.2s) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃                                                              ┃
┃ Agno is an open-source, model-agnostic agent framework       ┃
┃ designed to help developers build composable and Pythonic    ┃
┃ agentic applications with built-in support for tools,        ┃
┃ memory, and reasoning capabilities. It focuses on            ┃
┃ performance and minimalism while enabling multimodal         ┃
┃ tasks—such as handling text, images, audio, and              ┃
┃ video—natively.                                              ┃
┃                                                              ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

The model decides for itself when to search, and in this run it searched but ignored the instruction to cite sources. Across five runs with the Spanish prompt, qwen3.5:4b always searched and took between 16 and 37 s, but gave links in only three. Check the sources either way: in one Spanish run it cited third-party pages rather than the official docs. With qwen2.5:3b each answer took under 7 s, but the model skipped one search and never gave links.

In 3.0, DuckDuckGoTools wraps WebSearchTools and its functions are now called web_search and search_news. During the test, the DuckDuckGo backend stopped returning results (DDGSException: No results found.), while WebSearchTools, which picks the backend automatically and is the one the documentation recommends, kept working.

To switch provider, replace Ollama with OpenAIResponses, Claude or Gemini, or use the short form model="ollama:qwen3.5:4b"; we did not test the variants that need an API key. In the test we added options={"num_thread": 6} because the machine was shared: with the default 18 threads, qwen2.5:3b generated 0.1 tokens per second, and with 6, 80.

How to migrate from Agno 2 to Agno 3

The 3.0.0 release notes require migrating the database before 3.0 serves traffic. Take a backup, stop the processes that write to it, upgrade with pip install -U agno and run the migration with your application’s database configuration:

import asyncio

from agno.db.migrations.manager import MigrationManager
from agno.db.sqlite import SqliteDb

db = SqliteDb(db_file="agent.db")
asyncio.run(MigrationManager(db).up())
print(len(db.get_runs(session_id="demo")), "runs in agno_runs")

We tested it with a SQLite database where Agno 2.7.3 had stored a two-turn session. This is an excerpt of the output with 3.0.10:

INFO    Applying migration 3.0.0 on agno_sessions
INFO    -- Copied 2 runs from agno_sessions into the runs table
INFO    Successfully applied migration 3.0.0 on table agno_sessions
2 runs in agno_runs

The migration copied both runs into agno_runs and kept the old runs column; running it again changed nothing. Version 3.0.10 could already read the session before migrating, but the official guide still requires the migration. Once you have verified the history, db.cleanup_legacy_runs_column() drops the old column, an optional and irreversible step.

In the code, check these changes:

  • enable_user_memories: now update_memory_on_run
  • search_session_history and num_history_sessions: now search_past_sessions and num_past_sessions_to_search
  • reasoning=True: removed; pass a reasoning model in reasoning_model
  • Workflow("my-workflow", ...): the constructor only takes keyword arguments, so write Workflow(id="my-workflow", ...)
  • DuckDuckGoTools.duckduckgo_search and duckduckgo_news: now web_search and search_news

Old names fail at startup: 3.0.10 raises TypeError: Agent.__init__() got an unexpected keyword argument 'enable_user_memories'. If you keep per-user knowledge in a vector database created before 3.0, also run the matching script from libs/agno/migrations/v2_to_v3. The migration guide lists the remaining changes, such as the removal of MultiMCPTools.

Agno versus CrewAI

The natural comparison is with CrewAI, another Python framework focused on agent teams. The difference in approach is clear. CrewAI is built around the "crew" metaphor: you define roles, tasks and a crew that collaborates, with a guided experience.

Agno is more generalist and puts performance and production deployment at the centre. It covers everything from the single agent to the deterministic workflow, and tops it off with AgentOS to deploy it as a service.

If your case is a multi-agent system with well-defined roles and you want a gentle learning curve, CrewAI fits well. If you care about massive concurrency, low memory use and having a production runtime from day one, Agno has the edge. They are not mutually exclusive: both are model-agnostic and you can prototype in one and migrate if your needs change. For lighter, code-focused tasks, it is also worth looking at Hugging Face smolagents, which bets on a minimal surface.

How we tested this guide

On 16 September 2026 we ran the examples in Docker containers on an arm64 machine with 18 cores and no GPU. We used Python 3.14.7, Agno 3.0.10, LangGraph 1.2.11 and Ollama 0.34.1 with qwen3.5:4b and qwen2.5:3b. The migrated database was created with Agno 2.7.3. The models were already on the machine, so ollama pull did not run, and we did not test the providers that need an API key or the AgentOS server.

Frequently asked questions

Is Agno the same as Phidata?

Yes, it is the same project under a new name. Phidata was renamed to Agno in January 2025 and its GitHub organisation moved to agno-agi. If you find tutorials or dependencies mentioning phidata, they refer to the old version; active development is in the agno package, which is on version 3.0.10. The documentation has migration guides to 2.0 and to 3.0.

Is it really 10,000 times faster than LangGraph?

No: that figure came from the version 1.2.0 README and only measured framework overhead when creating the agent. With Agno 3.0.10 and LangGraph 1.2.11, creating an agent with one tool took us 6 microseconds against 1.3 ms and 7.5 KiB against 153 KiB. That does not speed up answers, because latency is dominated by the model call, which took 16.3 s in our local example. Where it does matter is concurrency: with thousands of agents at once, you save about 145 KiB per agent.

Which models does Agno work with?

Its documentation lists 51 provider guides that share the same API: OpenAI, Anthropic, Google Gemini, DeepSeek, Mistral, Groq, Amazon Bedrock, Azure OpenAI and the LiteLLM gateway, among others. It also works with models you run on your own machine with Ollama, vLLM or LM Studio. Switching from one to another is a matter of replacing the model class, without rewriting the agent logic.

What do I need to change to move from Agno 2 to Agno 3?

Back up the database, upgrade with pip install -U agno and run asyncio.run(MigrationManager(db).up()) before serving traffic. Then rename the removed parameters (for example, enable_user_memories becomes update_memory_on_run), replace reasoning=True with reasoning_model and use keyword arguments in Workflow; 3.0 raises TypeError on the old names.

Conclusion

Agno brings an unusual obsession to the world of AI agents: efficiency. It offers a microsecond startup, a few KiB per agent and three clear abstractions (agents, teams and workflows) served by AgentOS.

It fits beautifully when you need to scale to heavy concurrency without giving up on going to production. Remember that its performance edge, around 200 times in our measurement and not 10,000, refers to framework overhead, not real latency. The next step is to install it with pip install -U agno, write your first agent with a tool and, if you come from 2.x, migrate the database before deploying. Then compare it with CrewAI to decide which fits your project best.

Sources

  1. Official Agno documentation
  2. Agno on GitHub
  3. Agno 3.0.0 release notes
  4. Agno 3.0.10 release notes
  5. Official Agno 3.0 migration guide
  6. agno package metadata on PyPI
  7. Agno 2.4.0 README with the performance table
  8. Agno 1.2.0 README with the 10,000x figure
  9. Agno performance comparison scripts
  10. WebSearchTools documentation
  11. Agno model provider index

Route: Frameworks to Build AI Agents