adk-python vs agno: a workflow runtime next to a full agent platform

A graph runtime on one side, a platform on the other

adk-python and agno both describe themselves as frameworks for building agents, and both ship a Python package under Apache-2.0, but they operate at different layers.

In adk-python the unit of work is the Workflow. The README describes a graph-based execution engine for deterministic flows, with routing, fan-out and fan-in, loops, retry, state management, dynamic nodes, human-in-the-loop and nested workflows. An Agent carries instructions and tools; a Workflow carries the shape of the run. The Task API adds agent-to-agent delegation with a multi-turn task mode, a single-turn controlled output mode, and task agents usable as nodes inside a workflow. That is a control-flow model, and it behaves like one. You can read the graph, argue about which node runs after which, and test the route with no model in the loop.

In agno the unit of work is the platform. You build agents with the SDK, serve them with the AgentOS runtime, and manage them through the AgentOS UI. Around that sit storage for sessions, memory, knowledge and traces, fifty-plus REST endpoints with SSE and websockets, one hundred-plus integrations, context providers for Slack, Drive, wikis and MCP, human approval that pauses a run for confirmation, OpenTelemetry tracing with run history and audit logs, JWT-based role-based access control with multi-user and multi-tenant isolation, interfaces for Slack, Telegram, WhatsApp, Discord, AG-UI and A2A, and cron-style scheduling with background jobs.

The consequence is straightforward. adk-python asks you to write orchestration code and leaves the platform around it to you. agno hands you the platform and asks you to bring agent logic to it.

Running each one for the first time

Getting adk-python running is a package install and a code editor. The stable release comes from pip, needs Python 3.10 or newer, and the project publishes companion constraints files for Python 3.10 through 3.14 that pin transitive dependencies, so a repeatable environment is one download and one pip. Optional integrations install through the extensions extra, and the development version installs straight from the main branch when you need a fix that has not shipped yet. The first program is an Agent with a name, a model and an instruction, followed by a Workflow that composes it. If you would rather not write code, the Agent Config feature builds agents without it, though the project's own framing keeps code as the primary path.

agno starts differently. Its documented setup hands a prompt to a coding agent, which clones a starter repository such as agentos-railway, reads its README and follows the get started guide. The result is a local Docker stack with a REST API for serving agents, a Postgres database for data and traces, an MCP server and a control plane. Equivalent templates exist for Docker, AWS, GCP, Azure, Fly, Render, Modal and Helm, and they differ only in the deploy scripts. A manual path exists as well: the docs point at building a first agent in twenty lines of code.

So the choice at the start is between writing orchestration yourself and letting a template plus a coding agent build the platform, then editing what it produced.

What production costs on both sides

Running adk-python in production means containerizing a Python service and putting it somewhere. The documented targets are Cloud Run and Vertex AI Agent Engine, and the framework does not care which model you use, since it is model-agnostic even though it is tuned for Gemini. The cost that catches teams is the event model rather than the compute. ADK 2.0 changed the agent API, the event model and the session schema, and sessions written by 2.0 are readable by 1.28 and newer but not by older 1.x releases. That turns an upgrade into a data migration question for anything with stored sessions, and the README states a release cadence of roughly bi-weekly, which puts the changelog in your maintenance routine.

agno's production surface is wider and more explicit. The AgentOS runtime serves fifty-plus endpoints over SSE and websockets, keeps sessions, memory, knowledge and traces in your own Postgres, and schedules cron-style background jobs without external infrastructure. Human approval pauses a run until someone confirms, so a pending approval holds resources instead of failing fast. Access control is JWT-based role-based access control inside your deployment, so the identity boundary is something you operate rather than something a vendor hosts. The project also sends one telemetry event per agent run, which can be switched off by setting AGNO_TELEMETRY=false; the documentation states that prompts, messages and outputs are never sent.

Where adk-python gets in the way

adk-python's weaknesses come from the same place as its strengths. It is code-first, so a visual designer is not the way to build an agent, and Agent Config is the exception rather than the default path. Session storage is a schema you own and must migrate whenever the event model moves, and the 2.0 break with older 1.x sessions is exactly the case where a stored conversation becomes unreadable. The tool ecosystem is built for tight integration with the Google ecosystem, and although ADK is model-agnostic and sibling implementations exist in Java, Kotlin, Go and TypeScript, the reference implementation here is Python, so a Python shop gets the framework this repository documents in full.

Deployment is likewise narrow by default. Cloud Run and Vertex AI Agent Engine are the paths the project documents, so a team that needs a different runtime or an on-premises deployment writes that layer itself. There is no management console inside the package either. ADK Web is a separate repository, and sessions, traces and evaluation are things the framework gives you hooks for rather than a bundled operations surface. A team that needs a place to watch what agents did during the day ends up building it, or switching to a platform that ships one.

Where agno gets in the way

agno's weaknesses are the price of the platform it sells. The documented onboarding path asks you to hand a prompt to a coding agent and let it clone a template repository, which is a real operational bet for a team that wants to understand what is running on its machines. The platform layer then becomes yours to maintain: a Postgres instance holding sessions, memory, knowledge and traces, migrations, backups, and the access configuration that decides who may call an agent. Telemetry is on by default, one event per agent run, and turning it off takes an environment variable; the project states that prompts, messages and outputs are never included in that event.

The API surface is also large, more than fifty endpoints. That is useful if you are building a product on top of it and a liability if you only need one agent, because each endpoint is behaviour you have to audit and keep working. And a versioned major release is not far behind: the published tags move from v3.0.0 to v3.0.1 within days at the end of August 2026, so the API you write against needs pinning. A team that wants a small dependency and nothing else will find the platform layer too heavy for the job.

Licence, maintenance and the choice by scenario

Licence is not a differentiator here. adk-python and agno are both Apache-2.0, so you may modify either, host a modified copy and ship it inside a commercial product without publishing your changes. Both repositories also had a push on 2026-10-21, so neither is a project you would be adopting on the strength of an old snapshot.

The differences that should decide it are operational. If your product's hard part is the routing, with branching, retries, loops, parallel branches and a human approving a tool call before it runs, adk-python gives you a model for that which you can read in one file, at the cost of building the surrounding service. If your product's hard part is everything around the agent, a management UI, per-user and per-tenant access, scheduled jobs, a catalogue of a hundred integrations and a stable REST surface, agno has already built it, at the cost of a Postgres instance and a control plane you now operate. Teams that need both can run them side by side and let them talk over HTTP, because their scopes barely overlap and a hand-written service boundary is cheaper than trying to make one library call the other.

Bottom line

Pick adk-python when the routing logic is the hard part of your product and you want the runtime under your own code; pick agno when the platform around the agent is the part your team is missing. Before committing to either, write one realistic run end to end and pin the version you build against, because adk-python's 2.0 session format will not open on older 1.x releases and agno's AgentOS expects a Postgres instance you have to run yourself.

Sources

1. google/adk-python repository
2. google/adk-python README
3. agno-agi/agno repository
4. agno-agi/agno README