-
Notifications
You must be signed in to change notification settings - Fork 816
feat: agentic fetch tool #1315
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
feat: agentic fetch tool #1315
Conversation
uses a subagent for researching and finding content
e9abf99 to
19fe1de
Compare
4cfa2cc to
cc4a6aa
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a few questions...
First, seeing that we can implement sub-agent easily is cool! That said, I am not so sure about the benefits in this case. How is this better than letting the main model do fetching in your opinion? I imagine letting the main agent process could be better due to having more context about the problem the user described. Also, would potentially use less tokens due to being more straighforward? (No need to ask to generate a prompt and then parse the result, etc. With a sub-agent we're kinda processing it twice. It felt slower to me as well, compared to before).
Second, wouldn't it be needed to keep the previous fetch tool? I suppose it would still be needed for some things, like fetching a JSON API, maybe from a server previously ran in brackground once #1328 is ready.
The reason to use a subagent here is that we actually preserve tokens, in a lot of cases the information needed is in other pages and the agent needs to go and search for things... instead of polluting the context of the main agent with all the pages context we ask the subagent to find the thing that is actually needed and we preserve only that in the context (all the tool calls you see in the subagent are not send to the main agent) None of the HTML or unnecessary text in a webpage is sent to the main agent for sequential calls.
Yeah I think I will add back the concept of formats to fetch stuff... and add the simple fetch tool in addition to the agentic tool. |
|
@andreynering added the old fetch back and it is still smart enough to use the agent fetch with complex tasks |
| return fantasy.NewAgentTool( | ||
| tools.AgenticFetchToolName, | ||
| string(agenticFetchToolDescription), | ||
| func(ctx context.Context, params tools.AgenticFetchParams, call fantasy.ToolCall) (fantasy.ToolResponse, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a lot of data validation logic in this lambda, it looks important to make sure we're getting these right and in order. Can we move this into a concrete/defined function and break it up into individual steps, either consolidate all of the validation to run at once as a method on a agent specific config type or break into individual functions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let me know if this looks better now.


This updates the fetch tool so it uses a subagent to search and find relevant information.
agentic_fetch.mp4