feat: simplify durable agent wf def

[sicoyle]

issue
#167

I updated the durable agent wf definition to:

• ensure stateful actions were durable by enabling state management aspect to be atomic with the operation. For ex: if a tool is executed, then the results are immediately saved within the same activity.
• make wf runtime task/wf registration atomic so things will only register once (this fixes a race condition where task/wf registrations occurred before runtime was fully up)
• use deterministic time formatting from the wf context
• updated log levels to improve dx and not log so much and also not log on replays of the wf
• create/use helpers in the activities so they're not as large with making state management more atomic

The workflow used to look like this:

And now its simplified to this :)

[sicoyle]

I'm looking for input on activity naming still. For the generate_llm_response calls, I think that could be clearer with a few options:

1. plan_and_call_tools and the second call being llm_final_response
2. llm_plan and the second call being llm_generate_response
3. More ReAct focused: reason_and_act and the second call being observe_and_respond

Open to ideas here and on other activity call names please.

[sicoyle]

this was added bc MCP's websocket client requires it so in the tests i saw MCP tool schema creation fail silently... so went ahead and added a core dep

[Cyb3rWard0g]

does the task_name generate_llm_response exist yet? or this is a placeholder for when the task names are updated

[sicoyle]

yes, i renamed generate_response to generate_llm_response so now thats what it appears as in tracing

[Cyb3rWard0g]

Other than the question about the name of the task, LGTM. If the task named "generate_llm_response" does not exist yet, then it will not trigger right?

[bibryam]

1. IMO ToolCallingWorkflow -> AgenticWorkflow
   as it is not always tool calling, and in fact it is an agentic workflow as per definition:

An agentic workflow is an AI-driven process where autonomous, intelligent AI agents manage complex tasks and processes with minimal human intervention, making decisions, coordinating actions, and adapting to changing circumstances in real-time.

2. We cannot use plan, final_call, etc as we not every LLM interaction starts with a plan, or ends up in tool call.
   I think we need two names:
   run_tool -> run_tool (this is ok)
   generate_llm_response -> call_llm