Agno
The Agent Framework That Cares How Fast You Instantiate
A framework that ships a built-in performance eval for agent construction, benchmarks itself against four competitors, and treats latency as a feature rather than a footnote? That is either a gimmick or the first honest design decision in the space, and I spent the morning finding out which.
Most agent frameworks benchmark themselves on leaderboard scores. MMLU. HumanEval. SWE-bench. Pick a task, pick a model, pick a score, and claim that your framework makes the model smarter. Agno does not make this claim. It benchmarks itself on three things that have nothing to do with model capability: how fast you can create an agent, how much memory that agent consumes, and how reliably the agent does whatever you asked it to do. The first time I saw the comparison table on their docs site, I assumed it was a marketing gimmick. Then I looked at the code, and the performance eval is not a graphic. It is a class called PerformanceEval that ships in the library, wraps an agent factory function in a timer and a memory profiler, runs it a thousand times, and prints the mean and standard deviation. You can run it yourself, on your machine, against any agent you write. That is a different category of claim.
The claim itself, that Agno instantiates agents approximately 10,000 times faster than LangGraph, is the kind of number that either proves a point or proves that you measured something nobody cares about. The truth matters less than what the number reveals about the architecture. LangGraph’s create_react_agent imports langchain-core, langchain-openai, langgraph, and compiles a state graph with checkpointing machinery. Agno’s Agent() constructs a Pydantic-backed object with a model reference and a system prompt string. The overhead difference is not surprising. The surprising thing is that nobody else bothered to call it out. Every agent framework has an instantiation cost, and most of them hide it behind an abstraction layer that makes the cost feel like a design choice. Agno makes it a benchmark, and the benchmark is telling you something about what the framework thinks an agent is.
An agent in Agno is a Python object with three primitives: Agent, Team, and Workflow. An Agent has a model, a system message, optionally some tools and optionally some storage. A Team is a coordinator that delegates to multiple Agents. A Workflow is a step-based pipeline for deterministic output. That is the whole abstraction surface. There is no state graph, no DAG compiler, no node-edge architecture. The framework does not own the control flow. It owns the agent primitive and a thin runtime for serving it, and everything else is pure Python that you write, debug with pdb, and test with pytest. The design philosophy is visible in the library structure: the SDK is one layer, the AgentOS runtime is another, and the performance evals are a third. You can use the SDK without the runtime. You can run the evals without deploying anything. You can construct an Agent in a single line of code and call agent.run() in the next. The shallow learning curve is not an accident of simplicity. It is a bet that an agent is a unit of work, not a framework of computation, and the framework’s job is to make that unit as fast and as reliable as possible.
The performance eval itself is worth looking at because it says something about what Agno considers worth measuring. PerformanceEval(func=instantiate_agent, num_iterations=1000) wraps your agent factory, runs it a thousand times, and reports the mean and standard deviation of both the wall-clock time and the memory allocation. There are warmup runs to eliminate cold-start noise. There is a comparison directory in the cookbook that runs the same benchmark against LangGraph, CrewAI, AutoGen, OpenAI Agents SDK, and Smolagents, all using identical tool definitions and model configurations. The benchmark code is in the repo. Nobody has to take Agno’s numbers on faith because they can clone the repo, set up the virtual environment, and run the script. The decision to ship the benchmark rather than the benchmark results is the kind of design instinct that tells you the framework was built by people who have been burned by vendor benchmarks before.
The runtime story is where Agno separates from the pack of lightweight agent libraries. The AgentOS is a FastAPI application that wraps your agents in REST endpoints with streaming support, session management, JWT-based RBAC, and OpenTelemetry tracing. It is not a separate product. It is the same library, imported differently. You write your agent in an agents/ directory, configure a platform.yaml, and run agno dev to get a live server with hot reload. The same server exposes SSE and WebSocket endpoints for the control plane UI at os.agno.com, which gives you a chat interface, trace viewer, memory manager, and session browser. The control plane is optional. The runtime works without it, and you can deploy it on any container platform that runs FastAPI. The architecture collapses the gap between “I wrote a script” and “I shipped a platform” to a configuration file and a CLI command, which is either the right level of abstraction or exactly the kind of magic that bites you in production when the abstraction leaks. The answer depends on whether your deployment story is already containerized and whether you trust a framework-owned FastAPI app to live next to your existing services.
The current version is 2.6.12, released on June 5, and the project has shipped six patch releases in the last three weeks. That cadence is either a sign of active maintenance or a warning that the API surface is not stable. The release notes reflect the tension: bug fixes for ArxivReader, Milvus hybrid search parameters, AG-UI protocol validation, alongside new features like HTML file generation and WorkOS RBAC integration. The commit velocity suggests a team that is building fast and fixing fast, which is the right posture for a framework at this stage, but it also means the API you use today may have moved by the time your agent hits production. The project has 40,000 GitHub stars and a large, active contributor base, so the risk is not abandonment. The risk is churn.
The model provider story is the strongest signal of architectural maturity. Agno supports over 30 providers through a single model interface, including OpenAI, Anthropic, Google, Groq, DeepSeek, Mistral, and Together. The provider abstraction is thin enough that swapping models is a one-line change, but deep enough that each provider’s native features, streaming, tool calling, structured output, are surfaced through the same Agent interface. The team primitive supports multi-agent delegation where a coordinator agent routes to specialist agents, and the workflow primitive supports step-based pipelines with conditional branching. Both compose with storage, memory, and knowledge capabilities without requiring a new abstraction layer for each combination. The design pattern is consistent: a primitive plus a list of capabilities equals a component in your agent platform. The composition happens in Python, not in YAML.
The storage architecture is where the framework’s opinion on state becomes visible. Agents can be configured with PostgreSQL, SQLite, or in-memory storage for sessions, memory, knowledge, and traces. The storage backend is a single configuration object, and it persists everything the agent generates: conversation history, learned facts, document embeddings, and audit logs. The storage layer is not a vector database. It is a relational store with pgvector for embeddings, which means you can query your agent’s state with SQL while your agent queries it with vector search. The design bet is that a single database for all agent state is simpler to operate than a separate vector store, a separate session store, and a separate audit log. The bet pays off in deployments where you already run PostgreSQL and you do not want to add three more services to your infrastructure. It breaks down if your embedding workload outgrows a single pgvector index, at which point you are doing the migration work that a dedicated vector store would have absorbed.
The thing that makes Agno interesting is not the feature list. It is the design posture. The framework cares about things that other frameworks treat as implementation details: instantiation speed, memory footprint, the difference between a library and a platform. The PerformanceEval class exists because someone on the team asked “how fast is this actually?” and built the instrumentation to answer the question instead of shipping a marketing page with a made-up number. The comparison benchmarks exist because someone decided that transparency about framework overhead is more valuable than a feature matrix that makes every framework look equivalent. The AgentOS exists because someone recognized that “I built an agent” and “I deployed an agent” are different problems that should be solved by the same library. None of these are novel ideas individually. The coherence of the package is what makes it stand out.
Agno is not the right framework for every team. If you need durable execution with automatic checkpointing and crash recovery, you want Restate or Temporal. If you need a visual workflow builder, you want n8n. If you need agents that run inside a browser, you want something else entirely. If you need a framework that treats agent construction as a performance concern, ships the benchmarks to prove it, and gives you a deployment story that does not require a separate platform team, Agno is the first framework in the Python ecosystem that has all three of those things in one install. The PerformanceEval class is not going to make your agents smarter. But it will tell you, in milliseconds and megabytes, whether your framework is doing work you did not ask it to do. That is a question every team should ask, and almost nobody does.
If this was useful, forward it to one engineer who needs less noise in their feed.