JetBrains has announced that Koog, their agent orchestration framework, now integrates directly with Spring AI. If you're already running Spring AI in production, the pitch is simple: keep everything you have, add Koog on top as the agent runtime layer. Your LLM providers, vector stores, chat memory backends are unaffected.
Koog adds what Spring AI deliberately doesn't try to be: multi-step workflow strategies, fault-tolerant execution with checkpointing, and history compression for long-running agent sessions.
That division of labor is pretty sensible. Spring AI is an integration layer — a consistent API surface across models and infrastructure backends. What it doesn't provide is a serious answer to "how do I build an agent that recovers from failures, manages its own context budget, and executes multi-step plans without custom glue code." Koog positions itself as that answer.
The setup is minimal: three starters that wrap your existing Spring AI beans — one for the chat model, one for chat memory, one for the vector store. Koog's auto-configuration picks them up without requiring changes to your existing application config. The JetBrains post walks through the mechanics in code.
The Coordination Problem Is Real
Spring Boot's release cadence is not slow, and dependency management across the Spring ecosystem is something every team has opinions about, mostly formed through pain. As this was being written, Spring announced an update to the base framework, with a new set of Boot releases to follow - a useful reminder that this ecosystem moves, and things that integrate with it need to move with it.
Adding Koog means two frameworks with independent release cycles that need to agree on the Spring AI integration contracts they're both honoring. The seams are probably clean right now - this is a fresh integration from a capable engineering organization. What they look like after a Spring release or two is a different question.
There's a version of this that resolves cleanly: if Koog becomes the primary surface you program against - if Spring AI recedes into infrastructure - then the dependency management problem becomes Koog's to solve rather than yours. You trust JetBrains to track Spring AI compatibility the way you trust Spring Boot to track Jakarta EE. That's a real trade, and whether it's a good one depends on your confidence in Koog's maintenance commitment.
What Koog Is Actually Solving For
The concrete capabilities include features like graph-based and planning-based workflow strategies for agents that need to do more than one thing in sequence; persistence so a failed agent run resumes from the last checkpoint rather than re-spending the LLM calls that got it there; history compression so context windows don't blow up over long sessions. If none of that sounds like your problem, Koog probably isn't for you yet - but these are real pain points for anyone running non-trivial agents in production.
You can write your agent code in Java without touching Kotlin source, but the kotlin-stdlib, kotlinx-coroutines, and kotlinx-serialization all land on your classpath at runtime. For most JVM shops that's a non-issue; for shops with strict dependency management it's worth knowing upfront: you're getting Kotlin.
If you're not already in the Spring AI ecosystem, the announcement is less immediately relevant — Koog also integrates with Ktor, and the native Java API stands on its own.
Koog is Apache 2.0 licensed and on Maven Central. The Spring AI integration starters are at version 0.8.0, independent of the Spring starters' own versioning. Worth watching closely if you're evaluating JVM agent frameworks — coordination caveats noted, eyes open.