Agno, or a framework with its own runtime

Agno, or a framework with its own runtime

Agno stands out among agent libraries for two things. The first is its emphasis on performance, which it advertises loudly and which deserves an honest reading. The second is more interesting: beyond the library itself you get a runtime layer exposing agents as a network service, with session storage, history, and run inspection.

The project started under a different name, as a tool closer to data work, and changed direction in early 2025. That history causes confusion when searching for material, since older tutorials describe something other than what the project is today.

The construction rests on four concepts: agent, team, workflow, and runtime. The first three you know from other libraries, the fourth is the differentiator here.

Your first agent

pip install agno

from agno.agent import Agent
from agno.models.openai import OpenAIChat
from agno.tools import tool

@tool
def check_stock(sku: str) -> int:
    """Returns the number of units available in the warehouse."""
    return warehouse.count(sku)

agent = Agent(
    model=OpenAIChat(id="gpt-4o"),
    tools=[check_stock],
    instructions="You answer availability questions. Always check stock.",
    markdown=True,
)

agent.print_response("Are there still shoes in size 42?")

The interface is terse and resembles other libraries of this class. Dozens of model families are supported, including locally run ones through Ollama, and switching vendor means swapping one object.

Three things other libraries add separately are built in: conversation memory, a knowledge layer based on document retrieval, and handling of data beyond text. That shortens the path from an idea to a working prototype.

The loud numbers and what they mean

The project promotes results in the range of thousands of times faster agent creation and many times lower memory use than the competition. Those numbers are true and equally misleading if you do not know what exactly they measure.

They measure the cost of creating an agent object in memory, meaning the time from calling the constructor to readiness. They do not measure the time to answer a user's question, since that is dominated by the model call, taking hundreds of milliseconds or seconds.

The proportion settles it. If creating an agent takes microseconds and calling the model takes two seconds, then speeding the first up a thousandfold changes the total by an unmeasurable amount. Choosing a library on that number resembles choosing a car by how fast its doors open.

There are cases where it genuinely matters, though, and they deserve naming. The first is systems creating agents dynamically, one per request, under heavy traffic. The second is simulations with thousands of agents at once, where memory use decides how many fit on a machine. The third is environments where the process starts on every request, so you pay the initialisation cost every time.

Outside those three, choose on something else: observability, tooling maturity, and how quickly you establish the cause after a failed run. The model bill will be several orders of magnitude larger than the library's own cost anyway.

This is not a criticism of the project, since the numbers are honest and low memory use has real value across many concurrent sessions. The point is only not to build on them a decision they were never meant to support. The whole industry publishes such comparisons today, and every vendor picks the number where it looks best.

Teams and workflows

Two mechanisms with different purposes handle combining agents.

from agno.team import Team

team = Team(
    members=[analyst, editor],
    model=OpenAIChat(id="gpt-4o"),
    instructions="The analyst prepares the numbers, the editor writes the report.",
)

team.print_response("Prepare the June sales report.")

A team runs in one of four modes: the leader picks members itself and synthesises their results, routes the whole request to a single specialist, sends the same task to everybody, or keeps a shared task list until it is exhausted. Sharing responses between members is a separate setting, off by default. That suits tasks requiring different specialisms and is expensive, since coordination means model calls beyond the work itself.

A workflow serves something else: it describes steps explicitly, in code, with conditions and loops. That is the choice for processes that must run identically every time.

Dividing work between the two is a practical guideline for the whole project. Describe a process with known stages as a workflow, since you gain repeatability and cheaper diagnosis. Leave a single step requiring judgement to an agent or a team.

The runtime layer

This is the part the competition usually lacks and the strongest argument for this project.

The runtime wraps agents, teams, and workflows in a server exposing them through an ordinary network API. You get ready endpoints, session management, conversation history storage, execution traces, and a view of what happens inside.

The practical difference is that you do not write the server layer yourself. In a typical agent deployment that is several hundred lines handling sessions, streaming, history storage, and authentication, plus decisions that must be made correctly the first time.

An important distinction: state goes into your database rather than the vendor's service. That means conversation data stays with you and falls under your retention rules, which under personal data requirements is sometimes a condition of entry.

Note, though, that a runtime layer is another dependency in the architecture, with its own release cycle. If you already have a mature server layer, wiring agents into it is often simpler than adding a separate runtime alongside.

The run inspector deserves attention too, since it is the most practical part of this solution. You see a single run as a tree: model calls, tool calls, arguments, results, timings, and token usage. Without that the only diagnostic method is repeating the run and staring at the console, and with agents, where the same input produces different runs, that method simply fails.

Memory and knowledge

Two things available immediately that other libraries require separate packages for.

Memory stores conversation history along with conclusions from it, attached to a user and a session. The agent remembers what you settled yesterday without passing the whole history in every request.

That is a record the library keeps: the agent uses it but does not manage it. Letta takes the opposite route, where the agent edits blocks of its own memory with tools and decides for itself what stays in context and what gets paged out. It works better across a long running relationship with one user, at the cost of extra model calls on every write, though note that the authors described that project's Python server as deprecated in July 2026 and moved development to a Node.js variant.

The knowledge layer is document retrieval wired into the agent as a context source. You load documents, name a vector store, and the agent reaches for them when needed.

Plan two things for both mechanisms from the start. The first is cost: memory requires model calls when writing, and knowledge requires them when computing vectors, so both add to the bill beyond the conversation itself. The second is data deletion. A record attached to a person falls under the right to be forgotten, so the ability to erase everything concerning one user should exist from day one rather than appear after the first request.

What is actually worth measuring

Since agent creation numbers say little, the numbers that genuinely settle a library choice and production readiness deserve naming.

The first is cost per task, measured on real cases from your own system rather than a documentation example. Take ten real requests, sum the tokens used, and multiply by your planned scale. That one number says more than any library comparison.

The second is turns per task. An agent finishing in three turns and one needing twelve differ fourfold in cost, and the difference usually comes from tool descriptions and instructions rather than from the library.

The third is time to the first visible character. Users judge speed by when something starts happening rather than by total run time. Streaming intermediate events can change the perception of a thirty second task more than any optimisation.

The fourth, the most important and least often measured, is the share of tasks completing successfully across a fixed set of cases with expected results. Only that establishes whether a change to the instructions improved anything. Without it, judgement reduces to an impression from a few manual attempts, and impressions mislead regularly.

The fifth is time to establish the cause after a failed run. Hard to measure and the most keenly felt in daily work, and it usually decides whether a team stays with its chosen library after three months.

Deployment and running costs

A few things this class of tool requires settling before anything reaches users.

A per run cost cap should exist from the first launch. An agent in a loop can make dozens of model calls before anybody notices, and a ceiling is the only mechanism working without your attention.

Recording runs is cheaper here than elsewhere, since the runtime layer does it itself, while how long that data is kept deserves a decision. Storing every conversation with no expiry grows in the database at a pace nobody planned, and with personal data the obligation to delete it arrives too.

Think through what happens when you deploy a new version with sessions in flight. Changing the system instructions mid conversation produces an agent behaving differently from two turns earlier, which to a user looks like a fault. Pinning a session to a configuration version settles that once.

The last thing is isolating tools that change state. A function sending a message or modifying data should require confirmation or operate on an explicitly bounded scope, since its arguments come from text the model generated, which input data also influences.

Agno against the alternatives

The first criterion is what you have already built. If a server layer, sessions, and history storage already work in your system, adding a separate runtime is surplus, and then the library's interface alone matters.

The second is the maturity of diagnostic tooling. With agents the biggest cost is establishing why a run went wrong, and there projects with a longer history and larger community hold the advantage.

Common mistakes

The first is choosing a library on agent creation numbers. They measure the cost of creating an object rather than response time, which is dominated by the model call.

The second is searching for material under the project's former name. Older tutorials describe a tool with a different purpose and mislead.

The third is a team of agents where a workflow suffices. Coordination means extra model calls, so with known steps you add cost without gain.

The fourth is enabling memory and the knowledge layer without pricing them. Both add calls beyond the conversation itself, and that shows up only on the bill.

The fifth is having no way to delete one user's data. Memory attached to a person falls under personal data rules, and adding that later is harder than planning it at the start.

The sixth is adding a runtime layer to a system that already has one. Two runtimes side by side mean two release cycles and two places where something can break.

FAQ

Is Agno the former Phidata?

Yes, the project renamed in early 2025 and changed direction at the same time: from a tool closer to data work into an agent framework with its own runtime layer. Material under the old name describes something else and is worth skipping.

Do those performance numbers matter?

In three cases yes: creating agents dynamically per request, simulations with thousands of agents at once, and environments starting a process on every request. Outside those, response time is dominated by the model call and the difference is unmeasurable.

What is the runtime layer?

A server exposing agents through a network API, with session management, history storage, and run inspection. State goes into your database, so conversation data stays with you and falls under your retention rules.

Does it work with models beyond one vendor?

Yes, dozens of model families are supported, locally run ones included. Switching vendor means swapping the model object passed to the agent, with no changes elsewhere.

When should I choose something else?

When you already have a mature server layer with sessions and history storage, since this project's main advantage is then surplus for you. When run diagnostics matter most, check LangGraph, which has a longer history and richer observability tooling.

Documentation sits on the project site, and the code in the GitHub repository.