Skip to content

Allow additional tools at runtime #8190

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

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

TomeHirata
Copy link
Collaborator

@TomeHirata TomeHirata commented May 7, 2025

This PR allows tools to maintain states during the lifespan of each ReAct.forward without affecting other executions by allowing users to pass additional tools to forward. Users can create a tool class that mutates instance variables.

class Counter():
    def __init__(self):
        self.count = 0

    def __call__(self, i: int):
        self.count += i
        return self.count

counter = Counter()

react = dspy.ReAct("max -> sum:int", tools=[])
react(max=5, additional_tools=[Counter()])

Copy link
Collaborator

@chenmoneygithub chenmoneygithub left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One minor comment

@TomeHirata TomeHirata changed the title Allow state management of tools Allow additional tools at runtime May 16, 2025
.append("next_thought", dspy.OutputField(), type_=str)
.append("next_tool_name", dspy.OutputField(), type_=Literal[tuple(tools.keys())])
.append("next_tool_name", dspy.OutputField(), type_=str)
Copy link
Collaborator Author

@TomeHirata TomeHirata May 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part feels a bit downgraded, but at the same time, I wouldn't dynamically update the signature at runtime.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels a little scary because it's hard to tell if this is going to cause regression or not.

@okhat From your experience, do you think LM can remember only to choose from provided tool without the Literal constrant?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, tool names are passed to the LLM in the same call, so LLMs should have enough context. We could dynamically construct the literal at runtime, but I think it would increase the complexity so want to avoid it unless it causes regression.

Copy link
Collaborator

@chenmoneygithub chenmoneygithub left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few minor comments, otherwise LGTM!

.append("next_thought", dspy.OutputField(), type_=str)
.append("next_tool_name", dspy.OutputField(), type_=Literal[tuple(tools.keys())])
.append("next_tool_name", dspy.OutputField(), type_=str)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels a little scary because it's hard to tell if this is going to cause regression or not.

@okhat From your experience, do you think LM can remember only to choose from provided tool without the Literal constrant?

@TomeHirata TomeHirata mentioned this pull request May 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants