Skip to content

fix: Notify agent of failed agent transfer in function response #1206

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 2 commits into
base: main
Choose a base branch
from

Conversation

calvingiles
Copy link
Contributor

What happens now

If an error is raised when calling a sub agent - for example, because one of the toolsets raises an error on get_tools (expected on an MCP toolset connection error, for example) then the error is silently caught, and the transfer response is returned as is. The means two things:

  1. the context window strongly implies that a transfer was successful
  2. the last sent message is from the original agent, not the transferee, and so the transfer will not have been picked up, according to _find_agent_to_run

What should happen

given resolving the failure in general is not possible, I think the only stable solution is to accept that the transfer failed, and to ensure the transfer_to_agent response does not imply otherwise.

Alternatives

Remove the transfer call

The call and response could be stripped. This seems likely to result in the agent trying again though, without a fix being applied.

Try again

There are no general solution to a failed run_async - for example, a misconfigured MCPToolset, or an MCP server outage will result in persistent failures until that is resolved. Given this can easily take longer than the request timeout it. seems better to accept that failure may occur sometimes.

Proposed solution (in this PR)

If the run_async or run_live methods emit at least one event, consider the subagent to be working and transfer successful. If not, assume a failure and re-write the function response.

This involves just a little juggling of the yield to delay when it was yielded before until we are sure, which will put a small amount of latency on the result, but before an event is yielded it is not known if the agent was successful.

Happy to implement an alternative solution if this is not the way the project wants to take this.

@calvingiles
Copy link
Contributor Author

Note - if we want to make successful transfer clearer, we can also add return {'result': f'Transferred to {agent_name}'} as a default in the transfer_to_agent tool (which will be overridden on failure).

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.

1 participant