feat: support parallel calls #392
Conversation
andreitava-uip
force-pushed
the
feat/parallel-calls
branch
from
6c6253a to
f7d3bee
Compare
andreitava-uip
force-pushed
the
feat/parallel-calls
branch
from
f7d3bee to
46797a6
Compare
| return (tool_call, message) if return_message else tool_call | ||
| return (None, None) if return_message else None | ||
|
|
||
| # 2. Find first tool call with matching name from the last AI message |
There was a problem hiding this comment.
On what usecase we can end up without a tool call id?
There was a problem hiding this comment.
In our Agent loop? None because we always do routing via Send(), or the guardrail subgraph which has the tool_call_id in the state (because it was called with Send() )
But if somebody else tries to reuse our primitives anyhow and they don't respect our contract, the id can be missing
| else: | ||
| subgraph.add_edge(START, inner_name) | ||
|
|
||
| # Always add the tool call state handler node at the end |
There was a problem hiding this comment.
This function is generic for any scope (agent, llm or tool). Won't your changes add the TOOL_CALL_STATE_HANDLER for agent and llm guardrail subgraphs as well?
There was a problem hiding this comment.
it would, but the llm and agent subgraphs are expected to have tool_call_id=None, which will make the node a no-op.
We can of course also conditionally add this node only for tool guardrails, that would make it more optimized.
2 participants
Rough implementation draft to support parallel subgraphs. Successfully ran two IS tools with pre-execution guardrails in parallel.
Not yet done: