If you want to integrate LLMs into a Kotlin app, or build Kotlin-powered tooling around LLMs, your first stop should be Koog. Reportedly, Koog was used internally at JetBrains before eventually being pulled out into an open source library, and it just reached 1.0.0 status... at least in part.

(more on that below)

Koog's original focus was on serving as an abstraction layer for talking to LLM providers and working with models. You can create a PromptExecutor that, well, executes prompts, sending them to a provider and returning with responses. You plug in implementations that bridge between Koog's Kotlin API and the Web service API or other API offered by the LLM provider. You do not need to worry about things like API differences, how things like attachments get handled by different providers, and the like.

Koog then started trying to solve common problems with LLM interactions. For example, many LLM clients will want the LLMs to have access to tools, just as Claude Code, Codex, OpenCode, etc. have access to tools to read/write files, load Web pages, or (eek!) run arbitrary shell commands. This involves telling LLMs about the tools in the prompt, then handling "tool call" messages from the LLM, executing the tool, and sending the tool call results back to the LLM. This too can vary a bit by LLM provider, so Koog built up an abstraction layer that lets you teach it about tools, after which Koog handles all the tool-related interactions directly. Basically, the tool messaging happens "automagically", and you just see the rest of the conversation.

However, it is starting to feel like Koog is turning into a dumping ground. If it is open source and AI-related at JetBrains, it feels like it goes into Koog. It is unclear why Koog itself needs to be able to power a Spring-based Web service, or why Agent-to-Agent (A2A) needs to be in Koog rather than simply being dependent upon Koog. Even their strategy system feels like an attempt to have Koog handle the sorts of enterprise orchestration work that might be better left in the hands of folks like Temporal.

While JetBrains says that Koog is at 1.0.0, that is only true in part. Koog's VERSIONING.md page lists the several dozen modules that make up Koog. Many are 1.0.0, while others are 1.0.0-beta. Based on a Slack discussion, the -beta ones are not yet up to the desired quality and stability levels. So, for example, while the Anthropic and OpenAI bridges are 1.0.0, those for Google, Mistral, and DeepSeek are all 1.0.0-beta. My worry is that with Koog going for so much breadth, there may be insufficient staff and volunteer time to handle the depth that will let these -beta libraries stabilize.

I like Koog and will continue using it for Knosh. And if you want pluggable LLM providers for your Kotlin app, especially if you want integrated tool calling, Koog is a fine solution. Just be careful, as Koog can get complicated quickly, and you need to decide what you want Koog handling and what might be better handled elsewhere within your project.

Next issue, I will get a bit more specific and show you how Knosh integrates with Koog.