Koog: AI-Agenten als Kotlin-Bibliothek statt als Python-Dienst

Welches Problem Koog adressiert und für wen es gedacht ist

Viele Agenten-Bibliotheken stammen aus der Python-Welt und werden als separater Dienst betrieben. Für ein JVM-Backend bedeutet das einen zweiten Prozess, eine HTTP-Grenze und zwei Sprachen im Repository. Koog setzt an dieser Stelle an: Das README beschreibt ein Framework, mit dem sich Agenten vollständig in idiomatischem Kotlin und Java bauen und ausführen lassen. Der Agent ist damit ein Objekt im eigenen Anwendungscode, kein externer Aufruf. Die Zielgruppe ist entsprechend eng umrissen. Wer Spring Boot oder Ktor einsetzt, findet laut README Integrationen für beide. Wer Android oder iOS bedient, kann dieselbe Agentenlogik über Kotlin Multiplatform auf JVM, JS, WasmJS, Android und iOS ausrollen. Für ein Data-Science-Team, das ohnehin in Notebooks arbeitet, ist das kein Vorteil, sondern eine zusätzliche Sprachgrenze.

Der Mechanismus: PromptExecutor, Graph und persistierter Zustand

Das zentrale Konstrukt im Quickstart ist AIAgent. Der Konstruktor bekommt einen promptExecutor, einen systemPrompt und ein llmModel. Im Beispiel ist der Executor ein MultiLLMPromptExecutor, der einen OpenAILLMClient mit API-Schlüssel umschließt. Der Name verrät die Absicht: Der Executor ist die Stelle, an der ein Modellwechsel oder ein Rerouting zwischen Anbietern ansetzt, ohne dass die Agentendefinition angefasst werden muss. Das README nennt genau das als Feature, inklusive der Anpassung der bestehenden Konversationshistorie. Daneben steht ein zweiter Baustein: flexible graph workflows. Komplexe Abläufe werden also nicht als lineare Aufrufkette modelliert, sondern als Graph. Wie die Graph-API im Detail aussieht, lässt sich aus dem Material nicht ableiten, das README verweist dafür auf docs.koog.ai und api.koog.ai. Belastbar ist dagegen die Aussage zur Fehlerbehandlung: Retries sind eingebaut, und über agent persistence lässt sich der Zustand an definierten Punkten der Ausführung sichern und wiederherstellen. Genau dort liegt der Unterschied zu einem Skript, das bei einem Timeout von vorn beginnt.

Einbindung: was in build.gradle.kts tatsächlich steht

Die Einrichtung ist bewusst knapp gehalten. In Gradle mit Kotlin DSL kommen zwei Zeilen in den dependencies-Block: implementation("ai.koog:koog-agents:1.2.0") und implementation("ai.koog:koog-agents-additions:1.2.0-beta"). In Groovy dasselbe mit einfachen Anführungszeichen. Für Maven nennt das README die Artefakte koog-agents-jvm und koog-agents-additions-jvm, ebenfalls in 1.2.0 beziehungsweise 1.2.0-beta. In allen drei Fällen muss mavenCentral() als Repository eingetragen sein. Auffällig ist die Versionsaufteilung: Das Hauptartefakt trägt die stabile Nummer 1.2.0, das Zusatzartefakt eine Beta-Kennung. Wer beide einbindet, mischt einen stabilen und einen vorläufigen Stand im selben Klassenpfad. Das ist kein Fehler, aber eine bewusste Entscheidung, die man im Blick behalten sollte. Die Anforderungen sind ebenfalls konkret: JDK 17 oder höher, Kotlin 2.3.10 oder höher explizit im bestehenden Projekt gesetzt. Das README verweist für die transitiven Abhängigkeiten auf gradle/libs.versions.toml und nennt dort kotlinx-coroutines 1.10.2, kotlinx-serialization 1.10.0 und kotlinx-datetime 0.7.1.

Anbieter, Protokolle und die Frage der Portabilität

Koog spricht laut README Google, OpenAI, Anthropic, DeepSeek, OpenRouter, Ollama und Bedrock an. Ollama ist dabei der interessante Eintrag, weil er lokale Modelle ohne Cloud-Abhängigkeit ermöglicht; das Repository führt dafür einen eigenen CI-Workflow namens ollama-tests.yml. Neben den Modellanbietern nennt das README zwei Protokolle: Model Context Protocol für Tools und Agent Client Protocol für standardisierte Client-Anwendungen. Dazu kommen Vektor-Embeddings für Wissensabruf und RAG, Streaming mit parallelen Tool-Aufrufen sowie eine History-Kompression, die den Tokenverbrauch in langen Unterhaltungen senken soll. Für Betriebsteams relevant ist die Beobachtbarkeit: Das README nennt OpenTelemetry-Exporter und als Anbieter W&B Weave und Langfuse. Wie viel Konfiguration ein solcher Export erfordert, geht aus dem Material nicht hervor. Das ist eine der Stellen, an denen die Dokumentation auf docs.koog.ai verweist und der Leser dort nachsehen muss.

Wo Koog an Grenzen stößt

Die deutlichste Einschränkung ist die Plattformbindung. Koog ist ein JVM- und Kotlin-Framework. Wer eine nicht-JVM-Sprache einsetzt, kann es nicht sinnvoll nutzen, und das ist keine Frage der Reife, sondern der Architektur. Ein zweiter Punkt betrifft die Versionierung. Das README bezeichnet Koog als stabil und semantisch versioniert, und die Release-Historie zeigt 1.0.0 im Mai 2026, 1.1.1 im Juli und 1.2.0 im August desselben Jahres. Drei Releases in vier Monaten bedeuten eine hohe Änderungsfrequenz für ein Projekt, das sich selbst als stabil bezeichnet. Ob die semantische Versionierung dabei streng gilt oder nur für ausgewählte Module, lässt sich aus dem Material nicht beantworten; dafür müsste man VERSIONING.md heranziehen. Ein dritter Punkt ist die Beta-Kennzeichnung des additions-Artefakts. Wer dessen Funktionen einplant, plant gegen eine Oberfläche, die der Maintainer selbst noch nicht als stabil ausgibt. Und schließlich: Für einen einzelnen Prompt an ein Modell ist der Apparat aus Executor, Modellklasse und Agent unnötig. Der Quickstart zeigt zwar, wie kurz das aussehen kann, aber die Bibliothek lohnt sich erst, wenn Tools, Zustand oder mehrere Modelle ins Spiel kommen.

Der Unterschied zu LangChain-artigen Ansätzen

Die naheliegende Alternative ist ein Agenten-Framework aus dem Python-Ökosystem, das als eigener Dienst läuft und über HTTP oder eine Queue angesprochen wird. Der Unterschied liegt nicht im Funktionsumfang, sondern im Ort der Logik. Bei einem separaten Dienst definiert man den Agenten in der Sprache des Dienstes und ruft ihn aus dem JVM-Backend über eine Netzwerkgrenze auf. Das entkoppelt die Teams, kostet aber einen Serialisierungsschritt, einen zweiten Deployment-Pfad und eine eigene Fehlerbehandlung für die Verbindung. Koog zieht die Agentendefinition in die Anwendung selbst. Der Agent teilt sich Typen, Konfiguration und Lebenszyklus mit dem übrigen Code. Der Preis dafür ist die Kotlin-Bindung: Ein Python-Team kann denselben Agenten nicht ohne Weiteres mitentwickeln. Wer bereits Kotlin schreibt, tauscht also eine Netzwerkgrenze gegen eine Sprachgrenze, und dieser Tausch ist nur dann ein Gewinn, wenn das Team ohnehin auf der JVM zu Hause ist.

Wartung, Lizenz und was vor dem Einsatz zu prüfen ist

Koog steht unter Apache-2.0. Das erlaubt kommerzielle Nutzung, Modifikation und Weitergabe, verlangt aber die Beibehaltung der Lizenzhinweise und enthält eine ausdrückliche Patentgewährung sowie einen Haftungsausschluss. Eine rechtliche Bewertung ersetzt das nicht, insbesondere wenn das Framework in ein Produkt eingebettet und mitverbreitet wird. Für die Wartung ist die Kopplung an die Kotlin-Version der wichtigste Kostenfaktor. Das README fordert Kotlin 2.3.10 oder höher explizit im bestehenden Projekt. Ein Upgrade der Kotlin-Version im eigenen Build kann damit ein Koog-Upgrade erzwingen, und umgekehrt. Hinzu kommt die Abhängigkeit von kotlinx-coroutines, kotlinx-serialization und kotlinx-datetime, deren Versionen im Repository festgelegt sind. Der Issue-Tracker liegt nicht auf GitHub, sondern im JetBrains-YouTrack unter dem Projekt KG; wer Fehler melden oder den Stand verfolgen will, braucht dort ein Konto. Vor dem Einsatz würde ich drei Dinge konkret prüfen: ob VERSIONING.md die Stabilitätszusage auf alle Module erstreckt, welche Funktionen im additions-Artefakt stecken und ob man sie braucht, und ob die Konfiguration der OpenTelemetry-Exporter in der eigenen Umgebung dokumentiert genug ist. Alles drei steht nicht im README, sondern nur in der verlinkten Dokumentation.

Redaktionelles Fazit

Koog passt zu Teams, die Agentenlogik ohnehin in Kotlin oder Java schreiben und keine zweite Laufzeit für einen Python-Agentendienst betreiben wollen. Wer nur einen einzelnen Prompt an ein Modell schickt, braucht das Framework nicht, und wer einen sprachunabhängigen Agentenserver mit HTTP-Schnittstelle sucht, ist mit einem eigenständigen Dienst besser bedient. Vor der Adoption sollte man die eigene Kotlin-Version gegen die Anforderung 2.3.10 prüfen, die Abhängigkeit ai.koog:koog-agents-additions:1.2.0-beta getrennt von der stabilen 1.2.0 behandeln und im VERSIONING.md nachlesen, was der Maintainer unter semantischer Versionierung versteht.

Offizielle Quellen

1. JetBrains/koog on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases