Agno: Agentenplattform mit AgentOS-Laufzeit, 50+ Endpunkten und acht Vorlagenzielen
Erstellen, betreiben und verwalten Sie Agentenplattformen. Erstellen Sie Agenten, führen Sie sie als Dienst aus und verwalten Sie Ihre Plattform über eine Web-Benutzeroberfläche.
Auf einen Blick
- Was ist das?
- Agno ist ein Python-Framework samt AgentOS-Laufzeit für Agentenplattformen, mit über 50 API-Endpunkten, Speicher in der eigenen Datenbank und JWT-basierter Rechteverwaltung. Die Einordnung folgt README und Releases bis v3.0.1.
- Für wen ist es gedacht?
- Agno passt zu Teams, die Agenten als Dienst mit Schnittstelle, Datenbank und Oberfläche betreiben und ihre Daten in der eigenen Datenbank behalten müssen. Weniger passt es für Vorhaben ohne Kapazität für den Betrieb von Postgres und Containern sowie für Umgebungen, die eine belegte Sicherheitsprüfung verlangen statt zugesagter Mechanismen.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Drei Ebenen: Agno SDK, AgentOS-Laufzeit und AgentOS-UI
Agno ist ein Framework und eine Laufzeit für Agentenplattformen, geschrieben in Python. Die Beschreibung im Repository nennt drei Tätigkeiten: Plattformen bauen, sie als Dienst ausführen und sie über eine Weboberfläche verwalten.
Dahinter stehen laut README drei Ebenen. Das Agno SDK dient dem Bauen der Agenten. Die AgentOS-Laufzeit führt sie als Dienst aus. Die AgentOS-UI verwaltet die Plattform.
Der Anspruch, der das Projekt trägt, heißt Eigentum am eigenen Stack. Daten, Gedächtnis und Sicherheitslage sollen bei den Betreibenden bleiben, mit JWT-basierter Rechteverwaltung als Mechanismus. Das README spricht außerdem von einer Lernschleife, in der Simulationen und Nutzungsdaten die Agenten mit der Zeit verbessern. Wie diese Schleife konkret aussieht und was sie aufzeichnet, bleibt offen.
Die Versionierung ist jung. v3.0.0 erschien am 24. August 2026, v3.0.1 zwei Tage später, dazwischen liegt eine Vorabversion v3.0.0a5 vom selben Tag.
Einrichtung über einen Coding-Agenten und agentos-railway
Der empfohlene Einstieg ist ungewöhnlich. Statt einer Befehlsliste gibt das README einen Textblock, den man einem Coding-Agenten übergibt; genannt werden Claude Code, Cursor und Codex.
Der Text weist den Agenten an, https://github.com/agno-agi/agentos-railway in einen Ordner namens agent-platform zu klonen, hineinzuwechseln, die dortige README zu lesen und der Anleitung zu folgen. Herauskommen soll laut README eine lokal mit Docker laufende Plattform, bestehend aus einer REST-Schnittstelle für die Agenten, einer Postgres-Datenbank für Daten und Traces, einem MCP-Server und einer Steuerungsebene.
Für andere Ziele tauscht man nur den Repository-Namen: agentos-docker, agentos-aws, agentos-gcp, agentos-azure, agentos-fly, agentos-render, agentos-modal und agentos-helm. Das README sagt, die Vorlagen seien bis auf die Bereitstellungsskripte identisch.
Wer von Hand arbeiten will, findet drei Einstiege: einen ersten Agenten in 20 Zeilen unter docs.agno.com/first-agent, eine eigene Plattform unter docs.agno.com/agent-platform/overview sowie die vollständige Dokumentation. Der Weg über den Coding-Agenten ist bequem, aber wer wissen will, was auf der eigenen Maschine geschieht, liest die Vorlage selbst.
Über 50 Endpunkte mit SSE und Websockets
Die Schnittstelle ist als Produktions-API beschrieben, mit mehr als 50 Endpunkten, die Server-Sent-Events und Websockets unterstützen. Genau hier löst sich Agno von einer reinen Bibliothek: Ein Produkt kann auf diesen Endpunkten aufsetzen, statt eigene Protokolle zu erfinden.
Zum Verhalten der Endpunkte unter Last macht das Material keine Angabe. Ein Schema oder eine OpenAPI-Beschreibung wird im README nicht verlinkt. Bei mehr als 50 Endpunkten wäre das die erste Adresse für eine Bewertung, und ihr Fehlen in der Übersicht bedeutet zusätzliche Lektüre in der Dokumentation.
Für die Arbeit am Code selbst bietet Agno zwei Wege an, die beide darauf zielen, die Dokumentation dem Coding-Agenten zugänglich zu machen: einen MCP-Server unter docs.agno.com/mcp sowie eine indizierbare Fassung unter docs.agno.com/llms-full.txt, die in Werkzeugen mit Dokumentenindex eingetragen wird.
Speicher in der eigenen Datenbank und über 100 Toolkits
Der Speicher liegt in der eigenen Datenbank. Sitzungen, Gedächtnis, Wissen und Traces werden dort abgelegt, nicht bei einem Dienst des Anbieters. Das ist die konkrete Form der Eigentumsbehauptung, und sie hat eine Betriebsfolge: Die Datenbank ist selbst einzurichten, zu sichern und zu migrieren.
Für Anbindungen nennt das README mehr als 100 vorgefertigte Werkzeugsätze, mit GitHub, Slack und Postgres als Beispielen. Kontextanbieter ziehen zusätzlich Live-Daten aus Slack, Drive, Wikis, MCP und eigenen Quellen.
Diese Breite ist der praktische Vorteil gegenüber einem Selbstbau. Sie ist zugleich Abhängigkeitsfläche, denn jeder Werkzeugsatz bringt eigene Versionen und eigene Anforderungen an Berechtigungen mit. Eine Richtlinie, wie diese Abhängigkeiten geprüft oder erneuert werden, nennt das Material nicht.
JWT-RBAC, Mandantentrennung und menschliche Freigabe
Bei der Sicherheit wird das README konkret und bleibt dann stehen. Es nennt JWT-basierte Rechteverwaltung sowie Trennung zwischen mehreren Nutzern und mehreren Mandanten als ab Werk vorhanden. Wie Richtlinien konfiguriert werden und ob die Trennung für jede Laufzeitkomponente gilt, ist der Dokumentation zu entnehmen, nicht der Übersichtsseite.
Der zweite Mechanismus geht über Rechte hinaus und ist der eigentlich interessante. Die menschliche Freigabe kann einen Lauf anhalten, bis jemand bestätigt, und Werkzeuge blockieren, die eine Freigabe durch eine Verwaltungsperson brauchen. Damit lässt sich eine Grenze ziehen, die nicht am Rechtesystem hängt, sondern am einzelnen Werkzeug.
Was fehlt, ist der Nachweis. Eine Zertifizierung, ein Prüfbericht oder eine Garantie sind im Material nicht belegt. Die Aussage betrifft Kontrolle, nicht Konformität.
OpenTelemetry, Cron-Planung und Schnittstellen nach außen
Beobachtbarkeit läuft laut README über OpenTelemetry-Tracing, einen Verlauf der Läufe und Prüfprotokolle. Die Wahl ist sinnvoll, weil sich OpenTelemetry in bestehende Werkzeugketten einhängen lässt, statt eine eigene Oberfläche aufzuzwingen.
Die Planung arbeitet mit Cron-Ausdrücken und Hintergrundaufträgen, ausdrücklich ohne zusätzliche Infrastruktur. Wer schon einen Warteschlangendienst nur für wiederkehrende Agentenaufgaben betrieben hat, spart sich das hier. Die Kehrseite ist eine Frage an die Ausfallsicherheit: Was mit einem geplanten Auftrag geschieht, wenn die Instanz zum Ausführungszeitpunkt nicht läuft, sagt das Material nicht.
Als Bereitstellungsziele nennt das README jede Plattform, die Container ausführt, mit Docker, Railway, AWS und GCP als Beispielen. Nach außen erreichen Agenten ihre Umgebung über Schnittstellen zu Slack, Telegram, WhatsApp, Discord, AG-UI und A2A.
Ein Telemetrieereignis pro Lauf und AGNO_TELEMETRY=false
Die Telemetrie ist dokumentiert und knapp gehalten. Agno sendet pro Agentenlauf ein Ereignis, damit die Wartenden sehen, welche Modellanbieter sie bevorzugen sollen. Prompts, Nachrichten und Ausgaben werden laut README nie gesendet. Abschalten lässt sich das über die Umgebungsvariable AGNO_TELEMETRY=false.
Offen bleibt, ob die Telemetrie in der Voreinstellung an ist und auf welchem Weg das Ereignis übertragen wird. Wer in einer Umgebung mit strengen Vorgaben arbeitet, setzt die Variable von Anfang an, statt dem Verhalten nachzugehen.
Die Lizenz ist Apache-2.0. Sie erlaubt Nutzung, Veränderung und Weitergabe auch in kommerziellen Produkten und enthält eine Patentklausel, die bei einer Patentklage gegen Beitragende endet. Gewährleistung und Support sind im Lizenztext nicht geregelt, und das README erwähnt keinen kommerziellen Support.
Alternative: AgentScope als Framework mit eigenem FastAPI-Dienst
Als Alternative bietet sich AgentScope an, ein Python-Framework derselben Gattung. Es verlangt Python 3.11 oder höher, wird mit uv pip install agentscope installiert und bringt eine ReAct-Schleife, ein Toolkit, Sandbox-Backends und Rechteprüfung mit, dazu einen FastAPI-Dienst mit fertiger Weboberfläche unter examples/web_ui, der mit python main.py startet.
Der Unterschied liegt im Einstieg und im Ort des Betriebs. Bei AgentScope liegen SDK und Dienst im selben Repository, und zwei Befehle bringen die Oberfläche hoch. Bei Agno führt der Weg über ein Vorlagen-Repository je Bereitstellungsziel und über einen Coding-Agenten, der die Einrichtung übernimmt; dafür stehen acht vorbereitete Ziele von Docker bis Helm bereit.
Wer eine Plattform mit mehreren Mandanten auf einer bestimmten Cloud ausrollen will, findet bei Agno das passende Gerüst eher. Wer zuerst verstehen möchte, was im Inneren passiert, und die Beispiele gern neben dem Code liegen hat, ist bei AgentScope näher dran.
Redaktionelles Fazit
Agno passt zu Teams, die Agenten als Dienst mit Schnittstelle, Datenbank und Oberfläche betreiben und ihre Daten in der eigenen Datenbank behalten müssen. Weniger passt es für Vorhaben ohne Kapazität für den Betrieb von Postgres und Containern sowie für Umgebungen, die eine belegte Sicherheitsprüfung verlangen statt zugesagter Mechanismen. Vor einer Festlegung lohnt der Blick auf zwei Dinge: ob die über 50 Endpunkte der AgentOS-API ein Schema mitliefern, gegen das sich ein Client bauen lässt, und ob AGNO_TELEMETRY=false in der eigenen Konfiguration gesetzt ist. Die Apache-2.0-Lizenz erlaubt den produktiven Einsatz, Support und Gewährleistung sind nicht zugesagt.
Community-Notizen