What does Koog's Spring Boot starter auto-configure, and how do you use it in a service?

## What the starter actually does The starter is deliberately small. It performs the one piece of wiring that is pure boilerplate in every Spring service: reading provider credentials from configuration, constructing the right `LLMClient` for each provider you configured, and publishing a `PromptExecutor` bean into the context. Provider settings live under the `ai.koog` prefix in `application.yaml` or `application.properties`, one block per provider, so they participate in Spring's normal configuration story — profiles, environment variables, config server, secret injection. The bean it publishes adapts to what you configured. Configure a single provider and you get an executor bound to that one client. Configure several and you get a multi-provider executor that dispatches each call on the provider of the `LLModel` you pass, which is what makes per-call model tiering possible from a single injected dependency. ## Using it From there it is ordinary Spring. Inject `PromptExecutor` into a service by constructor. For a one-shot prompt, build a `Prompt` and call `execute` with the model you want. For an agent, hand the executor to the agent you construct, alongside your own strategy and tool registry. The pattern that scales is to keep a thin service layer between your controllers and Koog: one Kotlin class per capability that owns its prompt, its model choice, and its result parsing. Controllers then depend on your domain-shaped API rather than on prompt strings, which keeps prompts testable and swappable and keeps model-selection policy in one place. ## What it deliberately does not do It is a *model access* starter, not an agent framework in a box. It does not invent a strategy, register tools, decide which model each use case should use, manage conversation history, or give you session storage. Those are application decisions, and the starter leaves them alone on purpose — the alternative would be a set of opinionated beans you fight rather than use. That boundary matters for interview answers, because the follow-up is always about *state*. The executor is a stateless singleton shared by every request. Multi-turn conversations therefore need somewhere to live: a database keyed by conversation id, a cache, or Koog's own persistence and memory features installed on the agents you build. Nothing about injecting a bean solves that for you. ## Coroutines and the servlet model Koog's API is suspending from top to bottom. In a Kotlin Spring application, the clean route is a suspending controller handler or a suspending service method, which Spring supports for Kotlin handlers. The anti-pattern to name explicitly is wrapping every call in `runBlocking` on a servlet thread: a model call can take tens of seconds, an agent run can take minutes, and blocking a bounded request-thread pool on that turns a modest burst into thread starvation for your whole application, including endpoints that have nothing to do with the agent. If you must bridge from blocking code, do it onto a dedicated bounded dispatcher, not the request thread, and put a timeout on it. Related: long agent runs do not belong inside a synchronous request at all. The usual shape is to accept the request, start the run on a background scope with its own supervision and timeout, return an identifier, and let the client poll or subscribe over SSE or WebSocket for progress. ## Configuration and operational concerns Because keys are ordinary Spring configuration, the usual rules apply: no keys in the repository, inject from the environment or a secret manager, and use profiles so local development can point at a locally hosted model while production uses a hosted provider. Add timeouts consciously — a default HTTP timeout that is generous for a chat completion may still be far shorter than a long structured generation, and an unbounded one is worse. Also plan for provider failure. The starter gives you the seam — a single executor bean — but the retry, circuit-breaking, budget and fallback policy are yours to add around it. Do it once, at that seam, rather than in each service. ## When the starter is not the right tool If your application is not Spring, the same wiring is a few lines by hand: construct the clients, construct the executor, register it in whatever container you use. The starter saves boilerplate and standardises configuration keys; it does not unlock capability. Knowing that keeps the answer honest — the interesting engineering in embedding Koog into a Spring service is coroutine discipline, state ownership and failure policy, not the dependency line.