Pass LLM or Runnable chain in config @ runtime

[TanGentleman]

Currently, we pass custom callbacks at runtime. This allows custom logic to modify arbitrary frontends, like our gradio app in src/tangents/app.py.

When the graph reaches the action node, it populates the ActionArgs with the configurable values. These can be unloaded from the action arg after saving, and in some flows, should have info unnecessary to the LangGraph state.

This concept should be extended to runnables, for instance the LLM as a ChatOpenAI object. This eliminates the need to define it in the task state beforehand.

One option is to define these directly in the LangGraph action_node function. This seems less maintainable, and it seems like a better idea to include it in src/tangents/core/handle_action.py. This will take some testing, but should reduce the bloat in our graph state as well.

[TanGentleman]

I really like this pattern! I wonder which other things make more sense in the config class...

Here's a guide that includes some helpful info (I can write in Python/Typescript):

https://langchain-ai.lang.chat/langgraphjs/how-tos/configuration/

[TanGentleman]

More docs:

https://v02.api.js.lang.chat/interfaces/_langchain_core.runnables.RunnableConfig.html

https://api.python.langchain.com/en/latest/core/runnables/langchain_core.runnables.config.RunnableConfig.html

https://python.langchain.com/docs/how_to/binding/

Here's the changes I'd like to make:

• Change the type for the configuration passed in LangGraph nodes to be a RunnableConfig
• Add runtime arguments, including active third party sessions, in this object
• Use .bind in our constructors, like ChatOpenAI object

[TanGentleman]

Making some changes! Previously, behavior was as following:

1. User executes graph
2. When user input is being processed, if there's no LLM or chain in the task state, construct the chain here or fail.
3. Pass this chain to the Generate action at the action node on execution.

Change:

1. User executes graph (with RunnableConfig for any configurable params)
2. When input is being processed, if there's no active chain in the task state, give a warning
3. At the action node, prioritize: values in action_args > config > task_state.

This kiinda goes against a principle for this framework:

• Each Task maintains state needed for all Actions to execute successfully. Logic is defined for each discrete TaskType.
• This allows us to reason through the trace as the graph executes.

I find the tradeoffs to be great, but only if we have strong observability into executed actions. This applies more generally to anything configurable at runtime, since we break parity with the logged details of our task from its recorded state.

[TanGentleman]

Here's a public LangSmith trace of the difference between including the LLM chain in the task state vs. only defining it at runtime: https://smith.langchain.com/public/e54aa8b0-21a2-4077-ac9c-e1828bc52523/d