I am having a hard time understanding how to imple...

# koog-agentic-framework

[Hendre Page]

I am having a hard time understanding how to implement chat history with Koog..
Basically, how do I keep state across requests? Where does agent persistence come in and where does sessions come in?
What is automatic and what do I need to implement manually?
Can anyone point me in the right direction?

[Jeff Mandell]

This would be helpful for me too.

I took a look at https://docs.koog.ai/sessions/ but am still a bit confused what the best practice to maintain session history for a multi-turn conversation. It would also be helpful to document the lifecycle of different core objects. For example, it took me a while to learn that instances of AIAgent are meant to be single use (at least for simple and functional agents; I haven't tried graph agents yet).

I have explored google's ADK SDK and they have good documentation for managing sessions.

[Jeff Mandell]

Here is one example that I made using the llm session read & write APIs to manage state between turns of a conversation.

Would be curious to get someone from the koog team to review and provide feedback of best practices.

[Antonii Belyshev]

Here's a simple example of chat strategy in `koog`: https://github.com/JetBrains/koog/blob/develop/examples/simple-examples/src/main/kotlin/ai/koog/agents/example/chat/FunctionalAgentChat.kt. The main idea is to keep the whole conversation inside a single strategy (and therefore a single agent.run), then you do not need to transfer the context between different agents (which you indeed can do, but that's not an expected use).

Generally, if you have some dependent tasks / requests (like different messages in a single chat), they should be handled inside a single strategy run. On the other hand, when you have a few independent pipelines (like different chats), it's better to run a separate agent for each of those tasks.

[Jeff Mandell]

Thank you @Antonii Belyshev, this is helpful! This example is the direction that I'm looking for, but I'm going to experiment swapping readln and println with a different IO mechanism, e.g. flows. One use-case that I'm exploring is an audio-based chat agent.

[Jeff Mandell]

I revised the while example to use flows with this gist. Setting the strategy signature as AIAgentFunctionalStrategy<Flow<String>, Flow<String>> was fun.

[Hendre Page]

@Antonii Belyshev Thanks for this.. only coming back to it now. Seems like I completely misunderstood how Koog works..
Where does history compression and persistence come in? (I assumed implementing persistence is what gave the agent context and history )

[Antonii Belyshev]

Message history is managed inside the `llm.writeSession`: for example, if you call requestLLM(userMessage), the user message and the model response will be added to the prompt. This functionality does not require any features installed. However, the history will not be visible in another agent.run , so the whole conversation should be performed inside a single strategy (like in the chat agent example).

The history compression is a functionality designed to reduce the message history but preserve the main information. It's useful for a few reasons:
• LLM requests with shorter history will contain less tokens, and therefore be cheaper and faster
• The responses could improve because models' responses often become worse when input length grows
• Too long prompts will hit the max context length
To use the history compression, you can call compressHistory (in a functional strategy) or use nodeLLMCompressHistory (in a graph strategy)

The persistence feature is responsible for storing the agent state outside of the agent context (i.e. creating checkpoints). The main idea behind its design is to allow to resume an agent run from the latest available checkpoint if it unexpectedly stopped (e.g. due to a network error).