Hello, I have question related to system prompt. ...

# koog-agentic-framework

[Mirzamehdi]

Hello, I have question related to system prompt.

Let's say I have 2 different prompts, for example one would start "Act as designer...." and another one would start "Act as developer.."
For better results do I need to start 2 different agents that specialized in different tasks, or somehow in strategy I need to specify it?

The main question is that if I do it in one agent is it like an agent confused about its role or when specifying in strategy it overrides its role?

Because if I would take example from Chatgpt most of the time starting in new chat would give better results

[Vadim Briliantov]

Hi! If you have 2 completely independent actors with 2 independent roles and sets of tasks — it’s indeed better to start separate agents.

Though, if you need to share some history between them — you can use a composite strategy and rewrite the system prompt before the execution of each of them.

Another thing is — you can consider using parallel execution if they are independent but need to eventually merge their results and proceed further (see: https://docs.koog.ai/parallel-node-execution/):

val designer by subgraph { 
     val setSystemPrompt by node {
          llm.writeSession { rewritePrompt { prompt("id") { system("You are designer") } }
     }
     …
}

val developer by subgraph { 
     val setSystemPrompt by node {
          llm.writeSession { rewritePrompt { prompt("id") { system("Act as a developer") } }
     }
     …
}

val designAndDevelop by parallel(designer, developer) {
    ... // combine the results and acquired message histories
}

val qa by subgraph { ... } // Acts as a QA


designAndDevelop then qa

[Mirzamehdi]

Ohh that's cool, that is exactly what I was looking for, thanks a lot 🙏

[Gabriel Duncan]

@Vadim Briliantov i'm working on something where i'm not sure the best way to architect it based on the same problem -- multi-agent, single agent with subgraphs etc. the problem is going through a conversational onboarding process. there is a checklist of facts and questions that need to be answered. to keep things conversational i want to have separate responsibilities:
• a time checker that will force wrapping up if time is getting close
• an evaluator that knows the question bank and is judging whether questions get answered sufficiently (and sometimes multiple questions will be answered indirectly in a single response)
• a question asker that is mainly concerned with the conversation dynamics
i might be overcomplicating things here, but assuming that's what i want to build, is that a multi-agent or a subgraph architecture? what's the rule of thumb (if there are any at all)?

[Gabriel Duncan]

i also have tools like:
• load state
• update state
• ask user
• next question
• check time
each responsibility (agent? subgraph?) should only have access to a subset of tools. for example, the question asking part only needs to load state and read it, not update it. updating state (session data) really belongs to the evaluator etc.

[Vadim Briliantov]

Hi @Gabriel Duncan ! Thanks for sharing what you are working on.

Of course the best option is always — to try several approaches, evaluate online and offline, and compare.
Bur what I would personally start with would be:
• time checker is a part of the strategy graph. Literally a conditional edge with a condition about message times and/or total tokens spent going to some sub-graph for shortcut finishing. That’s pretty much a known pattern : if history grows too long/ you soent too much tokens / too much time has passed — better to route to a shortcut path and finish with probably worse result but at least in time.
• Evaluator is essentially an LLM as a judge. Usually to make it unbiased — it’s better to put it as a separate agent (with vector database/ranked document storage/embeddings for known answers). Otherwise, if you share the history with the general flow, it might get biased. Plus — it has its own system message. In Koog you can provide another agent as a tool, for instance, using AIAgent.asTool(“description”) syntax. Also please consider checking https://docs.koog.ai/ranked-document-storage/ and https://docs.koog.ai/embeddings/ . Then, it’s up to you whether you just provide it as yet another tool for your agent and prompt it to use it, or force it’s usage in the strategy (ex: use https://docs.koog.ai/nodes-and-components/#subgraphwithtask or https://docs.koog.ai/custom-subgraphs/ that can take a list of tools, or alternatively — you can call any tool anytime directly inside a llm.writeSession{…} of the node using callTool(::toolFunction, arg1, arg2) or callTool<ToolClass>(toolArgs) depending on what type of tools you use). Alternatively, you can even go without a separate tool/agent and write a custom node that would call the LLM using promptExecutor available from inside of the llm.writeSession (it won’t be sharing the history with the parent agent, if called directly — and you’ll see an OptIn warning about that — it’s exactly what you need) and use the vector storage as well inside such node.
• A question-asker is essentially a part of the strategy (a tool or a node)

Sorry for too much of text, I hope I didn’t make it too complicated. Please let me know if it helps or if you need more advice here — I’m always happy to chat about the architecture of agents

[Gabriel Duncan]

@Vadim Briliantov thanks for your reply. I think I'm getting more confused. If you'd be willing to do a live chat I'd be happy to go over it in more detail. It should be a simple application. I'm starting with this so that I can share with my company and try to get the engineers to move to koog.

[Vadim Briliantov]

@Gabriel Duncan my apologies for not replying for a while — was busy with the release and the blogpost.
Sure, let’s have a chat next week.