You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So i have a 'primary' workflow service that references a number of other agent based workflows that are also deployed as independent services using the llamadeploy system.
In the old llamaagents approach i could wire the 'workflow agent' as a ToolService with metadata, and tool calls would go via the control plane and utilise the distributed service instance to run the tool call.
I dont seem to be seeing this behaviour using the new llamadeploy and workflows approach (but its def possible im missing something obv).
agent.add_workflows(fact_finder_agent=fact_agent)
This does add the workflow and i can manually call the run method from a step (or even a tool call); however my use of it is that it is called as a tool in a standard ReAct workflow process. This approach seems to call the sub workflow in the same service process as the primary workflow, I expected that it would work in a similar fashion to the old ServiceTool approach where a new task would be created for the tool call to be executed by the 'tool service' (which for all intents and purposes in this example is another deployed agent being used as a tool).
Could you confirm that nested workflows are expected to be run in process or should these generate new tasks in the same way the old 'TOOL_CALL' messages worked with ToolServices.
Appologies if I have misunderstood or am presuming features and thanks for any help you may be able to offer.
Danny
The text was updated successfully, but these errors were encountered:
Yea, the entire UX has changed quite a bit from llama-agents to llama-deploy. I should probably just delete the extra services (I thought I'd find a use for them, but workflows are so general, I don't really see the value currently)
If you want replicate the experience of the tool service, I would write a workflow for a react agent, and a workflow for calling tools.
To replicate the tool service, I would write a workflow like
classToolWorkflow(Workflow):
tools= {"tool1": tool1_fn., ....}
@stepasyncdefcall_tool(self, ev: StartEvent) ->StopEvent:
tool_name=ev.get("tool_name")
tool_kwargs=json.loads(ev.get("tool_kwargs"))
try:
tool_to_call=tools[tool_name]
result=awaittool.acall(**tool_kwargs)
exceptExceptionase:
result=f"Error while calling tool {tool_name}: {e}"# since we are intending this to run over a network, need to serialize -- could also use picklereturnStopEvent(result=json.dumps({"result": result}))
Then in the agent example, we can modify the tool calling step to use this workflow
So i have a 'primary' workflow service that references a number of other agent based workflows that are also deployed as independent services using the llamadeploy system.
In the old llamaagents approach i could wire the 'workflow agent' as a ToolService with metadata, and tool calls would go via the control plane and utilise the distributed service instance to run the tool call.
I dont seem to be seeing this behaviour using the new llamadeploy and workflows approach (but its def possible im missing something obv).
This does add the workflow and i can manually call the run method from a step (or even a tool call); however my use of it is that it is called as a tool in a standard ReAct workflow process. This approach seems to call the sub workflow in the same service process as the primary workflow, I expected that it would work in a similar fashion to the old ServiceTool approach where a new task would be created for the tool call to be executed by the 'tool service' (which for all intents and purposes in this example is another deployed agent being used as a tool).
Could you confirm that nested workflows are expected to be run in process or should these generate new tasks in the same way the old 'TOOL_CALL' messages worked with ToolServices.
Appologies if I have misunderstood or am presuming features and thanks for any help you may be able to offer.
Danny
The text was updated successfully, but these errors were encountered: