In Koog, when do you need a custom strategy graph instead of a plain AIAgent?

## Two ways to stand up a Koog agent Koog is JetBrains' Kotlin/JVM agent framework, so everything here is Kotlin code compiled with your application rather than a Python script. It gives you two entry points at very different levels of ceremony. The first is the `AIAgent` constructor on its own. You supply a `promptExecutor` (the object that actually talks to a model provider), an `llmModel`, a `systemPrompt`, optionally a `toolRegistry` holding the tools the model may call, and `maxIterations` as a safety cap. Then you call `agent.run(input)` — a suspending call that returns the agent's final answer. The second is to also pass `strategy = ...`, where the strategy is built with Koog's `strategy("name") { ... }` DSL: a directed graph of nodes and edges you declare yourself. ## What the default behaviour already does for you Without a strategy the agent is not "one LLM call and stop". It runs the standard tool loop: it sends the prompt; if the model responds with tool calls, the agent looks each tool up in the `toolRegistry`, executes it, sends the results back to the model, and repeats; when the model finally returns an ordinary assistant message, that message is the run's result. So tools work perfectly well with no strategy at all — a common misconception in interviews is that you must hand-write a graph to get tool calling. That default covers a surprising share of real work: a support-triage agent, a code-explainer, an agent with five tools that answers a question. If you cannot name a decision the framework is making wrongly for you, you do not need a graph. ## What a strategy graph buys A strategy is where the loop stops being implicit. Inside `strategy("name") { }` you declare nodes as delegated properties — `val callLLM by nodeLLMRequest()`, `val runTool by nodeExecuteTool()`, `val sendResult by nodeLLMSendToolResult()` — and connect them with `edge(a forwardTo b)`, optionally guarded by conditions such as `onToolCall { }` or `onAssistantMessage { }`. `nodeStart` and `nodeFinish` are provided as the graph's entry and exit. The things that genuinely require this: - **Branching on what came back.** Route to a validation node when the model returns structured output, and to a retry node otherwise. - **Deterministic Kotlin between model calls.** A custom `node("name") { input -> output }` runs ordinary code — hit a database, normalise a payload, call an existing service — as a first-class graph step rather than as a tool the model has to choose to call. - **History management.** Dropping a history-compression node in the middle of a long loop is something the default loop will not do for you. - **Phases with different tool sets.** Subgraphs let a research phase see search tools and a writing phase see none. - **Multi-model runs.** Cheap model for extraction, expensive model for synthesis, chosen by edges. ## What it costs Explicit control flow means explicit responsibility. Every node needs a reachable path to `nodeFinish`; if the exit condition is missing or shadowed by an earlier edge, the graph loops until `maxIterations` trips and the run fails instead of returning a half-answer. You also write and maintain more code, and the graph is a second place where behaviour lives alongside the prompt. ## The compile-time angle The reason Koog appeals to JVM teams is that the graph is typed. Each node has an input and an output type, and an edge only compiles if the upstream output feeds the downstream input; `transformed { }` on an edge adapts one to the other. A wiring mistake is a red squiggle in the IDE, not a runtime surprise in production — which is the usual selling point versus dynamically typed agent frameworks. ## How to answer this in an interview Say plainly that the default agent is not a toy: it already does prompt, tools, answer. Then name one or two concrete reasons you reached for a graph, and admit the cost — you now own termination. Candidates who claim every Koog agent needs a hand-written strategy are describing docs they skimmed, not code they shipped.