# Agno: the setup is a prompt you paste, and telemetry fires once per agent run

> A Python framework and runtime for agent platforms, split into an SDK for building, AgentOS for running, and a UI for managing, with eight deploy templates that differ only in their deploy scripts. The recommended first step is not an install command, it is a prompt you hand to a coding agent, and a telemetry event leaves your machine on every run until you set one environment variable.

**agno-agi/agno** — Build, run, and manage agent platforms. Build agents, run them as a service, manage your platform using a web UI.

- Repository: https://github.com/agno-agi/agno
- Website: https://docs.agno.com
- Stars: 42,339 · Forks: 6,012
- Language: Python
- License: Apache-2.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/agno-agi-agno

## The first thing the page asks for is a prompt, not an install command

There is no pip line anywhere in this README. The get started section hands you a block of text to give to a coding agent, and it names three of them, Claude Code, Cursor, and Codex.

```text
Help me set up my agent platform.

Clone https://github.com/agno-agi/agentos-railway into a folder called
agent-platform, cd in, read the README, and follow the get started guide.
```

Read what that actually does. Your first contact with the framework is a template repository somebody else wrote, cloned into a folder the prompt names for you, and the agent inside the tool decides what to run next. The consequence is that the thing you read first is not Agno's own code, and the README you are reading is the one in this repository rather than the one in the clone. There is a separate path for people who would rather type it themselves, including a first agent in 20 lines of code, but it sits under a heading that reads as an alternative rather than the main road.

## Eight deploy templates that differ only in their deploy scripts

The deployment choice is not architectural. The starter templates are identical except for the deploy scripts, and the instruction for switching is mechanical: use the same prompt and point it at a different repository. Nine names are offered, agentos-railway, agentos-docker, agentos-aws, agentos-gcp, agentos-azure, agentos-fly, agentos-render, agentos-modal, and agentos-helm. That is good news for lock-in, since the choice commits you to almost nothing about how the platform is shaped. It is also a gap, because nothing here tells you which one fits your situation, and the list spans very different deployment shapes without saying so. A Helm chart and a Railway deploy button are not variations on one workflow, and the page treats them as a flat list. Decide from your own constraints, then read the README inside whichever template you clone, because that is where the actual deploy steps live.

## The local stack is four services, and Docker is the only prerequisite named

Run locally with Docker and you get four things: a REST API for serving your agents, a Postgres database for storing your data and traces, an MCP server, and a control plane. That is the concrete payoff of the prompt route, and it is also its real cost. The runtime surface is large enough that the feature list claims 50+ endpoints with SSE and websockets, plus 100+ integrations through pre-built toolkits, and storage for sessions, memory, knowledge, and traces. Those two numbers are the only quantities on the page and neither is enumerated here, so you cannot audit either claim from the README; the detail sits behind separate documentation pages. If your machine has no Docker, the recommended route simply does not run, and the page does not offer a non-container path for the four-service stack.

## One telemetry event per run leaves your machine, and one variable stops it

The telemetry section is short and unusually specific. Agno sends a telemetry event per agent run so the project knows which model providers to prioritize. Prompts, messages, and outputs are never sent. To disable it, set `AGNO_TELEMETRY=false`. The guarantee is scoped to content, not to volume, and the shape of the claim tells you what it is measuring: a per-run event exists to count activity, so a deployment still discloses that a run occurred, how often, and when, even with no payload attached. The practical consequence is ordering. If your environment forbids outbound events on principle rather than on content, the variable has to be set before the first run rather than after you read the section, because the first run is the one that already left. It also belongs in your deployment manifest, not in a developer's shell, or it will be missing in exactly the environment where it mattered.

## RBAC and admin approval live in the runtime, so SDK-only users do not get them

Security and human approval are listed as runtime features. Security is described as JWT-based RBAC with multi-user, multi-tenant isolation out of the box, and human approval pauses runs for user confirmation and can block tools that require admin approval. Both belong to AgentOS, the runtime layer, not to the SDK you import to build an agent. That distinction matters more than the feature list implies. If you build an agent with the SDK and never start the runtime, none of the access control described here is protecting you, and the multi-tenant isolation claim does not apply to your process. The other gap is the first step. Out of the box does not say who the first administrator is or how that account is created, and the README does not document it. Human approval has the same shape of dependency: pausing a run for confirmation only works if something on the other end can answer.

## The library asks you to feed its own docs to an agent, with no doc version to check

There is a section on using Agno with your coding agent, and it offers two paths. The recommended one is adding the Agno docs as an MCP server, which means pointing your tool at `https://docs.agno.com/mcp`. The second is adding the docs as an indexed source, which in Cursor means Settings, then Indexing and Docs, then adding `https://docs.agno.com/llms-full.txt`, and the page says the same works in VSCode and Windsurf. Think about what this implies. An agent writing Agno code is working from a snapshot your editor fetched, and nothing in either path reports which revision of the API that snapshot describes. The package is at v3.0.11 and releases landed on 2026-09-23, 2026-09-16, and 2026-09-08, so a doc snapshot can lag the library without failing loudly, and the symptom will be an agent calling a signature that no longer exists. Refreshing the index is your responsibility and nothing on the page will tell you it is stale.

## The root has libs/ and cookbook/ but no packaging manifest

The top-level entries are .cursorrules, .editorconfig, .github/, .gitignore, AGENTS.md, CLAUDE.md, CODEOWNERS, CODE_OF_CONDUCT.md, CONTRIBUTING.md, LICENSE, README.md, cookbook/, libs/, and scripts/. Two things follow. First, there is no packaging manifest at the root, so nothing on this page tells you the import name, the extras, or the supported Python versions; you have to go into libs/ to find out what the distribution is called. If you are choosing a framework by pinning a version, that information is not where you would look for it. Second, the root is already configured for agent-driven work, with AGENTS.md, CLAUDE.md, and .cursorrules sitting next to the code. The project is built to be worked on by coding agents, which is consistent with asking you to begin by handing it a prompt, and worth knowing before you clone it expecting the layout of a normal Python package.

## Conclusion

Adopt it when you want the whole stack, a REST API, Postgres storage, an MCP server, and a control plane in one local run, and when your team will actually run the AgentOS runtime rather than only importing the SDK. Skip it if you wanted a library you can pip install and read, since the page routes you to a template repository instead, and if a per-run outbound event is disqualifying in your environment. Before you start, set AGNO_TELEMETRY=false ahead of the first run, and read the runtime security page for how the first admin is created, which the README does not cover.

## FAQ

### What are the 5 types of AI agents?

This page does not classify agent types. What it describes is a platform in three named parts: build your agent platform with the Agno SDK, run it with the AgentOS runtime, and manage everything with the AgentOS UI.

### Is AGNO AI free?

The project is distributed under the Apache-2.0 license. The page describes a self-hosted stack that you run on your own infrastructure and does not list a hosted pricing plan, and it does not state costs for the model providers the agents call.

### What are level 3 AI agents?

No level taxonomy appears on this page. The capabilities it does name include human approval to pause runs for user confirmation, cron-based scheduling and background jobs with no external infrastructure, context providers for live data, and observability through OpenTelemetry tracing, run history, and audit logs.

### What are the four types of agents?

The page does not enumerate agent types. It does enumerate the channels your agents can be exposed through, naming Slack, Telegram, WhatsApp, Discord, AG-UI, and A2A as the interfaces the runtime can serve.

## Sources

- [Official documentation](https://docs.agno.com)
- [Official README](https://github.com/agno-agi/agno#readme)
- [Project repository](https://github.com/agno-agi/agno)
- [Release notes](https://github.com/agno-agi/agno/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/agno-agi-agno