Separate Planner/Execution Flow in Accelerated Discovery Framework

[muthukumaranR]

Is your feature request related to a problem?

The way agents work is non-deterministic, and especially in long tail processes, any unintended behaviour will cascade exponentially down the chain.

Describe the solution you'd like

Our Accelerated Discovery Framework needs a clearer separation between the planning and execution stages, to make sure we can capture some of these in early stage, before execution.

Describe alternatives you've considered

setting Temperature to 0 doesn't seem to help in other cases

Additional context

- when a langgraph "graph" is compiled, is shows all the nodes connected, irrespective of if they will be visited based on a condition. we need a way to pre-polulate the path we might end up taking, as well as some parameters that will need to be considered by the nodes (agents) in the process. 

e.g. the search engines to consider when using the searchNG tool, (being a runtime decision based on query)

- This would be a first step in creating a few langgraph execution flow, where the current execution is based on the previously successful, stored state representation. 

[muthukumaranR]

@movinam implemented a initial version, for a basic QA / lit review agent.

problem
bug - doesnt get to end node with vllm and ollama

[movinam]

Currently working on a planner implementation based on the LLMCompiler and HuggingGPT papers.

References:

1. LLMCompiler Repo
2. Microsoft Jarvis - HuggingGPT
3. LLMCompiler LangGraph Implementation
4. LangGraph Sequential Planning
5. KnowAgent

[movinam]

The format for a task in a plan could be as follows. We can either use TypedDict or Pydantic classes:

class Task(TypedDict):
    """Represents a singular task.

    Attributes:
        idx (int): A unique identifier for the task.
        tool (BaseTool): An instance of a tool that performs the task's action.
        args (list): A list of arguments required by the tool to execute the task. 
                     The arguments could optionally take an additional argument called "context" allowing context from other tasks to be passed to the current task.
        dependencies (list): A list of task identifiers that the current task is dependent on.
        thought (Optional[str]): Optional field for additional notes or reasoning about the task.
    """
    idx: int
    tool: BaseTool
    args: list
    dependencies: list
    thought: Optional[str]

A plan would consist of a list of tasks. For example, for the query, "What is the current temperature in San Franciso raised to the third power?":

[
    {
        'idx': 1,
        'tool': StructuredTool(name='search_engine', description='search_engine(query="the search query") - a search engine.', args_schema='', etc ...),
        'args': {'query': 'current temperature in San Francisco'},
        'dependencies': [],
        'thought': None
        },
    {
        'idx': 2,
        'tool': StructuredTool(name='math', description='math(problem: str, context: Optional[list[str]]) -> float:\n - Solves the provided math problem.\n, (detailed description) ...', etc ...),
        'args': {'context': ['$1']},
        'dependencies': [1],
        'thought': None
        },
    {
        'idx': 3,
        'tool': 'join',
        'args': (),
        'dependencies': [1, 2],
        'thought': None
        }
]

[NISH1001]

@movinam This looks good. Since BaseTool is also an attribute, I think this fits nicely to existing framework as the tools and agents have to_langchain_structured_tool(...) method and can be converted to it. Might need to integrate and check though.

[muthukumaranR]

I am taking this task: Tracking this in this issue here: #87

I will send incremental PRs as I have them tested

[muthukumaranR]

The planner workflow is merged to develop: #244