Koog and Kotlin AI agents — what it is and what it is for | Guides

Short version: Koog is JetBrains’ attempt to give AI agents in the Kotlin/JVM world what a good web framework gives the web: a repeatable structure instead of a pile of glued model calls. The agent is not “a prompt with legs”. It is a controlled system: strategies, tools, state, memory, logs and tests.

What an AI agent is

An AI agent is a system where the language model does more than answer. It decides next steps, calls tools, reads data, asks for confirmation, checks results and continues until the task is done.

A chatbot tells you what could be done. An agent can actually do parts of the work. A good agent has boundaries, state and control. A bad one is an LLM released into an application like a demon in a porcelain shop.

Example: “prepare a financial report”. A chatbot writes generic advice. An agent can load data, call internal APIs, draft the report, run a compliance check, fix issues and store the result.

What Koog is

Koog is an open-source JetBrains framework for building AI agents in Kotlin and Java. It targets JVM/Kotlin teams that want agents inside existing backends, Android apps, multiplatform projects or internal tools.

It covers the glue people usually rebuild by hand:

multiple LLM providers,
tool definitions,
strategy/workflow graphs,
long history and context compression,
agent state persistence,
memory and knowledge retrieval,
streaming and parallel tool calls,
tracing and observability,
MCP and related integrations.

From Koog 1.0, JetBrains promises a more stable core API and clearer stable-vs-beta boundaries. Boring. Exactly the kind of boring production wants.

What it is good for

Koog makes sense when your app already lives in Kotlin/JVM and you do not want the agent layer in a completely different stack.

1. Internal company agents

Docs search, reports, ticket checks, routine workflows, support help. Tools and strategy stay inside the JVM stack.

2. Product AI features

Assistants in IDEs, banking apps, CRM or admin UIs. The point is not only a nice answer. It is about safely calling internal functions, managing state, keeping logs and enforcing least privilege.

3. Kotlin Multiplatform

Koog aims at JVM, JS, WasmJS, Android and iOS. Useful when some agent logic should be shared across backend and clients.

4. Multi-step workflow instead of one giant ask

The value is not “call a model”. The value is splitting work: collect data, draft, check, repair, publish. Each phase can have different tools, models and rules.

The key idea: narrow corridors

The strongest idea from Vadim Briliantov’s talk is simple: the LLM should not get the whole universe of tools. It should get a narrow corridor.

Give the model every app function and “solve it”, and it will improvise: loops, useless tool calls, burned tokens. Expensive lottery.

Better design:

Define task phases.
Allow only relevant tools in each phase.
Give a clear goal for the phase.
Verify important steps.
Keep a trace so you can inspect why something happened.

Koog models those corridors as strategies and graphs. That is healthier than one giant prompt pretending to be architecture. The same lesson shows up in coding agents: closed-loop without narrow tools and verification is just a diff generator with JVM branding.

The Koog mental model

Model — OpenAI, Anthropic, Google, Ollama, OpenRouter or another provider.
Tools — app functions, APIs, databases, files, MCP tools.
Strategy — order and conditions for steps.
State and history — what already happened, what matters, what can be dropped.
Observability — logs/traces so the agent is not a black box.
Evals/tests — proof that a new version did not break old workflows.

The model is only the engine. The agent is the whole machine around it.

Practical example: a report

Bad:

“Here is the database, Slack, docs and spreadsheets. Make the report.”

Better:

Collect — read-only data access, produce a fact list.
Analyze — work only on collected facts, find trends.
Draft — write the document, no more data pulls.
Check — another step verifies numbers, compliance and missing sources.
Repair — on failure, return to a specific phase.
Publish — only after checks pass.

That is the difference between “AI magic” and engineering.

What Koog is not

Not a substitute for product design. Not a fix for a broken workflow. Not security by existence. Not proof that every use case should be an agent.

Also not proof that Kotlin suddenly wins all of AI. Python still owns the ML research ecosystem. Koog answers a narrower question: what if our apps, teams and ops already live in Kotlin/JVM and we want the agent layer there?

Common traps

Too many tools → the model wanders.
No traces → failures are mysteries.
No evals → every prompt change is a religious experiment.
Long context without compression → you pay for history the model no longer uses well.
Agent instead of workflow → some jobs should stay deterministic code.
Security as an afterthought → permissions, sandboxing and approvals belong in the design.

When I would reach for Koog

Yes, if:

the team writes Kotlin/Java and does not want another Python runtime,
the agent must call existing JVM application logic,
the task has multiple steps and needs state,
tracing, testing and operations matter,
you want a path from assistant to more autonomous workflows.

No, as a first choice for pure ML research prototypes that already live in Python notebooks. That is a scenic detour.

Sources

What to remember

Koog is interesting not because “Kotlin also has an AI framework”. It is interesting because it treats agents as a software engineering problem: strategy, tools, state, observability, memory, testing and production fit. A good agent is not a free genius. It is a model guided through a narrow corridor, with tools it can use and a trail you can investigate later.