Probado con Agno 3.0.10 · Python 3.14 · Ollama 0.34.1 · LangGraph 1.2.11 · verificado

Actualizado: 2026-09-16

Agno es un framework de Python para construir agentes de IA cuyo mayor argumento de venta es el rendimiento. En nuestra prueba con la versión 3.0.10, crear un agente costó unos 4 microsegundos y 5,5 KiB de memoria. Antes se llamaba Phidata y en enero de 2025 pasó a llamarse Agno. La versión 3.0, publicada el 24 de agosto de 2026, rompe la compatibilidad con la 2.x y exige migrar la base de datos.

En esta guía verás qué es Agno y cómo organiza el trabajo en agentes, equipos y flujos de trabajo. También verás cuánto pesa de verdad un agente, un ejemplo probado con un modelo local, cómo migrar de la 2.x a la 3.x y en qué se diferencia de CrewAI. La misma explicación está disponible en inglés.

Puntos clave

  • Agno es un framework de agentes de código abierto (licencia Apache-2.0) escrito en Python; supera las 42 200 estrellas en GitHub y va por la versión 3.0.10, publicada el 16 de septiembre de 2026.
  • La 3.0.0 (24 de agosto de 2026) trae cambios incompatibles: las ejecuciones pasan a su propia tabla, hay que lanzar MigrationManager(db).up() antes de servir tráfico y desaparecen parámetros como enable_user_memories o reasoning=True.
  • Antes se llamaba Phidata: el proyecto se renombró a Agno en enero de 2025 y la organización de GitHub se movió a agno-agi, así que los tutoriales anteriores a esa fecha siguen citando el nombre viejo.
  • Su bandera es el rendimiento: medimos 3,9 microsegundos y 5,5 KiB por agente, y unas 200 veces menos tiempo que LangGraph al crear un agente con una herramienta.
  • Organiza el trabajo en tres piezas: agentes individuales, equipos de agentes que colaboran entre sí y flujos de trabajo deterministas por pasos, todo servido por su tiempo de ejecución AgentOS.
  • Es agnóstico del modelo: su documentación reúne 51 guías de proveedores (OpenAI, Anthropic, Gemini, DeepSeek, Mistral, Groq, Bedrock y modelos que ejecutes en tu propia máquina con Ollama) y sus metadatos de PyPI piden Python 3.9 o superior.

¿Qué es Agno (antes Phidata)?

Agno es un framework y un tiempo de ejecución para plataformas de agentes de IA. Nació como Phidata, una herramienta más orientada a datos, y en enero de 2025 se renombró a Agno; la organización de GitHub se movió a agno-agi y el paquete de PyPI pasó a llamarse agno. La versión 2 reescribió el núcleo para reducir al mínimo la sobrecarga del framework. La 3.0 cambió el almacenamiento: cada ejecución es ahora una fila de la tabla agno_runs y no un bloque JSON dentro de la sesión.

El proyecto es software libre bajo licencia Apache-2.0 y reúne más de 42 200 estrellas en GitHub. La última versión es la 3.0.10, publicada el 16 de septiembre de 2026; nosotros la hemos probado con Python 3.14.7. Se instala con pip, junto con los paquetes que usa el ejemplo de esta guía:

pip install -U agno

# Cliente de Ollama y buscador web del ejemplo
pip install -U openai ollama ddgs

# Solo si vas a servir agentes con AgentOS
pip install -U "agno[os]"

El paquete openai hace falta aunque uses Ollama: en la 3.0.10, from agno.models.ollama import Ollama falla con ImportError si no está instalado, porque el módulo de Ollama importa el de OpenAI. El extra os añade FastAPI, Uvicorn y el resto de dependencias del servidor.

Su README en GitHub lo describe como «un framework y un tiempo de ejecución para plataformas de agentes»: no solo escribes agentes, también los despliegas como servicio y los gestionas desde una interfaz web. Esa vocación de producto lo distingue de otras bibliotecas que se quedan en la capa de código.

Agentes, equipos y flujos de trabajo

Agno organiza el trabajo en tres abstracciones que conviene tener claras desde el principio. Un agente es la unidad básica: un modelo con instrucciones, herramientas y, opcionalmente, memoria y conocimiento. Es lo que usarás para tareas sueltas.

Cuando un problema pide más de una especialidad, montas un equipo (Team): agentes que colaboran y se reparten el trabajo, un enfoque parecido al que popularizó CrewAI con sus tripulaciones de agentes. Y cuando necesitas un proceso repetible y predecible, defines un flujo de trabajo (Workflow): una secuencia de pasos donde la salida de cada paso alimenta al siguiente, con estado persistente entre ejecuciones. A diferencia de un agente, que decide sobre la marcha, el flujo de trabajo es determinista y fácil de auditar. En la 3.0, Workflow solo acepta argumentos con nombre, mientras que Team([agente_1, agente_2]) sigue funcionando igual.

Por encima de las tres vive AgentOS, el tiempo de ejecución que sirve agentes, equipos y flujos como API de producción. Es de ejecución sin estado y escalable en horizontal: el estado (las sesiones) se guarda en una base de datos que tú controlas, no en el proceso. Trae además una interfaz web para observar y gestionar la plataforma. Si vienes de los grafos de estado de LangGraph, reconocerás la idea de separar la lógica del agente de su despliegue.

La 3.0 añade a AgentOS una cola para las ejecuciones en segundo plano, con un límite de 32 simultáneas por réplica. Con QueueConfig(durable=True), cada petición se guarda en la base de datos y sobrevive a reinicios y despliegues.

Rendimiento y bajo consumo de memoria

Agno se hace notar por lo poco que cuesta crear un agente, y lo hemos medido con la 3.0.10. Su herramienta PerformanceEval crea el agente mil veces y mide la memoria con tracemalloc, descontando lo que ocupa una función vacía:

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


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


evaluacion = PerformanceEval(func=crear_agente, num_iterations=1000)
evaluacion.run(print_summary=True)

En nuestro equipo (arm64, 18 núcleos, sin GPU y una carga media de 1,7), la salida fue esta:

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

Tras tres repeticiones, la media fue de 3,9 microsegundos y 5,5 KiB por agente; con WebSearchTools, el tiempo mediano subió a 16 microsegundos y la memoria media, a 12 KiB.

Agno ya no publica comparativas en su README. La última (v2.4.0, octubre de 2025) daba 3 microsegundos y 6,6 KiB a Agno frente a 1587 microsegundos y 161 KiB a LangGraph. El «10 000 veces más rápido» que citaba antes esta guía venía de la 1.2.0, de marzo de 2025.

Con el script de comparación del repositorio, que crea un agente con una herramienta, Agno 3.0.10 tardó entre 6,0 y 7,1 microsegundos y ocupó 7,5 KiB. LangGraph 1.2.11 tardó entre 1,29 y 1,43 ms y ocupó 153 KiB, unas 200 veces más tiempo y 20 más memoria. Hicimos tres repeticiones con una carga media de 5 a 6, y LangChain exige una clave ficticia en OPENAI_API_KEY aunque no llame al modelo.

Conviene entender bien qué miden esas cifras: la sobrecarga del framework, es decir, el tiempo y la memoria que cuesta montar el agente antes de llamar al modelo. En una petición real, la latencia la domina la llamada al modelo de lenguaje. En el ejemplo de la sección siguiente, la respuesta tardó 16,3 s con un modelo local de 4B en CPU.

Donde sí cuenta el ahorro es en la concurrencia. Piensa en un servicio que arranca miles de agentes por segundo, uno por petición de usuario, por ejemplo. Ahí un coste de arranque de microsegundos y unos pocos KiB por agente marcan la diferencia entre un servidor holgado y uno que se ahoga. Para un agente que ejecutas de vez en cuando, la diferencia es imperceptible; para una plataforma multiinquilino a gran escala, es justo lo que necesitas.

Un ejemplo con herramientas

Un agente útil necesita actuar sobre el mundo, y en Agno eso se hace pasándole herramientas: funciones de Python, o kits ya hechos de su catálogo de más de cien integraciones. El siguiente ejemplo crea un agente con un modelo local servido por Ollama y la herramienta de búsqueda web WebSearchTools, y le pide un resumen con fuentes. Antes, descarga el modelo con 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

agente = Agent(
    model=Ollama(id="qwen3.5:4b"),
    tools=[WebSearchTools()],
    instructions="Responde en español y cita siempre tus fuentes.",
    markdown=True,
)

agente.print_response(
    "Busca qué es el framework Agno y resúmelo en dos frases",
    stream=True,
)

Agno se conecta a Ollama en localhost:11434 o en la dirección que indique la variable OLLAMA_HOST. Esta es la salida real con Agno 3.0.10 y Ollama 0.34.1, en CPU:

┏━ Message ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃                                                              ┃
┃ Busca qué es el framework Agno y resúmelo en dos frases      ┃
┃                                                              ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
┏━ Tool Calls ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃                                                              ┃
┃ • web_search(query=framework Agno qué es, max_results=5)     ┃
┃                                                              ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
┏━ Response (16.3s) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃                                                              ┃
┃ El framework Agno es una plataforma multi-agente full-stack  ┃
┃ diseñada para construir sistemas autónomos complejos con     ┃
┃ capacidades de razonamiento avanzado, memoria persistente y  ┃
┃ gestión de conocimiento. Permite desarrollar agentes         ┃
┃ inteligentes, equipos coordinados y flujos de trabajo        ┃
┃ determinísticos que operan en Python, simplificando la       ┃
┃ creación de aplicaciones de IA a través de niveles           ┃
┃ jerárquicos desde agentes básicos hasta equipos              ┃
┃ colaborativos.                                               ┃
┃                                                              ┃
┃ (Fuentes: moge.ai, GitHub - lumys-ai/agno-agentic-framework) ┃
┃                                                              ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

El modelo decide por sí mismo cuándo buscar. En cinco ejecuciones, qwen3.5:4b buscó siempre y tardó entre 16 y 37 s, pero solo dio enlaces en tres; en esta cita páginas de terceros, no la documentación oficial. Con qwen2.5:3b cada respuesta tardó menos de 7 s, pero el modelo se saltó una búsqueda y nunca dio enlaces.

En la 3.0, DuckDuckGoTools envuelve a WebSearchTools y sus funciones pasan a llamarse web_search y search_news. Durante la prueba, el motor de DuckDuckGo dejó de devolver resultados (DDGSException: No results found.) y WebSearchTools, que elige motor automáticamente y es el que recomienda la documentación, siguió funcionando.

Para cambiar de proveedor, sustituye Ollama por OpenAIResponses, Claude o Gemini, o usa la forma abreviada model="ollama:qwen3.5:4b"; no hemos probado las variantes que piden clave de API. En la prueba añadimos options={"num_thread": 6} porque la máquina era compartida: con los 18 hilos por defecto, qwen2.5:3b generaba 0,1 tokens por segundo, y con 6, 80.

Cómo migrar de Agno 2 a Agno 3

Las notas de la 3.0.0 exigen migrar la base de datos antes de que la 3.0 sirva tráfico. Haz una copia de seguridad, detén los procesos que escriben en ella, actualiza con pip install -U agno y lanza la migración con la configuración de base de datos de tu aplicación:

import asyncio

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

db = SqliteDb(db_file="agente.db")
asyncio.run(MigrationManager(db).up())
print(len(db.get_runs(session_id="demo")), "ejecuciones en agno_runs")

Lo probamos con una base SQLite en la que Agno 2.7.3 había guardado una sesión de dos turnos. Este es un extracto de la salida con la 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 ejecuciones en agno_runs

La migración copió las dos ejecuciones a agno_runs y conservó la columna runs antigua; repetirla no cambió nada. La 3.0.10 ya leía la sesión antes de migrar, pero la guía oficial exige hacerlo igualmente. Tras verificar el historial, db.cleanup_legacy_runs_column() borra la columna antigua, un paso opcional e irreversible.

En el código, revisa estos cambios:

  • enable_user_memories: ahora update_memory_on_run
  • search_session_history y num_history_sessions: ahora search_past_sessions y num_past_sessions_to_search
  • reasoning=True: desaparece; pasa un modelo de razonamiento en reasoning_model
  • Workflow("mi-flujo", ...): el constructor solo admite argumentos con nombre, así que escribe Workflow(id="mi-flujo", ...)
  • DuckDuckGoTools.duckduckgo_search y duckduckgo_news: ahora web_search y search_news

Los nombres antiguos fallan al arrancar: la 3.0.10 lanza TypeError: Agent.__init__() got an unexpected keyword argument 'enable_user_memories'. Si guardas conocimiento por usuario en una base vectorial anterior a la 3.0, ejecuta también el script de libs/agno/migrations/v2_to_v3 que le corresponda. La guía de migración lista el resto de cambios, como la retirada de MultiMCPTools.

Agno frente a CrewAI

La comparación natural es con CrewAI, otro framework de Python centrado en equipos de agentes. La diferencia de enfoque es clara. CrewAI se articula alrededor de la metáfora del «equipo»: defines roles, tareas y una tripulación que colabora, con una experiencia guiada.

Agno es más generalista y pone el rendimiento y la puesta en producción en el centro. Cubre desde el agente suelto hasta el flujo de trabajo determinista, y lo remata con AgentOS para desplegarlo como servicio.

Si tu caso es un sistema multiagente con roles bien definidos y quieres una curva de aprendizaje suave, CrewAI encaja bien. Si te preocupan la concurrencia masiva, el bajo consumo de memoria y tener un tiempo de ejecución de producción desde el primer día, Agno lleva ventaja. No son excluyentes: ambos son agnósticos del modelo y puedes prototipar en uno y migrar si tus necesidades cambian. Para tareas más ligeras y centradas en código, también merece la pena mirar smolagents de Hugging Face, que apuesta por una superficie mínima.

Cómo hemos probado esta guía

El 16 de septiembre de 2026 ejecutamos los ejemplos en contenedores Docker sobre un equipo arm64 con 18 núcleos y sin GPU. Usamos Python 3.14.7, Agno 3.0.10, LangGraph 1.2.11 y Ollama 0.34.1 con qwen3.5:4b y qwen2.5:3b. La base migrada se creó con Agno 2.7.3. Los modelos ya estaban descargados, así que ollama pull no se ejecutó, y tampoco probamos los proveedores con clave de API ni el servidor de AgentOS.

Preguntas frecuentes

¿Es Agno lo mismo que Phidata?

Sí, es el mismo proyecto con otro nombre. Phidata se renombró a Agno en enero de 2025 y su organización de GitHub se movió a agno-agi. Si encuentras tutoriales o dependencias que mencionan phidata, se refieren a la versión antigua; el desarrollo activo está en el paquete agno, que va por la versión 3.0.10. La documentación tiene guías de migración a la 2.0 y a la 3.0.

¿De verdad es 10 000 veces más rápido que LangGraph?

No: esa cifra venía del README de la versión 1.2.0 y solo medía la sobrecarga del framework al crear el agente. Con Agno 3.0.10 y LangGraph 1.2.11, crear un agente con una herramienta nos costó 6 microsegundos frente a 1,3 ms y 7,5 KiB frente a 153 KiB. Eso no acelera las respuestas, porque la latencia la domina la llamada al modelo, que en nuestro ejemplo local tardó 16,3 s. Donde sí importa es en la concurrencia: con miles de agentes a la vez, ahorras unos 145 KiB por agente.

¿Con qué modelos funciona Agno?

Su documentación reúne 51 guías de proveedores que se usan con la misma API: OpenAI, Anthropic, Google Gemini, DeepSeek, Mistral, Groq, Amazon Bedrock, Azure OpenAI y la pasarela LiteLLM, entre otros. También funciona con modelos que ejecutes en tu propia máquina con Ollama, vLLM o LM Studio. Cambiar de uno a otro es cuestión de sustituir la clase del modelo, sin reescribir la lógica del agente.

¿Qué tengo que cambiar para pasar de Agno 2 a Agno 3?

Haz una copia de seguridad, actualiza con pip install -U agno y ejecuta asyncio.run(MigrationManager(db).up()) antes de servir tráfico. Después renombra los parámetros eliminados (por ejemplo, enable_user_memories pasa a update_memory_on_run), cambia reasoning=True por reasoning_model y usa argumentos con nombre en Workflow; la 3.0 lanza TypeError con los nombres antiguos.

Conclusión

Agno lleva al mundo de los agentes de IA una obsesión poco habitual: la eficiencia. Ofrece un arranque de microsegundos, unos pocos KiB por agente y tres abstracciones claras (agentes, equipos y flujos de trabajo) servidas por AgentOS.

Encaja de maravilla cuando necesitas escalar a mucha concurrencia sin renunciar a poner en producción. Recuerda que su ventaja de rendimiento, unas 200 veces en nuestra medición y no 10 000, se refiere a la sobrecarga del framework y no a la latencia real. El siguiente paso es instalarlo con pip install -U agno, escribir tu primer agente con una herramienta y, si vienes de la 2.x, migrar la base de datos antes de desplegar. Después, compáralo con CrewAI para decidir cuál encaja mejor en tu proyecto.

Fuentes

  1. Documentación oficial de Agno
  2. Agno en GitHub
  3. Notas de la versión 3.0.0 de Agno
  4. Notas de la versión 3.0.10 de Agno
  5. Guía oficial de migración a Agno 3.0
  6. Metadatos del paquete agno en PyPI
  7. README de Agno 2.4.0 con la tabla de rendimiento
  8. README de Agno 1.2.0 con la cifra de 10 000 veces
  9. Scripts de comparación de rendimiento de Agno
  10. Documentación de WebSearchTools
  11. Índice de proveedores de modelos de Agno

Ruta: Frameworks para construir agentes de IA