Replies: 1 comment
-
If the agents all share a kernel, then all the functions are registered to the kernel for any agent on that kernel to use |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I’ve set up a multi-agent architecture using Semantic Kernel where:
The issue I’m observing is that when a user sends a query, the router agent sometimes directly calls kernel_function tools exposed by the wrappers, instead of delegating through the full specialized agent logic. This bypasses my wrappers’ additional responsibilities (like per-agent token cost tracking and memory handling).
My questions for the community:
I’d appreciate guidance on the best practice for building multi-agent flows in Semantic Kernel, especially for ensuring all requests go through the full wrapper logic (token tracking, mem0 memory, etc.), rather than being shortcut by direct tool calls.
My architecture is
User Question -> get the past history -> pass it to orch agent (invoke/get_response) -> wrote a wrapper class for specialized agent -> orch agent should invoke the wrapper class (tool) to call that specialized agent -> the specialized agent has a list of kernel_function (tools) in it -> It will call the tool accordingly based on the question
But what is happening is
User Question -> get the past history -> pass it to orch agent (invoke/get_response) -> directly calling the kerenl function tool
Instead of calling the specialized agent, this is what happening
orchestrator_agent.py
general_wrapper.py
shared_kernel.py
we are invoking the main agent like this
Beta Was this translation helpful? Give feedback.
All reactions