What Is Agno? Lightweight Multi-Agent Framework in Python

// In plain English

Most agent frameworks start with orchestration abstractions — graphs, chains, steps — and ask you to wire your LLM into them. Agno flips the script: you describe the agent in plain Python, and the framework stays out of the way. Give it a model, some tools, and optionally a memory store or a knowledge base, and you have a running agent in fewer than ten lines.

The closest real-world analogy is hiring a specialist consultant. A consultant arrives with their own expertise (the LLM), a stack of reference files (the knowledge base), a notebook of past conversations (memory), and a set of approved actions they can take on your behalf (tools). You don't manage how they think; you just describe the problem and the constraints, and they produce a result. Agno codifies exactly that interface.

Agno started life as Phidata, a data-engineering toolkit. In January 2025 the team rebranded and refocused the project entirely on agentic AI, cleaning up the API surface and optimising for runtime performance. By mid-2026 the GitHub repository had accumulated around 40,000 stars, making it one of the most-watched Python agent projects.

// Why it matters

Agent frameworks proliferated quickly after ChatGPT, and most of them borrowed the abstraction vocabulary of workflow engines: directed graphs, stateful nodes, explicit edges between steps. That vocabulary works well when you already know the exact sequence of operations. It becomes friction when the whole point of the agent is to decide the sequence at runtime.

Agno's design choice is to stay at the level of Python objects. An Agent is a class you instantiate with keyword arguments. Tools are plain functions. Memory and storage are pluggable drivers you pass in. There is no graph to draw, no YAML to write, and no proprietary DSL to learn. If you know Python, you can read Agno code on first sight.

Practical reasons builders choose Agno

• Rapid prototyping. A working agent with web-search and memory takes under twenty lines. Teams can validate an idea before committing to heavier infrastructure.
• Multi-provider by default. Agno supports 23+ LLM providers (OpenAI, Anthropic, Google, Groq, Ollama, and more) behind a unified interface. Switching models is a one-line change.
• Built-in RAG. Knowledge bases backed by PgVector, ChromaDB, or other vector stores are first-class citizens, not an afterthought. Hybrid search (semantic + keyword) is available out of the box.
• Multi-agent without a graph. Teams of agents are declared the same way single agents are — you hand a list of agent objects to a Team. No graph topology required.
• Horizontal scalability. Agents are stateless by default; session state lives in a pluggable storage backend. This makes it straightforward to run many concurrent sessions behind a load balancer.

The framework is especially well-suited to API-serving workloads: customer-facing chatbots, internal Q&A systems over private documents, and coding or research assistants that need to persist conversation history across sessions.

// How it works

Every Agno agent is built from four optional building blocks that you compose as keyword arguments to the Agent constructor: a model (the LLM that reasons), tools (Python functions the model can call), memory/storage (where conversation state is saved), and a knowledge base (a vector-store-backed document index the agent can search).

The four building blocks

A minimal working agent

from agno.agent import Agent
from agno.models.openai import OpenAIChat
from agno.tools.duckduckgo import DuckDuckGoTools

agent = Agent(
    model=OpenAIChat(id="gpt-4o"),
    tools=[DuckDuckGoTools()],
    description="You are a research assistant. Search the web when needed.",
    markdown=True,
)

agent.print_response("What are the most recent AI releases this week?", stream=True)

Adding memory and a knowledge base

from agno.agent import Agent
from agno.models.anthropic import Claude
from agno.memory.agent import AgentMemory
from agno.storage.agent.postgres import PgAgentStorage
from agno.knowledge.pdf import PDFKnowledgeBase
from agno.vectordb.pgvector import PgVector

vector_db = PgVector(
    table_name="company_docs",
    db_url="postgresql+psycopg://user:pass@localhost/mydb",
)

knowledge_base = PDFKnowledgeBase(
    path="docs/",
    vector_db=vector_db,
)

agent = Agent(
    model=Claude(id="claude-sonnet-4-5"),
    knowledge=knowledge_base,
    memory=AgentMemory(),
    storage=PgAgentStorage(
        table_name="agent_sessions",
        db_url="postgresql+psycopg://user:pass@localhost/mydb",
    ),
    description="Answer questions using the company documentation.",
    search_knowledge=True,
)

agent.print_response("What is our refund policy?", session_id="user-123")

Setting session_id routes the conversation into a named session stored in Postgres. The next call with the same session_id picks up exactly where it left off — even if the server restarted in between. This is the pattern Agno calls durable memory: state is in the database, not in process.

Teams: multiple agents working together

When a single agent isn't enough, Agno lets you compose a Team — a group of specialised agents that coordinate on a shared goal. The team has its own model that routes subtasks to the right member, collects their outputs, and synthesises a final answer.

from agno.agent import Agent
from agno.team import Team
from agno.models.openai import OpenAIChat
from agno.tools.duckduckgo import DuckDuckGoTools
from agno.tools.yfinance import YFinanceTools

web_agent = Agent(
    name="Web Researcher",
    model=OpenAIChat(id="gpt-4o-mini"),
    tools=[DuckDuckGoTools()],
    instructions="Find recent news and summarise it.",
)

finance_agent = Agent(
    name="Finance Analyst",
    model=OpenAIChat(id="gpt-4o-mini"),
    tools=[YFinanceTools(stock_price=True, analyst_recommendations=True)],
    instructions="Retrieve stock data and analyst sentiment.",
)

team = Team(
    name="Market Intelligence Team",
    model=OpenAIChat(id="gpt-4o"),
    members=[web_agent, finance_agent],
    instructions="Combine news and financials into a coherent briefing.",
)

team.print_response("Give me an investment briefing on NVIDIA.", stream=True)

// Agno vs other frameworks

The Python agent ecosystem is crowded. Knowing where Agno sits relative to LangGraph, CrewAI, and the Claude Agent SDK helps you pick the right tool for the job.

The most-asked comparison is Agno vs LangGraph. LangGraph's graph model shines when you need to express conditional branching with human-in-the-loop steps, precise state transitions, and deep LangSmith observability. Agno wins when you want agents that are Python classes — no graph topology to maintain, no YAML state machines, no checkpointer config. For the majority of RAG-over-documents, tool-using chatbot, and multi-agent briefing use cases, Agno's simpler surface is the right default.

// Pitfalls and tradeoffs

Agno is fast to start with, but there are real tradeoffs to understand before committing it to production.

API churn

Agno releases frequently — sometimes multiple versions per week. The transition from Phidata to Agno in early 2025 included import path changes that required updating every from phidata import ... statement. If you depend on internal interfaces rather than the documented public API, expect breakage on upgrades. Pin your version in requirements.txt and update deliberately.

Performance numbers need context

Agno's headline claim of being 5,000x faster than LangGraph refers to agent instantiation time only — the cost of creating the Python object in memory. In any real workload, the LLM API call takes hundreds of milliseconds to several seconds. Framework overhead is effectively invisible at that scale. The performance advantage matters most when you need to create thousands of short-lived isolated agent objects, not when you care about end-to-end response latency.

Limited built-in workflow structure

Agno's Workflow primitive (added in the AgentOS layer) handles structured multi-step sequences, but it doesn't offer the fine-grained state-machine control that LangGraph provides. If your application genuinely requires explicit conditional branching, loopback on failure, or human-approval gates between specific steps, Agno's opinionated simplicity becomes a constraint rather than a feature.

AgentOS is optional but opinionated

Agno 2.0 introduced AgentOS, a FastAPI-based runtime layer that wraps your agents in REST endpoints with session management, RBAC, and audit logs. It's excellent for teams who want production infrastructure quickly. But it also means adopting Agno's view of what a production agent platform looks like. If your organisation already has a gateway, auth layer, or session store with strong opinions, evaluate whether AgentOS integrates cleanly or creates a second control plane.

// Going deeper

Once you're comfortable with the basics, several Agno capabilities reward deeper investment.

Reasoning agents

Agno supports two reasoning patterns. Chain-of-Thought (CoT) passes the model's internal scratchpad back to itself before it produces the final answer — useful for maths, logic, and multi-step analysis. ReAct (Reason + Act) runs an iterative loop: the agent reasons about what to do, takes a tool action, observes the result, and reasons again until it has enough information to answer. You enable ReAct by adding ReasoningTools() to the tools list — no separate agent class required.

Multimodal inputs

Agno passes images, audio, video, and binary files to models that support them. This requires no special adapter — you include the content in the message and Agno handles the provider-specific encoding. Teams building document-processing pipelines (PDFs, invoices, screenshots) or audio-transcription agents use this heavily.

Agentic RAG patterns

Standard RAG retrieves documents at query time and injects them into the prompt. Agno's search_knowledge=True flag goes one step further: the agent itself can decide when to search the knowledge base (using it as a tool), how many results to fetch, and whether to follow up with another search based on what it finds. This is sometimes called agentic RAG — the retrieval step is under model control, not hard-wired into the pipeline.

Structured outputs

Pass a Pydantic model to response_model on the Agent constructor and Agno will instruct the LLM to return valid JSON matching that schema, then validate and parse it for you. This is the right pattern when downstream code needs to act on the agent's output programmatically — routing decisions, database writes, API calls.

from pydantic import BaseModel
from agno.agent import Agent
from agno.models.openai import OpenAIChat

class SentimentResult(BaseModel):
    score: float          # -1.0 (negative) to 1.0 (positive)
    label: str            # 'positive' | 'neutral' | 'negative'
    confidence: float

agent = Agent(
    model=OpenAIChat(id="gpt-4o-mini"),
    response_model=SentimentResult,
)

result: SentimentResult = agent.run(
    "Analyse the sentiment: 'The new release exceeded all expectations.'"
)
print(result.score, result.label)

Deployment: AgentOS and beyond

For teams that want a full production runtime, agno serve wraps your agent in a FastAPI application with /chat, /sessions, and /health endpoints. You can run it directly or containerise it — the Agno docs include Dockerfile examples. For lighter deployment, an Agno agent is just a Python object, so you can instantiate it inside any existing FastAPI, Flask, or Django view without the AgentOS layer at all.