refactor: more flexibility in workflow composition

[tomaszfelczyk]

It would be nice if workflows cloud be composed in more flexible way.
To achieve this delegation to different agent could be done using delegate() and awareOf() (can help understand supervisor abilities of whole workflow) tools.

const hierarchicalWorkflow = (team: Agent[], description: string) => {
    const resourcePlanner = resource_planner({
        tools: {
            delegate: delegateTo(team)
        }
    })
    return workflow({
        team: team,
        entrypoint: supervisor({
            tools: {
                delegate: delegateTo([resourcePlanner]),
                awareOf: awareOf(team)
            }
        }),
        description: description,
        ...
    })
}

I can prepare a PoC if it relates to the concept and goals of the project.

[grabbou]

Right now, not sure if this helps, agents can delegate/handoff via available state modifiers. Check implementation of supervisor and planner. Does that help? I will add it to the README, I realized it's not well documented/intuitive at first shot!

Related #130

[tomaszfelczyk]

Thinking more about future limitations due to current architecture.

1. Supervisor is the only entrypoint of workflow
2. With current implementation, if i want to delegate anything in agent i need to rewrite it's run function which add complexity and increases the entry threshold of using the framework.

If we can think about tool'a as abilities of agent, then delegation is one of them. This implementation still can create child state as task delegated to different agent.
This architecture can also provide some convention. If we are thinking about state as nested tree of task and sub tasks then function calling is creation of child states and regular message response is result of current agent task that is going back to parent or is final result if current state is root.

[grabbou]

BTW,

Supervisor is the only entry point of workflow

If you want to change it, you can pass state as second argument to teamwork and create state yourself. That way, you can choose a different agent as entry point, either your own, or one of built-ins.

With current implementation, if i want to delegate anything in agent i need to rewrite it's run function which add complexity and increases the entry threshold of using the framework.

Yeah, delegation within agents is currently not supported, but it's on the roadmap. It was meant to be done automatically on error, when agent cannot complete the task, and also, as a way to delegate it further when needed.

This architecture can also provide some convention. If we are thinking about state as nested tree of task and sub tasks then function calling is creation of child states and regular message response is result of current agent task that is going back to parent

That is nice convention, but it also overlaps a bit with regular function calling, such as looking up wikipedia. Since we also want to provide serverless support, we have a teamwork variant that does not run tools on the server. Unless we add special property (such as synchronous, asynchronous), it will be hard to differentiate which tools are meant to be run on the server, and which not. I think this could be good idea anyway, because right now, we will pause on all tools on the server, where in fact, you may only want to pause on one such as wait_for_user_input, instead of the ones that you can execute.

[tomaszfelczyk]

If you want to change it, you can pass state as second argument to teamwork and create state yourself. That way, you
can choose a different agent as entry point, either your own, or one of built-ins.

I completely miss that! Thanks

That is nice convention, but it also overlaps a bit with regular function calling, such as looking up wikipedia. Since we also want to provide serverless support, we have a teamwork variant that does not run tools on the server. Unless we add special property (such as synchronous, asynchronous), it will be hard to differentiate which tools are meant to be run on the server, and which not.

Good points.
Theoretically, Wikipedia API can have some "agent" underneath, so overlapping with regular function calling can be a good thing and a way to build solid abstraction.

In which situations synchronous tools are needed?

I think this could be good idea anyway, because right now, we will pause on all tools on the server, where in fact, you may only want to pause on one such as wait_for_user_input, instead of the ones that you can execute.

Considering security issues, some “actions” or tool calls may also need user approval.

[grabbou]

In which situations synchronous tools are needed?

Ah, just used this as a mind shortcut. The idea is that you have two kinds of tools (let's say) on the server. Wikipedia -> let's say I want to run this one. And "get_user_input_from_slack", which, for example, I want to update into database myself via some event-driven architecture and resume workflow by then.

Does that make sense?

[tomaszfelczyk]

Clear.

I'm thinking out loud whether then the workflow in principle should be asynchronous in mind and adapted to event-driven. Whereas in non-event-driven environments it should be handled by kind of “runtime”.