-
Notifications
You must be signed in to change notification settings - Fork 29
feat: add escalation tool #303
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?
Conversation
radu-mocanu
commented
Dec 3, 2025
- add escalation tool
| output_schema = response_schema or END_EXECUTION_TOOL.args_schema | ||
| validated = output_schema.model_validate(args) | ||
| return validated.model_dump() | ||
| return _handle_end_execution(tool_call["args"], response_schema) |
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.
Should we make these into tools instead? That way, the LLM gets the tool definitions without additional change.
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.
| from pydantic import BaseModel, Field | ||
|
|
||
|
|
||
| class AgentTerminationSource(StrEnum): |
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.
Need more information here. AFAIK escalations states are submit and reject. IMO the model should be the one deciding to terminate. Otherwise, any potential cleanup may get skipped.
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 the way low code currently works. without this we won t be able to reach parity
| else None | ||
| ) | ||
| if outcome and outcome == EscalationAction.END: | ||
| return Command( |
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 feels like an anti-pattern. Tools should ideally not be aware of state.
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.
same as above. the escalations can be configured to terminate the execution on reject
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.
In that case, can we port over this logic to ToolNode?
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 already being converted to a ToolNode
| return {tool.name: ToolNode([tool], handle_tool_errors=False) for tool in tools} |
| ) | ||
| output_model: type[BaseModel] = jsonschema_to_pydantic(channel.output_schema) | ||
|
|
||
| # only works for UserEmail type as value is GUID for UserId or GroupId for other types |
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.
should be better to extend the api to accept recipient type and to update this: https://github.com/UiPath/uipath-python/blob/379b7b310dca36cd6bcf9889bdbc2c81a4d0966d/src/uipath/platform/action_center/_tasks_service.py#L125-L125 ?
