Replies: 1 comment
-
This is how we ended up with this design: An LlmAgent can only generate responses, in order to do anything else (e.g. look up from a database, call an external api, etc), it has to use a tool. Transferring to another agent is an action, therefore it's considered as a tool. This gives flexibility to developers as well, so they can control the agent transfer themselves by writing their tool. E.g. they can write a tool that transfer to different agent in different conditions. |
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.
-
First of all, thanks for the framework - this is a super intuitive, straight-forward and clean-architected solution which was exactly what I had been looking for.
As I am going through the design - I couldn't help but notice the fact that tools can be made aware of agents. This doesn't sound like a sound architectural decision. I am specifically talking about a tool's ability to control agent flow using attribute like "transfer_to_agent"
transfer_to_agent: str: Set this to the name of another agent. The framework will halt the current agent's execution and transfer control of the conversation to the specified agent. This allows tools to dynamically hand off tasks to more specialized agents.
Would have loved these sort of decisions to be made at the agent level or even higher (workflow agents level ideally) rather than tools - shouldn't tools be fully independent of agents so that they can be used in any other agentic contexts?
Beta Was this translation helpful? Give feedback.
All reactions