Koog

Koog is what you use when the agent belongs in the application rather than beside it. The multiplatform targets cover the server, the browser and both mobile platforms, so the same agent code compiles into the Android build and the iOS build, and the trait that decides it daily is that you never leave Kotlin or lose type safety at the model boundary.

Outside that world there is little reason to choose it. Pick it when Kotlin is the language your team actually writes. Pick Spring AI Alibaba if you are on the JVM but the codebase is Java and the deployment is a service.

The risk is status, stated in the repository's own badges. An alpha stability level means the public interface can change between releases without a deprecation path, and incubator classification means the vendor has not committed to it as a product. Building an application layer on something carrying both labels is a decision to re-do work later, and the version number confirms it has not reached one.

Budget for migrations rather than upgrades. What it does right: you can change model provider mid-conversation and the existing history is carried across, which is the sort of detail people discover they needed after choosing wrong.

1. Behaviour is expressed as a graph, so the sequence is inspectable rather than emergent. 2. Fault tolerance combines retries with a persistence mechanism that restores agent state at chosen points during execution, which makes a failed run resumable at a place the author selected. 3. Token growth is handled by declared compression strategies rather than dropping the oldest messages. 4. Knowledge is retained through embeddings, ranked document storage and memory shared between agents.

Choosing where a run may be resumed, instead of checkpointing everything, is the more disciplined of the two available designs.

This is ecosystem defence and it is rational. JetBrains sells tools to people who write Kotlin and Java, and a generation of agent frameworks arriving exclusively in Python is a slow leak in that market. Publishing a credible native framework closes it, costs a small team, and never needs to be monetised directly.

The corollary is that nobody at the company has to defend its revenue, which cuts in both directions: no pressure to over-monetise, and no protection if priorities move. Likely path: folded into the company's broader assistant product, or maintained quietly for years. Position: safe to adopt inside the language, worthless as a bet on the vendor.

Nothing to purchase and it needs a Java runtime we have deployed for a decade. Integration with the two frameworks our services already use means the rollout is a dependency addition rather than a new platform, which is the shortest path any of these tools can offer. Traces export to the observability providers rather than into a proprietary console.

Two blockers. The maturity label means we would be signing up to rewrites, and support is a public chat channel plus an issue tracker, with no commitment attached. Onboarding for a Kotlin engineer is a day. Approved with conditions: one service, one team, and a review before it spreads.

Apache-2.0 and it arrives as a single dependency line, which after years of Python extras feels like luxury. The provider list includes Ollama beside the hosted vendors, and there is a dedicated build job that tests against it, so local models are exercised rather than merely listed. Tools come in over MCP and the agent can also be published for other clients to reach.

The multiplatform targets stretch to WebAssembly, meaning the same agent runs in a browser tab. I did not need that. I am glad it exists.