-
Notifications
You must be signed in to change notification settings - Fork 45.1k
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
feature(platform) Smart Decision Maker Block #9490
base: dev
Are you sure you want to change the base?
feature(platform) Smart Decision Maker Block #9490
Conversation
This pull request has been ignored for the connected project Preview Branches by Supabase. |
This PR targets the Automatically setting the base branch to |
✅ Deploy Preview for auto-gpt-docs canceled.
|
Here's the code health analysis summary for commits Analysis Summary
|
autogpt_platform/backend/backend/blocks/smart_decision_maker.py
Outdated
Show resolved
Hide resolved
✅ Deploy Preview for auto-gpt-docs-dev canceled.
|
if not graph: | ||
raise ValueError(f"Graph not found {graph_id}") | ||
|
||
tool_functions = self._create_function_signature(node_id, graph) |
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.
Test this works with mem0
) -> BlockOutput: |
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.
@ntindle It seems that high level decision is that tools must be an AgentExecutionBlock.
If you feel strongly that this is a bad idea, let me know and we can discuss it with Toran
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.
Why should it require that? I can see plenty of use for this not needing a whole agent and the overhead that would come with it.
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.
The main reason why is to make a smart decision, a certain amount of information is required about a tool. We can backprogate this information from an agent - name, description, required params, etc.
But with a normal block, we can't really do this unless we assume that block can't be connected to another block...
There are a fair bit of subtleties with this system
…l-discovery-input-mapping-for-smart-decision-maker-block
This pull request has conflicts with the base branch, please resolve those so we can evaluate the pull request. |
…l-discovery-input-mapping-for-smart-decision-maker-block
Conflicts have been resolved! 🎉 A maintainer will review the pull request shortly. |
@Pwuts tests are failing due to an issue with the credentials system that does not occur locally. Can you advise on how to fix this please |
PR Reviewer Guide 🔍Here are some key observations to aid the review process:
|
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.
Are these true:
-
SMD can't be connected to non-AgentExecutorBlock, if so, why not? Would it calling non-agent block would be simpler, e.g: We have a block definition, type, description, etc, plus it's a more common pattern.
-
the
tools
output pin will connected to N other input pins, and then on each yield, N input will be produced, but N-1 of it will raise an exception due to the validation failure since it doesn't match the tool that the SMD is using. Is this the flow we are expecting ?
prompt: list[dict], | ||
json_format: bool, | ||
max_tokens: int | None, | ||
tools: list[dict] | None = None, |
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.
What is tools
here how do I use it? can we add it to the docstring too?
completion_tokens: int | ||
|
||
|
||
def llm_call( |
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.
This is copied function, can we remove the old one and make the function caller use this?
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 really want too, but I know how much people hate me making bigger PRs. So I was planning on refactoring llm.py in a separate PR if thats okay.
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.
Okay sounds good, though if the change is just removing self.
in self.llm_call
and removing the llm_call function I definitely don't mind doing it in a single PR. Both are fine for me 👍
tool_links = { | ||
link.sink_id | ||
for link in graph.links | ||
if link.source_name.startswith("tools_") and link.source_id == node_id |
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.
Can we make tools_
constant, and this is so prone to conflict, can we use a special character?
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.
Sure good idea
for link in self.links: | ||
input_links[link.sink_id].append(link) | ||
|
||
if ( |
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.
Add comments here?
Task
The SmartDecisionMakerBlock is a specialized block in a graph-based system that leverages a language model (LLM) to make intelligent decisions about which tools or functions to invoke based on a user-provided prompt. It is designed to process input data, interact with a language model, and dynamically determine the appropriate tools to call from a set of available options, making it a powerful component for AI-driven workflows.
How It Works in Practice
2.It identifies the available tools from the graph and constructs their signatures (e.g., send_email(recipient, subject, body)).
Changes 🏗️
Work in Progress
Current Status
I’m currently focused on the smart decision logic. The main additions in the ongoing PR include:
What’s Next
Reviewers Phase 1
This PR is now ready for review, during the first phase of reviews I'm looking for comments on approach and logic.
Out of scope: code style and organization at this stage
Reviewers Phase 2
Once we are all happy with the approach and logic. We can open the review process to general code quality and nits, to be considered.