Agno Agent Platform
Build, self-host, and operate agent platforms with an SDK, AgentOS runtime, and control UI.
- Source repo
- agno-agi/agno
- Stars
- ★ 43k
- Last updated
- today
- License
- Apache-2.0
- Primary language
- Python
- FA score
- 41/100 · Major gaps
At a glance
- How it runs
- Works with
- Portable with changesCodex · Claude Code (Partial support)
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A product engineering team that needs to expose internally built agents through REST-style APIs, SSE, or WebSockets.
- Not a fit if
- Solo developers wanting one-command use without Docker and Postgres
- Users who want a ready-made chatbot, not a platform to build
- Source review
- 41/100 · Major gaps 2 safety controls not found
What does this agent do, and when should you use it?
Agno is a framework and runtime for agent platforms, rather than a single-purpose end-user agent. The Agno SDK builds agents, the AgentOS runtime runs the platform as a service, and the AgentOS UI manages it. Its runtime exposes more than 50 endpoints with SSE and WebSocket support for product-facing integrations. The platform can store sessions, memory, knowledge, and traces in your own database, with OpenTelemetry tracing, run history, and audit logs. It suits teams that need control over data, memory, and JWT-based RBAC while deploying containerized services on Docker, Railway, AWS, GCP, or similar environments.
Developers build agents with the Agno SDK and run the resulting platform as a service through the AgentOS runtime. The runtime exposes more than 50 endpoints with SSE and WebSocket support, and can store sessions, memory, knowledge, and traces. Pre-built toolkits connect to GitHub, Slack, Postgres, and other services; Context Providers can access live data from Slack, Drive, wikis, MCP, or custom sources. It can pause runs for human confirmation and block tools that need administrator approval, while the AgentOS UI is used to manage the platform.
- A product engineering team that needs to expose internally built agents through REST-style APIs, SSE, or WebSockets.
- An enterprise team that needs sessions, memory, knowledge, and traces stored in its own database.
- An internal-tools team connecting agents to GitHub, Slack, or Postgres while sourcing context from Slack, Drive, wikis, or MCP.
- An organization that needs JWT-based RBAC, multi-user and multi-tenant isolation, plus audit logs around agent activity.
- A platform team deploying agent services with Docker, Railway, AWS, GCP, or another container-capable environment.
How do you install or deploy this agent?
The supplied material does not provide an Agno SDK package-install command, version requirements, credential setup, or minimal runnable code. Its documented getting-started route is to have Claude Code, Cursor, or Codex clone agno-agi/agentos-railway into a folder named agent-platform, enter that folder, read its README, and follow its getting-started guide; this runs the platform locally with Docker. For another deployment target, the material names agentos-docker, agentos-aws, agentos-gcp, agentos-azure, agentos-fly, agentos-render, agentos-modal, and agentos-helm as alternatives.
How do you use this agent?
Build agents with the Agno SDK, run the platform as a service with the AgentOS runtime, and manage it through the AgentOS UI. Integrate a product through the runtime API, whose endpoints are documented as supporting SSE and WebSockets. Configure pre-built toolkits or Context Providers when external systems or live context are needed, and enable human approval for sensitive actions. The supplied material does not specify SDK calls, endpoint paths, credential formats, or a first request example.
What are this agent's strengths and limitations?
- Separates agent construction, service execution, and platform management across the Agno SDK, AgentOS runtime, and AgentOS UI.
- Offers more than 50 SSE- and WebSocket-capable API endpoints for building product-facing agent experiences.
- Keeps sessions, memory, knowledge, and traces in your own database while adding OpenTelemetry tracing, run history, and audit logs.
- Documents JWT-based RBAC, multi-user and multi-tenant isolation, human approval, and administrator approval controls.
- The supplied material lacks package installation commands, minimal code, authentication setup, and endpoint examples, so technical evaluation requires additional documentation.
- The documented local route uses Docker and includes Postgres storage, creating runtime and data-operation responsibilities for adopters.
- Integrations, context sources, permission policies, and tenant isolation need environment-specific configuration; default behavior is not established here.
- A telemetry event is sent for each agent run; the material says prompts, messages, and outputs are excluded, but opting out requires AGNO_TELEMETRY=false.
How does this agent compare with similar options?
The README presents agentos-railway, agentos-docker, agentos-aws, agentos-gcp, agentos-azure, agentos-fly, agentos-render, agentos-modal, and agentos-helm as starter templates that differ in deployment scripts while otherwise remaining identical. They are deployment-entry alternatives, not competing products.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Agno Agent Platform This agent | 41 · Major gaps | FrameworkFree + model costs | ★ 43k | today | Python | — |
| Promptise Foundry | 44 · Major gaps | Library / SDKFree + model costs | ★ 894 | 3d ago | Python | Claude.ai · OpenAI API · Claude API |
| Omnara Managed Agent Platform | 65 · Some gaps | Hosted serviceFreemium | ★ 3.4k | 1d ago | Go | Codex · Claude Code · Claude.ai · OpenAI API · Claude API |
| BoTTube | 61 · Some gaps | Self-hosted serviceFree | ★ 365 | 3d ago | Python | Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence: README mentions JWT-based RBAC, multi-tenant isolation, human approval, indicating permission control and user confirmation; Telemetry section states it sends telemetry events but never prompts, messages, or outputs, and can be disabled, showing data flow transparency; sensitive data handling has security feature descriptions. Deductions: these are mostly feature claims without implementation details or code evidence; dependency security lacks dependency list or vulnerability scanning; rollback mechanism not mentioned; publisher identity unverified, source attribution only based on repo metadata.
Evidence: README is consistent, feature list aligns with doc links, good self-consistency; dependency availability: README mentions multiple deployment templates and integrations but no dependency versions or availability guarantees; failure messages: no error handling or user-visible error examples. Deductions: lack of concrete implementation and test evidence, failure messages not documented.
Evidence: README clearly targets developers building agent platforms, provides multiple deployment scenarios (Docker, AWS, GCP, etc.) and integrations (Slack, Telegram, etc.), good environment fit; capability boundaries: describes feature scope but no explicit limits; trigger precision: mentions human approval and scheduling but no detailed trigger conditions. Deductions: capability boundaries and trigger precision lack specifics.
Evidence: README structure is clear, includes intro, quick start, features, community, contributing, license, good information architecture; install notes: provides via coding agent or manual, but no direct install command; naming stability: product name and doc links consistent, but no version history; examples and FAQ: provides example links but no FAQ; known limitations not listed; license Apache-2.0, compliant; versioning changelog not provided; maintenance responsibility: contributing guide but no explicit maintainers. Deductions: missing version history, FAQ, known limitations.
Evidence: output usability: README describes production API, storage, observability, diverse output forms; marginal value: provides 100+ integrations and multiple deployment options, high value; cost-benefit: no performance data or cost analysis. Deductions: cost-benefit lacks evidence.
Evidence: README feature claims have doc links but no implementation code or test results; cross-source corroboration: multiple deployment templates and doc links but no independent verification; fact-inference separation: README distinguishes feature descriptions and recommendations but does not explicitly mark inferences. Deductions: lack of verifiable tests or independent evidence.
- Not found in source: dependency securityPin versions and run a dependency audit (npm audit, pip-audit) before installing; prefer running it in a container.
- Not found in source: rollback or recovery pathBack up first, or work on a git branch or snapshot, so its changes can be undone.
- Publisher identity unverified, treat source with caution.
- Dependency security information missing, recommend checking dependency list and vulnerability scanning.
- Rollback mechanism not mentioned, confirm before deployment.
- Telemetry is enabled by default, though disableable, be aware of data privacy.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
Changelog New Features: - Native Approvals for Harness Agents: Claude's and Codex's own permission requests now reach the AgentOS approval UI. When the agent has a database, including one AgentOS supplies, a native request persists a PAUSED run that shows up in the existing chat and Approvals views, and Resolve plus Continue Run delivers the decision back to the same native execution without replaying the prompt. The harness's own policy decides when to ask — Claude keeps its permission_mode and explicit permission callbacks, Codex supports `approval_policy="on-request" | "untrust …View on GitHub ↗ -
Release notes excerpt
Changelog New Features: - Harness Agents in Teams and Workflows: ClaudeAgent and CodexAgent can now be members of an Agno Team and steps of a Workflow, including inside Parallel, Loop, Condition and Router. The team leader delegates to them with delegate_task_to_member like any other member, each harness runs with its own model, tools and workspace, keeps its own conversation across turns of the same session, and the team or workflow collects its runs as usual. A harness agent with sandbox= runs each turn in its own container as a member or step, and AgentOS list …View on GitHub ↗ -
Release notes excerpt
Changelog Bug Fixes: - CodexAgent: Now signs in automatically with OPENAI_API_KEY, and keeps an existing ChatGPT or other login. - OS Manager: OS Manager now lists and runs external agents such as ClaudeAgent and CodexAgent registered in AgentOS(agents=[...]), by name or ID. - Knowledge Upload: POST /knowledge/content now returns a clear 400 message when an upload has no file, text_content or URL, or when url is not a single URL. …View on GitHub ↗