Replies: 1 comment
-
Hey @sharyar , I am facing the same issue. If you have found any solution or a workaround, could you please share it? |
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.
-
This question is less about what is possible but more about what is the right way to do things and make sure they work.
As I read the docs and examples such as the "Customer Support Agent" I see that most react style tool calling agents are implemented with a fairly simple AgentState with messages as an attribute.
However, I also see that tools can return artifacts and also receive and update state (via injected args and commands).
I am currently trying to build a ReACT style agent that has a bunch of tools at its disposal. The problem/confusion I am running into is how to design my tools and states based on this criteria:
Now, I am hoping that the model will take the results it gets from one tool and pass them to the other without trying to "generate" them on the fly. It sometimes does but sometimes not. In order to enforce this behaviour, I thought: why not update the AgentState from within the tool call by using Command as the return. This also means that the AgentState needs to have new attributes that can store these results. However, this feels off to me.
And then, I notice the llm will not take these new attributes into account and would instead try to generate the args for the subsequent tool calls based on the "ToolMessage" that it had recieved in the messages list. It seems that the llm only sees the "messages" and is not aware of the rest of the state.
So. My question is:
Beta Was this translation helpful? Give feedback.
All reactions